Wielka moc małych żądań ściągnięcia: jak usprawniają przeglądy i przyspieszają rozwój

Piszę kod zawodowo od ponad pięciu lat. Przez pierwsze cztery lata nie przejmowałem się rozmiarem moich pull requestów (PR). Jednak w zeszłym roku przeszedłem od przesyłania ogromnych PR z tysiącami wierszy zmian do dzielenia ich na mniejsze, bardziej zarządzalne. Korzyści z tej zmiany były ogromne i w tym blogu podzielę się tymi zaletami.

Według GitHub , żądanie ściągnięcia to:

Pull request to propozycja scalenia zestawu zmian z jednej gałęzi do drugiej. W pull request współpracownicy mogą przejrzeć i omówić proponowany zestaw zmian, zanim zintegrują zmiany z główną bazą kodu.

Zasadniczo pull request jest sposobem współpracy; powinniśmy zrobić wszystko, co możliwe, aby ulepszyć tę współpracę. Jedną ze skutecznych metod poprawy tej współpracy jest utrzymywanie małych PR-ów.

Nie ma uniwersalnej definicji rozróżniającej małe i duże PR. Poleganie wyłącznie na liczbie zmienionych wierszy jest niewystarczające, ponieważ automatycznie generowany kod i testy mogą zawyżać liczbę wierszy. Kiedy w tym artykule odnoszę się do małych PR, mam na myśli podzielenie większego PR na wiele mniejszych, logicznie spójnych PR. Każdy mniejszy PR powinien być samodzielny, scalalny i możliwy do wdrożenia.

Nie jestem zwolennikiem sztucznego podziału, takiego jak podział żądania ściągnięcia na dwie części – jedną zawierającą cały kod i drugą zawierającą tylko testy – ponieważ takie podejście nie przynosi żadnych korzyści, którymi się poniżej dzielę.

Efektywne recenzje:

Poproś programistę o przejrzenie 10 linijek kodu, a znajdzie 10 problemów. Poproś go o przejrzenie 500 linijek, a powie, że wygląda dobrze.

Choć zabawny, ten cytat niesie ze sobą prawdę. Każdy jest zajęty swoją pracą, a kiedy prosisz kogoś o zrecenzowanie PR, w zasadzie prosisz go o poświęcenie mu czasu. Recenzja PR wymaga od recenzenta zmiany kontekstu z jego własnej pracy, a jeśli recenzja zajmuje dużo czasu, powrót do pracy może być dla niego wyzwaniem, co potencjalnie wpływa na jego motywację i zaangażowanie w recenzję.

Mniejsze PR-y, których przegląd zajmuje tylko około 20–30 minut, są znacznie łatwiejsze do wykonania w porównaniu z tymi, które mogą zająć 2–3 godziny. Ponadto większe PR-y często prowadzą do niedopatrzeń, ponieważ nasza koncentracja uwagi jest ograniczona, a przeskakiwanie między wieloma zmianami w jednym PR-ze może być mylące. Z mojego doświadczenia wynika, że mniejsze PR-y zwykle otrzymują lepsze opinie i prowadzą do bardziej znaczących rozmów o projektowaniu.

Szybsze recenzje:

W tym momencie myślę o dodaniu mojego PR do testamentu na wypadek, gdyby po mojej śmierci nadal trzeba było go przeglądać.

Dłuższe PR wymagają od recenzentów znacznego zaangażowania czasowego, co sprawia, że rzadziej zwracają uwagę — zwłaszcza jeśli nie są powiązane z funkcjami o dużym wpływie. Z drugiej strony, małe PR są szybko recenzowane, ponieważ wymagają mniej czasu od recenzenta i są mniej nachalne.

Taka szybkość recenzji może mieć kluczowe znaczenie dla dotrzymania terminów realizacji projektu; widziałem przypadki opóźnień w realizacji projektów, ponieważ starsi recenzenci nie mogli poświęcić czasu na obszerne PR-y (choć może się to zdarzyć w przypadku małych PR-ów, ryzyko jest z natury wyższe w przypadku dużych PR-ów).

Mniejsza przeróbka:

Przerabianie dużego PR-u po zmianach w projekcie jest jak przestawianie leżaków na statku, który właśnie skończyłeś budować... a następnie zatopienie go.

