Dlaczego Warto Tworzyć Małe Pull Requesty?

Robotę trzeba sobie ułatwiać. Nie ma co gdybać. Dzisiaj pogadamy sobie o przeglądach kodu i ułatwieniu pracy z nimi. Czyli o dzisiaj będzie o code review.

Podobno pierwsza zasada dobrego programmera brzmi:

Pull requesty mają być małe.

Świat jest, jaki jest i nie zawsze nam się chce. Przyznaje — mi też się zdarza. Wiadomo, że łatwiej skupić się na robocie i pracować nieprzerwanie nad taskiem, ale w tym wszystkich musimy pamiętać, że mały pull-request nie jest tylko "dla zasady".

Po co tworzyć małe PR? Co Ci przychodzi do głowy? Bo mi kilka benefitów:

• Potencjalnie większa stabilność rozwiązania.
• Podział pracy na mniejsze kawałki daje lepsze zrozumienie całości. No bo przecież musisz zrozumieć problem, aby wiedzieć, jak go podzielić na mniejsze PR.
• Małe PR łatwiej się przegląda. Co przełoży się na szybszy proces review. Co więcej, łatwiej wyłapać potencjalne luki.
• Szybszy increment. Już dzisiaj może wpaść nowy kod do developa.
• Może zmiany są na tyle małe, że może nie musisz prosić QA o testy przed mergem? O ile w Twoim projekcie jest używana taka praktyka.
• W razie problemów (regresja) łatwiej namierzyć potencjalny błąd. Szybciej (prawdopodobnie) znajdziesz problematyczny kawałek kodu za pomocą git bisect.
• Motywacja zespołu, jak również Twoja wrosną. Widzisz, że ciągle coś wpada. Pull requesty, które czekają na przegląd, nie istnieją. Nie siedzisz nad taskiem tydzień czy dwa, ale dzień — może nawet kilka godzin. Zadanka ciągle lądują w statusie done. Fajne? Fajne.
• Jest szansa, że nie będziesz musiał estymować zadań. No bo jeśli zadanie jest podzielone na mniejsze to potencjalnie powstanie malutki kodzik.

No to jak możesz dzielić robotę?

Plan musi być. Głupio by było, gdybyś zaczął pracować nad taskiem i się okazało, że nie będzie to mały PR. Potem masz dwie drogi: albo skończyć to, co masz i potem podzielić kod rozwiązania, na kilka mniejszych gałęzi (branch) lub wrzucić okrąglutki, wielki, nieprzyjemny, śmierdzący PR, do którego nikt nie chce podejść.

Zakładam, że żadnej z nich nie chcesz.

To jak to zrobić inaczej?

1. Zastanów się, co trzeba przygotować. Niby oczywiste, ale zrozum, co jest celem zadania. Co ma zostać dowiezione na koniec dnia? Rozumiesz już kontekst biznesowy, rozumiesz funkcjonalność? Już wiesz, jak zrobić to w kodzie? Świetnie.
2. To teraz zastanów się nad ilością zmian. Sporo? To podziel to spore zadanie na mniejsze zadanka. Niech każde z nich dorzuca kolejną cegiełkę/cegiełki do tej budowli zwanej ficzerem.
3. Może dzięki tym mniejszym zadaniom możesz zaangażować innych devów do pomocy? Może da się tę robotę zrównoleglić?

Stary, to więcej roboty.

No wiem. I co z tego? 💁

Wróć do listy, gdzie pisałem o benefitach. Serio, nawet ta godzina, czy dwie poświęcona na dodatkową obsługę PR i commitowanie częściej jest czymś złym? Korzyści mówią, że nie.

Nie jest i koniec Pani/Panie czytelniku.

Chyba zgodzisz się ze mną, że jest coś zajebistego w momencie, gdy klikasz przycisk merge i Twoje zmiany lądują w developie?

No to teraz będziesz miał więcej okazji, aby to poczuć. 🌝

Czasami się nie da.

Fakt, czasami szybciej lub po prostu sensowniej coś zrobić w jednym PR. Wtedy zastanów się, jak możesz pomóc osobom, które będą Twój kod przeglądać.

Moje propozycje:

• Podziel zmiany na wiele commitów.
• Dodaj sensowny opis z podsumowaniem zmian w panelu PR — polecam Ci o to dbać przy każdym PR.

A Ty jak podchodzisz do pracy z PR? Dzielisz czy raczej jesteś autorem większych paczek zmian?

Nie wstydź się i daj znać w komentarzu! 👇