7 sposobów na drastyczne skrócenie czasu przeglądu kodu

Przeglądy kodu mogą być bolesne. Inżynierowie oprogramowania często skarżą się, że proces weryfikacji jest powolny. Opóźnia kolejne zadania i prowadzi do przełączania kontekstu, gdy nawigujesz tam i z powrotem pomiędzy otwartym pull requestem (PR) a kolejnym zadaniem. Przeglądy kodu mogą być również pełne niuansów i obrzucania się błotem, co sprawia, że nie jest to dobre doświadczenie dla wszystkich zaangażowanych.

Aby zaradzić temu problemowi, niektórzy inżynierowie posunęli się nawet do zasugerowania, abyśmy całkowicie pozbyli się pull requestów i code reviews. O ile może to działać w przypadku małych zespołów w startupach, nie sądzę, aby było to właściwe rozwiązanie dla wszystkich, a zwłaszcza dla firm na poziomie przedsiębiorstwa.

Istnieje raczej wiele sposobów, aby uczynić proces recenzji kodu lepszym doświadczeniem zarówno dla autora kodu, jak i dla recenzenta. Rozważmy razem siedem z tych najlepszych praktyk.

#1: Niewielkie wnioski o dociągnięcia

Każdy inżynier obawia się przeglądania pull requestów, w których zmieniono ponad 1000 linii kodu. Takie przeglądy mogą trwać godzinami i często kończy się to tym, że recenzent zaczyna przeglądać kod, zamiast uważnie go przejrzeć.

Rozwiązaniem jest utrzymywanie małych pull requestów. Małe PRy są łatwiejsze i szybsze do zrecenzowania. Recenzent nie musi spędzać tyle czasu na budowaniu mentalnego modelu tego, jak wszystkie zmiany działają razem. Jest też mniej zmienionego kodu, co, miejmy nadzieję, równa się mniejszej ilości błędów, mniejszej ilości komentarzy i mniejszej ilości rund tam i z powrotem pomiędzy autorem a recenzentem.

Utrzymywanie małych PR-ów może wydawać się trudne na początku, ale można to zrobić, jeśli podzielisz swoją pracę na małe zadania i pozostaniesz skupiony. Nie rób dużych refaktoryzacji, jednocześnie implementując nowe funkcje lub naprawiając błędy. Używaj znaczników funkcji w swoim kodzie, dzięki czemu możesz scalać małe części nowych funkcji do gałęzi głównej bez pokazywania ich w aplikacji produkcyjnej.

Utrzymuj swoje PR-y na niskim poziomie. Twoi recenzenci będą wdzięczni.

#2: Użyj szablonów pull requestów

Kolejną irytującą rzeczą jest bycie poproszonym o przejrzenie pull requesta bez żadnego kontekstu. Kiedy PR zostaje rzucony na kolana bez wyjaśnienia, często zastanawiasz się: „Do czego służy ten PR? Jaki problem rozwiązuje? Czy jest jakieś powiązane z tym zadanie? Dlaczego zastosowano to konkretne podejście?”.

Szablon pull request to mały, konfigurowalny formularz, który możesz ustawić jako domyślny tekst na każdym nowym pull request. Szablon PR skłania autora kodu do podania istotnych szczegółów dotyczących ich PR. Zazwyczaj szablon PR prosi o krótki opis tego, co zrobiłeś i dlaczego, link do biletu zadania oraz plan testów sprawdzających poprawność zmian.

Dobre szablony PR zazwyczaj zawierają również krótką listę kontrolną dla autora kodu, aby upewnić się, że nie pominął żadnego z podstawowych elementów. Lista ta może zawierać takie elementy jak testy jednostkowe, dokumenty, internacjonalizacja, wsparcie dla różnych przeglądarek i dostępność.

Poniżej znajduje się przykładowy szablon pull request, który lubię używać dla wszystkich moich repozytoriów:

#3: Wdrożenie umów SLA dotyczących czasu odpowiedzi

Jeśli zauważyliście, że pull requesty siedzą nie przejrzane dłużej niż byście chcieli, to teraz jest dobry moment, aby ustalić oczekiwania zespołu co do tego, jak szybko nowy pull request powinien być przejrzany. Innymi słowy, jaki jest maksymalny czas, w którym PR może istnieć, zanim zostanie odebrany? Jedna godzina? Dwie godziny? 24 godziny? Twoja odpowiedź na to pytanie będzie prawdopodobnie zależała od wielkości twojego zespołu. Możesz też mieć inną odpowiedź dla wewnętrznych pull requestów z Twojego zespołu, niż zewnętrznych pull requestów z innych zespołów.

Wybierając czas odpowiedzi SLA (service level agreement), będziesz chciał znaleźć odpowiednią równowagę. Nie jest rozsądne oczekiwać, że wszyscy natychmiast rzucą to, co robią i przejrzą Twój kod, kiedy opublikujesz nowy PR, ale nie chcesz też, żeby PR-y pozostawały nieprzegadane przez wiele godzin. Znajdź odpowiednią równowagę, która pozwoli Twoim kolegom z zespołu wejść w stan flow. Powinni mieć możliwość pracy nad własnym kodem, a następnie przeglądania PR w naturalnych momentach w ciągu dnia.

Osobiście lubię mieć dwugodzinne SLA na czas reakcji dla PR-ów wewnętrznego zespołu i 24-godzinne SLA na czas reakcji dla PR-ów zespołu zewnętrznego.