Wszyscy doświadczyliśmy sytuacji, w których ktoś podczas przeglądu PR zdaje sobie sprawę, że inny projekt byłby bardziej łatwy w utrzymaniu i odporny na przyszłość, a my musimy poświęcić dodatkowy czas na przerobienie PR na podstawie nowego projektu (nie mówiąc, że byli całkowicie za projektem, który został pierwotnie wdrożony :p). Jest to bardzo naturalne, ponieważ czasami rzeczy stają się jaśniejsze, gdy widzisz je zapisane w kodzie i zaczynasz zauważać aspekty, które mogłeś przegapić w fazie projektowania.

W przypadku dużych PR może to być poważny problem, ponieważ trzeba przerobić wiele elementów, ale w przypadku mniejszych PR łatwiej jest wprowadzać zmiany. Co ważniejsze, istnieje mniejsze prawdopodobieństwo przeróbek, ponieważ recenzenci częściej identyfikują problemy na wczesnym etapie i zajmują się nimi w początkowych PR, co pozwala na oparcie kolejnych PR na nowych projektach.

Lepsze testowanie:

Mniejsze PR-y są również korzystne dla Ciebie jako autora PR-u. Pomagają one w testowaniu mniejszych zmian stopniowo, zamiast testowania całego projektu na raz. Testowanie mniejszych zmian skutkuje bardziej wyczerpującym testowaniem każdego komponentu systemu, co prowadzi do mniejszej liczby błędów produkcyjnych. Dotyczy to zarówno testów automatycznych, jak i testów ręcznych wykonywanych przez Ciebie lub dedykowanych inżynierów ds. zapewnienia jakości.

Co więcej, mniejsze żądania powtórzenia testu zmniejszają prawdopodobieństwo pominięcia przypadków testowych, ponieważ można skupić się na ograniczonym zakresie, a nie na całym systemie.

Pisanie testów? To brzmi jak problem Future Me.

Widziałem, jak programiści (w tym ja sam w przeszłości) wahali się przed pisaniem testów automatyzacji z powodu postrzeganej inwestycji czasu bez natychmiastowej, „widocznej” wartości dla funkcji/produktu. Mniejsze PR-y zmniejszają to tarcie, ograniczając liczbę wymaganych testów i czas poświęcony na ich pisanie.

Łatwiejsze debugowanie:

Niezależnie od tego, jak dokładne są testy, błędy produkcyjne będą się zdarzać! Możliwość debugowania błędów w produkcji jest kluczowa, ponieważ błędy produkcyjne bezpośrednio wpływają na użytkowników, firmę lub obie strony. W przypadku dużych PR powierzchnia zmian jest również duża, co sprawia, że znalezienie przyczyny problemów jest czasochłonne i trudne. Z drugiej strony mniejsze PR zawierają mniej kodu, co znacznie przyspiesza debugowanie.

Debugowanie małych zmian jest jak szukanie literówki; debugowanie dużych zmian jest jak korekta encyklopedii.

Wdrażanie funkcji etapami:

Na koniec, mniejsze PR są również pomocne dla Twojego product managera i użytkowników. Dzięki małym PR możesz stale przekazywać części systemu do produkcji, co pomaga w uzyskaniu wczesnych opinii od użytkowników i umożliwia wczesne korekty kursu, jeśli zajdzie taka potrzeba.

Pominięcie wczesnej informacji zwrotnej jest jak przygotowanie pięciodaniowego posiłku bez spróbowania czegokolwiek — masz tylko nadzieję, że nie skończy się to katastrofą.

Korzyści z małych PR-ów jest wiele, a punkty opisane powyżej są jednymi z najbardziej wpływowych, jakich doświadczyłem osobiście. Jeśli napotkałeś inne zalety małych PR-ów lub wyzwania związane z większymi, których nie omówiłem, podziel się swoimi spostrzeżeniami.

Mam nadzieję, że ten artykuł zmotywuje Cię do przyjęcia mniejszych PR-ów. Jeśli już jesteś na pokładzie, mam nadzieję, że wzmocni to wartość tej praktyki.

Dziękuję za przeczytanie. Do następnego razu, koduj dalej i pozostań ciekawy!