Jak napisać dobry request pull

Żądania pull to siła napędowa repozytorium. Dzięki nim wszystko działa sprawnie. Na tej stronie znajdziesz szczegółowe informacje o tym, jak utworzyć kompletny i łatwy do sprawdzenia PR, co zwiększa szanse na jego połączenie.

Oto kilka wskazówek, które pomogą Ci prowadzić jak najlepszą kampanię PR.

  1. Komunikacja
  2. Konfigurowanie
  3. Keep it Small
  4. Zadbaj o przejrzystość
  5. Testowanie zmiany
  6. Komunikacja (część 2)

Komunikacja

Zanim zaczniesz pisać kod, warto skontaktować się z zespołem głównym, aby poinformować go o swoich zainteresowaniach.

Jeśli interesuje Cię jakiś problem, dodaj do niego komentarz, w którym poinformujesz, że zamierzasz nad nim pracować. Dzięki temu nie będzie kilku osób pracujących nad tym samym. Członek zespołu potwierdzi, że to Twój numer.

Jeśli masz pomysł, który nie jest objęty żadnym wydaniem, napisz własny scenariusz, zanim zaczniesz pracę. Dzięki temu zespół będzie mieć okazję przed rozpoczęciem tworzenia kodu omówić, jak najlepiej wprowadzić zmianę. Pozwoli to zaoszczędzić Ci pracy w długim okresie.

Konfiguracja

Jeśli po raz pierwszy przyczyniasz się do rozwoju Blockly lub blockly-samples, zacznij od strony konfiguracji programistycznej.

Keep it Small

Zawsze staraj się, aby zmiany były niewielkie i skupione na konkretnym celu. Zdecydowanie wolimy sprawdzić kilka mniejszych projektów PR niż jeden duży. Oto kilka przydatnych wskazówek:

  • Rozwiąż jeden problem. Nie próbuj rozwiązywać wielu problemów jednocześnie.
  • Ogranicz zakres. Zwykle PR powinien zająć mniej niż 8 godzin (w zależności od tego, jak dobrze znasz kod).
  • Używaj commitów. Jeśli Twój PR jest zbyt duży, podziel zmiany na logiczne grupy za pomocą commitów git.

Zadbaj o czystość

Dlaczego warto zwracać uwagę na styl kodu? Chcemy, aby nasze usługi były dostępne na dłużej perspektywie, a utrzymanie spójnego stylu ułatwia ich konserwację. Styl odnosi się do sposobu nazywania zmiennych, ale obejmuje też strukturę kodu, pisanie komentarzy i inne kwestie. W miarę możliwości używamy narzędzi takich jak eslint do automatyzacji sprawdzania stylu.

Oprócz eslint postępuj zgodnie z tymi przewodnikami:

Testowanie zmiany

Zanim wprowadzisz zmiany w ramach PR, zawsze sprawdź, czy działają prawidłowo, aby nie trzeba było ich później poprawiać. Oto kilka pomysłów na testowanie różnych kategorii projektów:

  • W przypadku wtyczek: napisz automatyczne testy Mocha obejmujące zmiany.
  • Przykłady: ręcznie przetestuj wszystkie demonstrowane funkcje.
  • W przypadku codelabs przeprowadź cały samouczek w czystym środowisku i przetestuj podany przykładowy kod.

Komunikacja

To ostatnia i najważniejsza część tworzenia PR: napisanie podsumowania.

Dobre podsumowanie zmian ułatwia innym deweloperom ich sprawdzenie, dzięki czemu szybciej zostaną zaakceptowane.

Podsumowanie powinno zawierać m.in.:

  • Problem, którego dotyczy zgłoszenie.
  • Jaką zmianę wprowadza PR.
  • jak testowano wprowadzoną zmianę.
  • Wszystko, co chcesz, aby sprawdzili weryfikatorzy.
  • wszelkie inne informacje, które według Ciebie są potrzebne weryfikatorom.

Jeśli podczas tworzenia prośby będziesz się trzymać szablonu, wszystko powinno być w porządku. Pamiętaj, aby prośba była jak najbardziej zwięzła i pełna.

Miłego kodowania!