Niezależnie od tego, co postanowisz Ty i Twoi koledzy z zespołu, posiadanie umowy zespołowej pozwala na wzajemne rozliczanie się. Jeśli wszyscy zgodzili się na określone SLA i czas ten upłynął dla jednego z Twoich PR-ów, wiesz, że możesz zacząć o to pytać.

#4: Szkolenie junior i mid engineers

Możliwości szkolenia są wszędzie. Mentoring mniej doświadczonych inżynierów to coś więcej niż tylko nauczanie ich technologii i języków, z którymi pracują. To także uczenie ich umiejętności miękkich, jak np. jak przeprowadzać efektywny code review.

Zobacz również: Cienie i blaski mentoringu

Naucz swoich kolegów z zespołu, na co zwracasz uwagę podczas przeglądu kodu. Pomóż im zrozumieć, co jest ważne, a co nie. Naucz ich, jak efektywnie komunikować się w komentarzach do przeglądu kodu, na przykład poprzez poprzedzanie nieblokujących sugestii słowem „nit”.

Istnieje wiele świetnych zasobów na temat tego, jak być bardziej efektywnym recenzentem kodu. Przewodnik Google Code Review Developer Guide jest wart przeczytania w całości. Przewodnik zawiera doskonałe porady zarówno dla autora kodu, jak i dla recenzenta kodu. Z kolei How to Make Your Code Reviewer Fall in Love with You to jedne z najlepszych (i zabawnych) porad dla programistów tworzących pull requesty.

#5: Skonfiguruj linie ciągłej integracji

Przeglądy kodu stają się nużące, gdy większość komentarzy to rzeczy takie jak „brakujący średnik” lub „wcięcie wydaje się tu nie pasować”. Nie poświęcaj czasu podczas przeglądów kodu na rzeczy, o które formatyzatory kodu i lintery kodu mogą zadbać za Ciebie. Pozwól komputerom zautomatyzować trywialne rzeczy, abyś mógł skupić się na ważnych rzeczach, które wymagają człowieka.

W przypadku projektów JavaScript, łatwo jest skonfigurować formater taki jak Prettier i linter taki jak ESLint dla swojego repo. Następnie można ustawić ciągłą integrację (CI – ang. Continuous Integration) dla swojego repo używając czegoś takiego jak Travis CI, CircleCI, GitHub Actions lub GitLab CI/CD.

Twój system CI wykona te zadania formatowania i lintingu dla ciebie wraz z twoimi testami jednostkowymi. Jeśli system CI zawiedzie na którymkolwiek etapie pull requestu, zablokuje go przed scaleniem.

Teraz zautomatyzowałeś kilka ważnych części przeglądu kodu, oszczędzając godziny.

#6: Użyj aplikacji do przeglądania pull requestów

Czasami konieczne jest nie tylko przejrzenie kodu w pull request, ale także ręczne obejrzenie zmian w aplikacji, aby sprawdzić, czy wszystko wygląda dobrze. W przypadku aplikacji ze skomplikowanymi krokami konfiguracyjnymi, ściągnięcie czyjegoś kodu i uruchomienie go lokalnie na swoim komputerze może zająć od pięciu minut do godziny. Co za ból głowy!

Aplikacje do przeglądania pull requestów są używane do automatycznego wdrażania kodu do krótkotrwałego środowiska testowego za każdym razem, gdy tworzony jest nowy PR. Dzięki temu recenzenci mogą łatwo sprawdzić zmiany w UI bez konieczności ściągania kodu i uruchamiania go lokalnie na swoim komputerze. Nie tylko oszczędza to czas, ale także skłania recenzentów do bycia bardziej dokładnymi w swoich recenzjach poprzez ułatwienie.

#7: Generowanie diagramów do wizualizacji zmian w kodzie

Podczas przeglądania kodu w GitHubie lub GitLabie, pliki są zazwyczaj wyświetlane w kolejności alfabetycznej. Dla stosunkowo małych PR-ów może to nie być problemem. Ale kiedy w PR są dziesiątki plików, czasami warto zobaczyć te zmiany pogrupowane logicznie, aby zobaczyć jak pasują do siebie w większej całości.

CodeSee Review Maps pomoże Ci zwizualizować, które pliki zostały zmienione i jak te zmiany wpływają na ich zależności. Integrują się z GitHubem, aby automatycznie umieszczać komentarze i diagramy na PR. Możesz nawet stworzyć interaktywne wycieczki po swoim kodzie, aby pomóc w prowadzeniu recenzentów kodu. Co najlepsze, CodeSee Maps są darmowe dla organizacji open-source i ich publicznych repozytoriów.

Wnioski: Najlepsze praktyki przyspieszania przeglądów kodu

1.Utrzymuj pull requesty na niskim poziomie.

2.Używaj szablonów pull requestów, aby dostarczyć recenzentowi cały kontekst, którego będzie potrzebował.

3.Wdrażaj umowy SLA dotyczące czasu odpowiedzi.

4.Przeszkolenie młodszych i średnich inżynierów w zakresie kluczowych rzeczy, na które zwracasz uwagę podczas przeglądu kodu.

5.Skonfiguruj linie CI, aby uruchomić lintery, formatery i testy jednostkowe.

6.Używaj aplikacji do przeglądania pull requestów, aby móc łatwo sprawdzić zmiany UI.

7.Generować diagramy do wizualizacji zmian w kodzie za pomocą narzędzia takiego jak CodeSee Review Maps.

Podsumowując, oto siedem wskazówek, jak radykalnie skrócić czas przeglądu kodu:

Dzięki za przeczytanie i życzę miłego kodowania!

Oryginalna wersja artykułu: https://dev.to/thawkin3/7-ways-to-dramatically-reduce-your-time-in-code-review-5cb2