Od ponad dekady zajmuję się codziennymi przeglądami kodu. Korzyści z przeglądów kodu jest mnóstwo: ktoś sprawdza Twoją pracę pod kątem błędów, ktoś uczy się na podstawie Twojego rozwiązania, a współpraca pomaga poprawić ogólne podejście organizacji do narzędzi i automatyzacji. Jeśli obecnie nie przeprowadzasz przeglądów kodu w swojej organizacji, zacznij teraz. Dzięki temu każdy stanie się lepszym inżynierem.
Mnóstwo osób i organizacji podzieliło się swoimi najlepszymi praktykami w zakresie code review i tym, co dla nich oznacza definicja dobrego code review. Przewodniki od Google, zespołu SmartBear i inżyniera Philippa Hauera są świetną lekturą. Poniżej przedstawiam moje osobiste spojrzenie na to, jak wyglądają dobre przeglądy kodu i jak sprawić, by były jeszcze lepsze na poziomie zespołu i organizacji. Jest to w kontekście środowiska technologicznego, w którym pracuję – obecnie w Uber, a wcześniej w Skype/Microsoft i Skyscanner.
Dobre przeglądy kodu są poprzeczką, do której wszyscy powinniśmy dążyć. Obejmują one powszechne i łatwe do naśladowania najlepsze praktyki, od których każdy zespół może zacząć, zapewniając jednocześnie wysoką jakość i pomocne recenzje w dłuższej perspektywie.
Better code reviews to sytuacje, w których inżynierowie stale ulepszają sposób wykonywania code reviews. Te przeglądy kodu patrzą na zmianę kodu w kontekście bazy kodów, tego kto o nią prosi i w jakiej sytuacji. Te przeglądy dostosowują swoje podejście w oparciu o kontekst i sytuację. Celem jest nie tylko uzyskanie wysokiej jakości przeglądu, ale także pomoc programistom i zespołom, które o niego proszą, aby byli bardziej produktywni.
Obszary objęte przeglądem kodu
Dobre przeglądy kodu patrzą na samą zmianę i jak pasuje ona do bazy kodu. Przejrzą przejrzystość tytułu, opisu i „dlaczego” zmiany. Obejmują poprawność kodu, pokrycie testami, zmiany funkcjonalności i potwierdzają, że podążają za przewodnikami kodowania i najlepszymi praktykami. Będą wskazywać na oczywiste ulepszenia, takie jak trudny do zrozumienia kod, niejasne nazwy, wykomentowany kod, nietestowany kod lub nieobsługiwane przypadki brzegowe. Zauważą również, kiedy zbyt wiele zmian jest upchanych w jednym przeglądzie i zasugerują utrzymanie zmian kodu w jednym celu lub rozbicie zmiany na bardziej skoncentrowane części.
Najlepsze przeglądy kodu patrzą na zmianę w kontekście większego systemu, jak również sprawdzają, czy zmiany są łatwe do utrzymania. Mogą zadawać pytania o konieczność zmiany lub o to, jak wpływa ona na inne części systemu. Przyglądają się wprowadzonym abstrakcjom i temu, jak pasują one do istniejącej architektury oprogramowania. Zwracają uwagę na spostrzeżenia dotyczące łatwości utrzymania, takie jak złożona logika, którą można uprościć, poprawa struktury testów, usunięcie duplikatów i inne możliwe usprawnienia. Inżynier Joel Kemp opisuje świetne przeglądy kodu jako kontekstowe przejście po wstępnym, lekkim przejściu.
Ton przeglądu
Ton przeglądów kodu może znacząco wpłynąć na morale w zespołach. Recenzje z ostrym tonem przyczyniają się do poczucia wrogiego środowiska poprzez swoje mikroagresje. Opiniotwórczy język może sprawić, że ludzie staną się defensywni, wywołując gorące dyskusje. Jednocześnie, profesjonalny i pozytywny ton może przyczynić się do powstania bardziej integracyjnego środowiska. Ludzie w tych środowiskach są otwarci na konstruktywne informacje zwrotne, a recenzje kodu mogą zamiast tego wywoływać zdrowe i ożywione dyskusje.
Dobre recenzje kodu zadają otwarte pytania, zamiast formułować mocne lub opiniotwórcze stwierdzenia. Oferują alternatywy i możliwe obejścia, które mogą działać lepiej w danej sytuacji, bez upierania się, że te rozwiązania są najlepszym lub jedynym sposobem postępowania. Takie recenzje zakładają, że recenzent może czegoś nie rozumieć i proszą o wyjaśnienie, a nie o korektę.
Najlepsze recenzje kodu są również empatyczne. Wiedzą, że osoba pisząca kod spędziła dużo czasu i wysiłku nad tą zmianą. Tacy recenzenci kodu są uprzejmi i niefrasobliwi. Pochwalają dobre rozwiązania i są ogólnie pozytywne.
Zatwierdzenie vs Żądanie zmian
Kiedy recenzent zakończy przegląd, może oznaczyć go jako zatwierdzony, zablokować przegląd żądaniami zmian lub nie nadawać mu określonego statusu, pozostawiając go w stanie „jeszcze nie zatwierdzony”. To, w jaki sposób recenzenci używają statusów zatwierdzenia i żądania zmian, świadczy o przeglądzie kodu.
Dobre przeglądy kodu nie zatwierdzają zmian, gdy istnieją pytania otwarte. Jednakże, dają jasno do zrozumienia, które pytania lub komentarze są nieblokujące lub nieistotne, oznaczając je w wyraźny sposób. Są one wyraźne przy zatwierdzaniu zmian – np. dodając komentarz w postaci kciuka w górę, taki jak „wygląda dobrze!”. Niektóre miejsca używają akronimów takich jak LGTM – one również działają, ale należy być świadomym, że nowicjusze mogą błędnie zinterpretować te wewnętrzne akronimy jako coś innego. Dobre przeglądy kodu są równie wyraźne, gdy żądają kontynuacji, używając narzędzia do przeglądu kodu lub konwencji zespołu, aby to zakomunikować.
Najlepsze przeglądy kodu są stanowcze co do zasady, ale elastyczne co do praktyki: czasami, niektóre komentarze są adresowane przez autora z oddzielną, następczą zmianą kodu. W przypadku zmian, które są bardziej pilne niż inne, recenzenci starają się być dostępni dla szybszych przeglądów.
Od przeglądu kodu do rozmowy
Przeglądy kodu są zwykle wykonywane asynchronicznie i pisemnie poprzez narzędzie do przeglądu kodu. Wynika to zazwyczaj z wygody, aby umożliwić zdalne przeglądy kodu i pozwolić wielu osobom na przeglądanie tej samej zmiany w kodzie. Ale kiedy jest czas, aby przestać używać narzędzia – jakkolwiek dobre by ono nie było – i zacząć rozmawiać twarzą w twarz o kodzie?
Dobre przeglądy kodu pozostawiają tyle komentarzy i pytań, ile jest potrzebne. Jeśli poprawki nie odniosą się do wszystkich, również je odnotują. Kiedy rozmowa staje się długa, recenzenci próbują przejść do osobistej rozmowy z autorem, zamiast tracić więcej czasu na korzystanie z narzędzia do recenzji kodu.
Najlepsi recenzenci proaktywnie docierają do osoby wprowadzającej zmiany po tym, jak wykonają pierwsze przejście na kodzie i mają wiele komentarzy i pytań. Ci ludzie nauczyli się, że w ten sposób oszczędzają dużo czasu, nieporozumień i trudnych uczuć. Fakt, że istnieje wiele komentarzy do kodu wskazuje, że prawdopodobnie istnieje jakieś nieporozumienie po obu stronach. Tego typu nieporozumienia są łatwiejsze do zidentyfikowania i rozwiązania poprzez rozmowę na ten temat.
Nitpicks
Nitpicks są nieistotnymi komentarzami, gdzie kod może być scalony nawet bez zajmowania się nimi. Mogą to być takie rzeczy jak deklaracje zmiennych w porządku alfabetycznym, testy jednostkowe o określonej strukturze lub nawiasy w tej samej linii.
Dobre przeglądy kodu jasno pokazują, kiedy zmiany są nieistotnymi drobiazgami. Zazwyczaj oznaczają takie komentarze w sposób wyraźny, dodając do nich przedrostek „nit:”. Zbyt wiele z nich może stać się frustrujące i odciągnąć uwagę od ważniejszych części przeglądu, więc recenzenci starają się nie przesadzać z ich ilością.
Najlepsze przeglądy kodu zdają sobie sprawę, że zbyt wiele drobiazgów jest oznaką braku narzędzi lub braku standardów. Recenzenci, którzy często się z tym spotykają, szukają rozwiązania tego problemu poza procesem przeglądu kodu. Na przykład, wiele z typowych komentarzy nitpick może być rozwiązanych poprzez automatyczny linting. Te, które nie mogą być rozwiązane przez zespół, który zgadza się na pewne standardy i podąża za nimi – być może nawet automatyzując je, ostatecznie.
Przeglądy kodu dla nowych pracowników
Początek w nowej firmie jest przytłaczający dla większości ludzi. Baza kodów jest nowa, styl programowania inny niż wcześniej, a ludzie przeglądają twój kod w zupełnie inny sposób. Czy więc przeglądy kodu powinny być łagodniejsze dla nowych pracowników, aby przyzwyczaić ich do nowego środowiska, czy też powinny utrzymywać poprzeczkę tak samo wysoko, jak dla wszystkich innych?
Dobre przeglądy kodu używają tej samej poprzeczki jakości i podejścia dla wszystkich, niezależnie od stanowiska, poziomu lub czasu dołączenia do firmy. Zgodnie z powyższym, recenzje kodu mają uprzejmy ton, proszą o zmiany tam, gdzie są potrzebne, i docierają do recenzentów, aby z nimi porozmawiać, gdy mają wiele uwag.
Najlepsze recenzje kodu zwracają dodatkową uwagę na to, aby pierwsze kilka recenzji dla nowych pracowników było wspaniałym doświadczeniem. Recenzenci są empatyczni wobec faktu, że nowy użytkownik może nie być świadomy wszystkich wytycznych dotyczących kodowania i może nie być zaznajomiony z częścią kodu. Te recenzje wkładają dodatkowy wysiłek w wyjaśnienie alternatywnych podejść i wskazanie przewodników. Są one również bardzo pozytywne w tonie, celebrując kilka pierwszych zmian w bazie kodu, które autor sugeruje.
Przeglądy między biurami, między strefami czasowymi
Przeglądy kodu stają się trudniejsze, gdy recenzenci nie znajdują się w tym samym miejscu. Są one szczególnie trudne, gdy recenzenci siedzą w bardzo różnych strefach czasowych. Przez lata miałem swój spory udział w takich przeglądach, modyfikując kod należący do zespołów w USA i Azji, podczas gdy sam przebywałem w Europie.
Dobre przeglądy kodu uwzględniają różnicę stref czasowych, kiedy tylko mogą. Recenzenci starają się przeglądać kod w godzinach pracy nakładających się na siebie w różnych biurach. W przypadku przeglądów z wieloma komentarzami, recenzenci zaproponują bezpośredni czat lub rozmowę wideo, aby omówić zmiany.
Najlepsze przeglądy kodu zauważają, kiedy przeglądy kodu wielokrotnie napotykają na problemy związane ze strefą czasową i szukają systemowego rozwiązania, poza ramami przeglądu kodu. Załóżmy, że zespół z Europy często zmienia usługę, która wywołuje przeglądy kodu od właściciela tej usługi z USA. Pytanie na poziomie systemowym brzmi: dlaczego te zmiany zachodzą tak często. Czy zmiany są dokonywane we właściwej bazie kodu, czy też inny system powinien zostać zmieniony? Czy częstotliwość zmian będzie taka sama czy spadnie z czasem? Zakładając, że zmiany są dokonywane we właściwej bazie kodowej i częstotliwość zmian nie będzie spadać, czy można w jakiś sposób złamać zależności między biurami? Rozwiązania tego typu problemów często nie są proste i mogą wymagać refaktoryzacji, stworzenia nowych usług/interfejsów lub ulepszenia narzędzi. Jednak rozwiązanie tego typu zależności sprawi, że życie obu zespołów stanie się łatwiejsze, a ich postępy bardziej efektywne w dłuższej perspektywie, co oznacza, że zwrot z inwestycji jest często imponujący.
Wsparcie organizacyjne
Sposób, w jaki firmy i ich organizacje inżynierskie podchodzą do przeglądów kodu jest dużym elementem wpływającym na to, jak wydajne mogą one być. Organizacje, które postrzegają je jako nieistotne i trywialne, w końcu nie inwestują zbyt wiele w ułatwianie przeglądów. W kulturach takich jak ta, może być kuszące, aby po prostu całkowicie zrezygnować z przeglądów kodu. Inżynierowie opowiadający się za lepszym wykonywaniem przeglądów kodu mogą czuć się odizolowani, bez wsparcia z góry i w końcu się poddać. W rezultacie powstaje organizacja, w której problemy wciąż się powtarzają i nawarstwiają. rganizacje, w których przeglądy kodu przebiegają sprawnie, zapewniają, że wszyscy inżynierowie biorą udział w procesie przeglądu kodu – nawet ci, którzy mogą pracować nad pojedynczymi projektami. Zachęcają do podnoszenia poprzeczki jakości, a zespoły ułatwiają zdrowe dyskusje na temat podejścia do code review zarówno na poziomie zespołu jak i organizacji. Firmy te często posiadają przewodniki przeglądu kodu dla większych baz kodów, które zostały zainicjowane i napisane przez inżynierów. Organizacje takie jak ta, zdają sobie sprawę, że przeglądy kodu zajmują sporą część czasu inżynierów. Wiele z tych firm dodaje przeglądy kodu jako oczekiwania do kompetencji zawodowych programistów, oczekując, że starsi inżynierowie będą poświęcać większą część swojego czasu na przeglądanie kodu innych osób.
Organizacje z lepszymi przeglądami kodu mają twarde zasady mówiące o tym, że żaden kod nie trafia na produkcję bez przeglądu kodu – tak jak zmiany logiki biznesowej nie trafiają na produkcję bez automatycznych testów. Organizacje te nauczyły się, że nie warto iść na skróty; zamiast tego posiadają procesy przyspieszonych przeglądów dla pilnych przypadków. Organizacje te inwestują w produktywność programistów, w tym nieustannie pracują nad bardziej efektywnymi przeglądami kodu i usprawnieniami narzędzi. Pomocnych dyrektorów technicznych nie trzeba przekonywać o korzyściach płynących z przeglądów kodu i innych najlepszych praktyk inżynierskich. Zamiast tego, wspierają inicjatywy dotyczące lepszego oprzyrządowania lub bardziej efektywnych procesów przeglądu kodu, które pochodzą od zespołów.
Gdy ludzie natkną się na recenzje, które wydają się wrogie, czują, że mogą się odezwać i mają wsparcie w rozwiązaniu problemu. Starsi inżynierowie i menedżerowie uważają, że przeglądy kodu, które nie są na najwyższym poziomie, są równie istotnym problemem jak niechlujny kod lub złe zachowanie. Zarówno inżynierowie, jak i menedżerowie czują się upoważnieni do poprawy sposobu, w jaki przeglądy kodu są wykonywane.
Zacznij od dobrego, zrób to lepiej
Dobre przeglądy kodu mają już za sobą wiele dobrego wysiłku. Dokonują dokładnego przeglądu samej zmiany, unikają opiniotwórczego tonu komentarzy i jasno pokazują błędy. Utrzymują spójny pasek, niezależnie od tego, kto prosi o przegląd i starają się, aby przeglądy w różnych strefach czasowych były mniej bolesne, zwracając na to dodatkową uwagę. Organizacje, które mają dobre recenzje zapewniają, że każdy programista regularnie otrzymuje i wykonuje przeglądy kodu. To już jest wysoko postawiona poprzeczka – ale jeśli ją osiągniesz, nie zatrzymuj się. Code reviews to jeden z najlepszych sposobów na doskonalenie swoich umiejętności, mentorowanie innym i uczenie się, jak być bardziej efektywnym komunikatorem.
Dąż do lepszych przeglądów kodu poprzez ciągłe doskonalenie się w szczegółach, ale także zacznij patrzeć na zmiany na wysokim poziomie. Bądź empatyczny w tonie komentarzy i pomyśl o sposobach poza procesem przeglądu kodu, aby wyeliminować częste uszczypliwości. Spraw, aby przeglądy kodu były szczególnie przyjazne dla osób rozpoczynających pracę i szukaj systemowych rozwiązań dla bolesnych przeglądów w różnych strefach czasowych. Organizacje, które wybiegają w przyszłość, zachęcają do inwestowania w narzędzia i usprawnienia procesów, aby uczynić code review lepszym, czerpiąc z tego więcej korzyści.
—
Gergely jest obecnie szefem inżynierii w Amsterdamie. Ten wpis pierwotnie ukazał się na blogu Gergely’ego, The Pragmatic Engineer. Jeśli chciałbyś przeczytać więcej od Gergely’ego, możesz zapisać się na jego comiesięczny newsletter, aby otrzymywać jego artykuły na temat inżynierii, przywództwa technicznego i systemów rozproszonych. Jeśli chciałbyś przyczynić się do powstania artykułów na blogu Stack Overflow, wyślij e-mail na adres [email protected].
Tagi: bulletin, code review, inżynieria, rozwój oprogramowania