Code review – dobre praktyki, wskazówki i kulisy procesu

Code review to jedno z tych pojęć, o których słyszał każdy. Ta technika, ściśle związana z tworzeniem oprogramowania, warta jest poznania przez każdego, kto pracuje w IT.

Ten artykuł jest skierowany do menedżerów technicznych, CTO, programistów i wszystkich, którzy z nimi bezpośrednio pracują. Wyjaśnię, czym jest code review i dlaczego powinno być elementem procesu każdego zespołu deweloperskiego. Następnie wskażę bolączki oraz porady i sztuczki – jak usprawnić proces code review, jak ograniczyć narzut czasowy i łagodzić możliwe konflikty między inżynierami. Zrozumiesz też, jak code review poprawia jakość kodu i jak rozpoznać problemy zespołu, uważnie obserwując, w jaki sposób przeglądy są przeprowadzane.

Czym jest code review?

Zanim wyjaśnię, czym jest code review, muszę przypomnieć podstawowe pojęcia gita (systemu kontroli wersji) – gałęzie i pull requesty. Jeśli znasz już koncepcję code review, możesz przejść do następnej sekcji.

Kiedy programiści wspólnie tworzą nowe funkcje i naprawiają błędy, (miejmy nadzieję) rozwijają swoje zmiany na gałęziach. W gicie gałęzie to osobne „sceny”, na których kod zmienia się bez wpływu na kod na innych gałęziach (np. na funkcjach innych programistów).

Kiedy funkcja jest gotowa, jej autor tworzy tak zwany pull request – czyli zgłoszenie, że pewne zmiany mają zostać scalone z główną gałęzią. Każdy programista tworzy funkcje w izolacji, a na końcu wszyscy próbują scalić je z główną bazą kodu.

Wreszcie code review to proces prowadzony w trakcie otwartego pull requesta, w którym inni programiści sprawdzają kod, komentują zmiany i dyskutują z autorem o proponowanych rozwiązaniach.

Narzędzia do code review – z czego korzystać?

Zwykle programiści używają jednej platformy do przechowywania i utrzymywania repozytorium kodu. Najpopularniejsze narzędzia do code review to Github, Gitlab i BitBucket. Możesz je porównać tutaj. Większość z nich oferuje szeroki zestaw funkcji, a code review jest tylko jedną z nich. Wskazówka: prawdopodobnie chcesz trzymać wszystkie dane związane z kodem w jednym miejscu. Jeśli mieszasz narzędzia, zadbaj o integracje.

Jak robić code review?

Code review to dyskusja. Do tanga trzeba dwojga, więc poza autorem kodu musi być zaangażowany przynajmniej jeden programista – ale oczywiście może, a czasem nawet powinno, dołączyć więcej osób.

Zwykle gdy autor kodu otwiera pull requesta, wskazuje recenzentów, wybierając, kto powinien dołączyć do dyskusji – ci programiści dostają powiadomienie. Oczywiście przegląd można dodać bez zaproszenia – na przykład programista, który ma wolną chwilę, może pomóc innym, dorzucając dodatkowe uwagi.

Platforma do code review pozwala programistom zobaczyć porównanie oryginalnego kodu ze zmianami proponowanymi przez autora. Każdą linię kodu można skomentować, można też dodać komentarze ogólne do pull requesta. Code review może zakończyć się na trzy sposoby:

• Zaakceptowany – gdy kod jest w porządku, a recenzent zgadza się na scalenie zmian
• Odrzucony – gdy recenzent nie zgadza się na scalenie i wymaga zmian w zaproponowanym kodzie.
• Komentarz – gdy recenzent dodaje uwagi, ale nie podejmuje decyzji o scaleniu. Przydatne, gdy pull request jest jeszcze w toku albo programista nie czuje się na tyle kompetentny, by ręczyć za sprawdzany kod.

Code review to dyskusja, więc czasem autor wprowadza żądane zmiany, a czasem się nie zgadza i omawia problem z recenzentem. To działa w obie strony – bywa praktycznym procesem edukacyjnym kończącym się wyższym standardem kodu, a bywa długą i bezproduktywną dyskusją (albo wręcz kłótnią!).

Cel code review

Code review daje kilka korzyści, ale każdy zespół może skupiać się na czymś innym. Zwykle celem jest poprawa ogólnej jakości kodu i zmniejszenie liczby błędów dzięki wymianie wiedzy między autorem a recenzentami. Programiści uczą się też nawzajem, jak pisać lepszy kod i jak rozumieć problemy biznesowe.

Ile czasu zajmuje code review? Czy mnie na to stać?

Przeglądy kodu rzeczywiście potrafią zajmować sporo czasu. Ten proces trzeba doliczyć do estymacji projektu. Podobnie jak przy samym programowaniu, każdemu programiście trudno oszacować, ile to naprawdę potrwa. Czas poświęcony na code review rośnie wraz ze złożonością zadania, tak samo jak implementacja funkcji. Ten narzut da się jednak optymalizować – kilka wskazówek podam w dalszej części artykułu.

Pamiętaj, że z code review jest jak ze zwinnym wytwarzaniem oprogramowania – może się wydawać, że dokładamy czasu, ale zwraca się to później lepszą jakością!

Dlaczego warto wymagać code review w swoich projektach?

Obowiązkowe code review w projekcie daje wiele korzyści. Oto niektóre z nich:

Wcześnie wychwycone błędy

Im dłużej błąd żyje w kodzie, tym trudniej go wykryć i usunąć. Z czasem coraz więcej fragmentów aplikacji może opierać się na wadliwym kodzie, przez co naprawa staje się droższa.

Code review nie wychwyci wszystkich, ale dodatkowa para uważnych oczu widzi to, czego nie widzą inni. Doświadczenie programistów bywa bardzo różne: jeden mógł wcześniej dużo pracować przy, powiedzmy, operacjach na datach, inny będzie doświadczony w animacjach albo wydajności. To bardzo częsta sytuacja, że programista rozwiązał już kiedyś dany problem i po samym spojrzeniu na kod wie, że ta czy inna linia przysporzy w przyszłości kłopotów.

Wyższa ogólna jakość kodu

To ludzka natura, że bardziej się staramy, gdy efekty naszej pracy ocenia ktoś inny. Nikt nie chce uchodzić za niechlujnego albo pozbawionego talentu pracownika, a już zwłaszcza programista! My, inżynierowie, uważamy się za bystrych i chętnie to innym udowadniamy, prawda? Skoro programiści potrafią rozmawiać o programowaniu po godzinach, to z pewnością znajdą czas, by podzielić się opinią, gdy się ich o nią poprosi.

W jaki sposób poprawia to jakość kodu? Recenzenci sprawdzają nie tylko implementację (której poprawa również ulepsza bazę kodu), ale też czytelność („nie rozumiem tego kodu, trzeba go uprościć”) i architekturę („będę potrzebował tego fragmentu logiki, ale nie mogę go użyć, bo jest źle zaprojektowany”). Mogą też zauważyć, że jakiś kod się dubluje („to jest już zaimplementowane *tutaj*, nie pisz tego drugi raz”) albo zestawić kod z wiedzą domenową, która bywa szersza, jeśli recenzent pracuje w projekcie dłużej.

Prawdziwa nauka

Programiści uwielbiają się uczyć. Zmieniają pracę, żeby spróbować nowych technologii, płacą za warsztaty, poświęcają weekendy na czytanie, naukę i hackathony. Dobrze wykształcony programista to nie tylko korzyść dla firmy, ale też – najpewniej – osoba zadowolona.

Moim zdaniem są dwa najskuteczniejsze sposoby nauki kodu – pisanie go i czytanie. Do tego dochodzi nauka na błędach, a przy czytaniu – na cudzych błędach.

Jeśli więc programista dostaje informację zwrotną o swoim kodzie, uczy się na doświadczeniu recenzentów, a często i na ich porażkach. Szybki feedback jest bardzo skuteczny, a programista nie musi zobaczyć awarii na produkcji, żeby stwierdzić, że kod był wadliwy.

Po drugiej stronie jest recenzent, który uczy się przez czytanie. Każdy inżynier ma unikalne doświadczenie i inaczej rozwiązuje problemy. Czasem nawet świetni programiści mają bardzo wąską perspektywę („jak masz młotek, wszystko wygląda jak gwóźdź”), co bywa problematyczne, ale daje się poszerzyć przez kontakt z innymi rozwiązaniami.

Code review to świetne narzędzie nauki dla każdego programisty, ale szczególnie korzystne dla juniorów, którzy potrzebują wsparcia – a to znakomity sposób, by im je zapewnić.

Oczywiście code review nie zastąpi budżetu szkoleniowego i konferencji, ale pośrednio podnosi kompetencje zespołu.

Wskazówka: jeśli programista chce poznać nową technologię, daj mu czas na robienie code review w projekcie opartym o ten stack. Patrzenie na kod produkcyjny jest o wiele lepsze niż nauka z książek po całym dniu pracy.

Wspólny obraz sytuacji

W projektach zwinnych są codzienne spotkania (standupy), a jedną z ich korzyści jest wyjaśnienie zespołowi, co kto zrobił. Te raporty skupiają się jednak głównie na wysokim poziomie i problemach biznesowych.

Przeglądanie pull requestów daje programistom podobny wgląd w rozwijane funkcje, a czytanie kodu idzie jeszcze o krok dalej.

Podczas code review recenzent powinien zapoznać się z wymaganiami biznesowymi (już samo skupienie się na cudzej pracy jest sporą wartością), a później dowie się, jakie nowe moduły ktoś dodał albo usunął. Nawet szybkie spojrzenie na kod, bez zagłębiania się w szczegóły implementacji, jest dla recenzenta korzystne. Jeśli programista A wie o nowej pracy programisty B, może z niej skorzystać bez duplikowania.

Wdrażanie nowych programistów

Zatrudnianie programistów sporo kosztuje – rekrutacja to dopiero początek. Zanim nowa osoba stanie się produktywna i faktycznie „zarobi” na swoje wynagrodzenie, miną tygodnie albo miesiące. Im większy i bardziej skomplikowany projekt, tym dłużej nowy programista będzie rozumiał bazę kodu i biznes, który za nią stoi.

Code review świetnie przyspiesza wdrożenie. Nowy pracownik powinien czytać obecny kod, zadawać pytania i poznawać sposób, w jaki zespół rozwiązuje problemy i prowadzi projekt. Kiedy zacznie tworzyć funkcje, szybka informacja zwrotna od reszty zespołu skróci czas potrzebny na wejście w projekt.

Ujednolicenie zasad i stylu kodu

Lepiej mieć „jakiś” przewodnik po stylu, którego trzymają się wszyscy, niż żeby każdy programista miał własny „idealny”.

Kod bez ujednoliconych zasad i stylu jest bałaganiarski, trudny w czytaniu i kłopotliwy. Ustawienia jednego programisty nadpisują ustawienia drugiego, co zaśmieca zmiany w kodzie i wprowadza niespójność.

Code review to dyskusja, więc jeśli któryś programista prosi o zmianę (np. „nie używaj tabulatorów, użyj czterech spacji”), prośbę powinien omówić zespół. Kiedy zespół uzgodni jeden sposób robienia rzeczy, właśnie stworzył standard, którego można się trzymać.

Im dłużej żyje projekt, tym więcej pojawia się standardów, a kod staje się czytelniejszy – wygląda, jakby napisała go jedna osoba, a nie dziesięć. Więcej standardów ułatwia też wdrażanie nowych programistów!

Podsumowanie

Jak widać, jest mnóstwo dobrych powodów, dla których zespoły deweloperskie powinny wprowadzić code review i się go trzymać. Wciąż jednak pojawiają się pytania – czy ta inwestycja czasu się zwraca? Czy nadal warto robić przeglądy, skoro zajmują dużo czasu, a mój kod pewnie nie będzie aż tak zły, jeśli z nich zrezygnuję?

Zwrot z inwestycji można mierzyć stosunkiem korzyści jakościowych do czasu. Może to brzmi abstrakcyjnie, ale jedno jest oczywiste – im mniejszy narzut czasowy code review, tym lepiej.

Sprawdźmy więc, jak poprawić ten stosunek!

Dobre praktyki code review – jak zapewnić maksymalną efektywność?

Przeglądy kodu bywają długie, to prawda, ale jak każdy proces da się je optymalizować. Oto kilka dobrych praktyk, które można wdrożyć w firmie.

Jak robić code review jak profesjonalista? Sprawdźmy!

Dwóch recenzentów jest lepszych niż jeden

Niełatwo o konsensus, gdy na stole leżą dwie różne opinie, a dwie osoby muszą wybrać jedną z nich. Mimo że informatyka bywa ścisła, mnóstwo problemów ma rozwiązania oparte na bardzo nienaukowych przesłankach i domysłach. Obie strony mogą się spierać, a nawet walczyć o rację. Niewielu programistów ma z tyłu głowy problemy biznesowe (czas!), więc potrafią zmarnować sporo zasobów na jałowe dyskusje.

Innym problemem bywa charakter członków zespołu. Czasem ludzie się frustrują, bo nie potrafią przeforsować swojego zdania wobec kogoś o lepszych umiejętnościach komunikacyjnych.

Rozwiązaniem jest wprowadzenie trzeciego programisty (zwykle drugiego recenzenta), który przechyli szalę i ostatecznie przyzna rację jednej ze stron (albo zaproponuje inne rozwiązanie).

Jeśli masz zasoby, polecam domyślnie dwóch recenzentów; jeśli brakuje czasu programistów, dokładaj kolejnego recenzenta wtedy, gdy trzeba rozstrzygnąć spór.

Warto wspomnieć, że niektóre problemy lepiej pasują do konkretnych osób. Typowa para programistów bywa skuteczniejsza, gdy do audytu kodu zaprosi eksperta z danej dziedziny.

Podsumowując – staraj się mieć dwóch recenzentów albo przynajmniej jednego rezerwowego.

Potraktuj code review priorytetowo

Code review blokuje scalenie funkcji, więc jeśli programista potrzebuje jakiegoś fragmentu kodu do nowej funkcji, może być problem. Wymagane zmiany można ręcznie scalić z nową funkcją przed startem, ale to grozi konfliktami w kodzie; z drugiej strony programista będzie czekał bezczynnie, aż zmiany powstaną.

Jak wiadomo, blokery trzeba znajdować jak najwcześniej i rozwiązywać jak najszybciej, żeby praca płynęła możliwie gładko.

Dlatego kluczowe jest, by programiści zrozumieli, że oczekujące przeglądy (i ogólnie pull requesty) są w istocie ważniejsze niż ich własna bieżąca praca (oczywiście w rozsądnych granicach – krytyczne poprawki są jeszcze bardziej krytyczne). To niełatwy temat, bo programiści bardzo cenią sobie stan skupienia, ale można to zakomunikować tak: niech code review będzie pierwszą rzeczą, którą programista robi, gdy:

• zaczyna pracę rano
• wraca z lunchu
• wraca z przerwy na piłkarzyki / PlayStation / dart
• wraca ze spotkania

Skoro programiści i tak tracą wtedy skupienie, wyrób nawyk, by najpierw sprawdzili, czy nie czeka przegląd od kolegów.

Sprawdzanie nowych próśb o code review nie powinno być trudne – można to zrobić na kilka sposobów. Programista może przejrzeć na Githubie otwarte PR-y ze statusem „Awaiting review from you”. Każdy dostanie też zapewne e-mail z przypisanym przeglądem. Github łatwo połączyć ze Slackiem, żeby każdy otwarty PR trafiał na kanał.

Podsumowując – wytłumacz programistom, jak ważne jest code review. Poeksperymentuj z zasadami skracającymi czas oczekiwania na przegląd.

Ustalcie zasady code review i spiszcie je

Proces code review, jak każdy inny, korzysta na zasadach – zwłaszcza w większych i bardziej złożonych projektach. Więcej programistów w zespole oznacza różnorodne doświadczenia i praktyki. To dobrze, ale czasem spowalnia pracę.

Dlatego każdy zespół powinien ustalić zestaw zasad i je spisać (nie pomijaj tego punktu!). Nie sądzę, żeby standaryzacja procesu w całej firmie dawała wiele, ale zespół pracuje razem na co dzień. Są dwie istotne korzyści:

1. Nowa osoba w zespole musi poznać istniejące zasady. Nie marnuj czasu na tłumaczenie za każdym razem tego samego. Dla nowego jest też frustrujące, gdy poprawia się go wielokrotnie, zamiast pozwolić mu najpierw przeczytać, jak zespół pracuje.
2. W razie konfliktów albo nieporozumień istnieje jedno, żywe źródło prawdy, do którego można się odwołać.

Oto kilka dobrych praktyk code review, które zawsze stosuję i które mogą pomóc usprawnić proces.

• Tylko autor komentarza może go zamknąć – gdy kod poprawiono albo gdy po dyskusji autor uzna, że zmiana jest zbędna.
• Nie zgłaszaj tego samego problemu wiele razy. Nie zaśmiecaj kodu – powiedz raz i poproś o poprawę wszędzie.
• Jeśli są otwarte, nierozstrzygnięte komentarze, odpowiedzialny jest autor kodu, który powinien poprawić albo odpowiedzieć.
• Jeśli w dyskusji odpowiedział autor kodu, odpowiedzialny jest recenzent, który powinien kontynuować rozmowę albo zamknąć komentarze i zaakceptować.
• Używajcie etykiet, żeby oznaczyć kolejny krok – np. „gotowe do przeglądu”, „gotowe do QA” itd.

Częsty problem: autor kodu sądzi, że czeka na przegląd, a recenzent czuje, że czeka na poprawki albo odpowiedź.

Podsumowując – ustalcie zasady, spiszcie je i ulepszajcie z czasem.

Zadbaj o dobre pull requesty

Nieodłączną częścią code review jest pull request. Przegląd dotyczy zmian, które ktoś prosi „wciągnąć” do głównej gałęzi.

Jeśli PR jest dobry, przegląd będzie łatwy i szybki. Jeśli PR jest zły – przegląd będzie męczący, długi i „nikt nie będzie miał na niego czasu”.

Główna zasada dobrego pull requesta: ma być krótki. Dwieście linii kodu łatwo zrozumieć i znaleźć w nich problemy. Dwa tysiące – już nie. Obciążenie poznawcze rośnie wykładniczo wraz z liczbą zmian.

Krótki PR da się sprawdzić przy kawie – długi kosztuje dosłownie wiele godzin, a jakość przeglądu spada, bo recenzent w końcu jest zbyt zmęczony i zdezorientowany, by przez cały czas trzymać poziom.

Dodatkowa wskazówka: dobrze oznaczaj PR-y. Autor powinien zadbać, żeby zgłoszenie było powiązane z systemem ticketowym (Jira itp.) i miało sensowny opis dla recenzentów.

Podsumowując – zadbaj, by programiści poświęcali trochę czasu na przygotowanie dobrego pull requesta, co zwróci się wieloma godzinami pracy przy przeglądach.

Wprowadź audyty code review między zespołami

W dużych organizacjach z wieloma zespołami i projektami z pewnością istnieje mnóstwo podejść do zarządzania pracą zespołów deweloperskich. To świetne pole do poprawy!

Bardziej doświadczony zespół (np. z seniorami) potrafi naturalnie wypracować dobre praktyki, nawet bez pomocy zarządu. To znakomita okazja, by rozszerzyć ich sposób pracy na inne zespoły.

Z drugiej strony można trafić na zespół z agresywnymi komentarzami, długim czasem oczekiwania i zepsutym procesem. Im szybciej się o tym dowiesz i to naprawisz, tym lepiej. Nie licz, że sprawa sama odpowiednio wcześnie eskaluje.

Pomyśl o okresowych audytach wybranych zespołów, żeby ocenić kondycję procesu code review (tak samo jak audytujesz zarządzanie, spotkania scrumowe itd.!). Niektóre zespoły będą miały problemy, inne będą wzorowe. Wykorzystaj tę wiedzę, żeby wymieniać doświadczenia i naprawiać problemy na wczesnym etapie.

Podsumowując – rozważ przypisanie CTO albo innego doświadczonego inżyniera lub menedżera technicznego do audytów codziennych procesów deweloperskich.

Automatyzuj, ile się da

Programiści wolą automatyzację od ręcznych, powtarzalnych zadań. Code review stoi między kodem a człowiekiem, ale mimo to wiele można oddać maszynie.

Ustaw pipeline'y CI

Przede wszystkim PR powinien uruchamiać pipeline CI z testami i buildem. Ten krok trwa kilka minut i wychwytuje mnóstwo problemów, które inaczej musiałby wykryć recenzent. Dobrze napisane testy pokryją wiele kwestii jakościowych, ale bez skonfigurowanego CI ktoś może scalić kod nawet wtedy, gdy testy nie przechodzą.

Połącz narzędzie CI z Githubem i zablokuj możliwość scalenia, dopóki wszystkie sprawdzenia nie przejdą. Nie marnuj czasu programistów na sprawdzanie kodu, który nawet się nie zbuduje.

Ustaw formatery i lintery

Mnóstwo czasu w przeglądach marnuje się na bezcelowe komentarze o tabulatorach kontra spacjach i o tym, jak kto woli pisać kod (a nie o tym, jakie problemy ten kod rozwiązuje). Spójność kodu jest oczywiście ważna, ale nie powinna zapychać procesu przeglądu.

Są narzędzia stworzone do automatyzacji tej pracy, jak Prettier czy ESLint w ekosystemie JavaScriptu albo Rubocop w Rubym. Odpowiadają za stosowanie i raportowanie „przewodnika po stylu” oraz praktyk, o których wspominałem. Im więcej ustawionych reguł, tym spójniejszy kod. Programiści mogą głosować za zmianą istniejących reguł albo tworzyć nowe, ale automat zadba o to, żeby bieżąca praca trzymała się obowiązującego zestawu.

Polecam ustawić formater automatycznie na haku Gita pre-commit (uruchomi się sam) i lintery na haku pre-push (zatrzymają wypchnięcie, jeśli nie przejdzie). Linter powinien działać też w pipelinie CI. Gdy te sprawdzenia przechodzą, recenzent ma znacznie mniej do sprawdzania i może skupić się na rozwiązywaniu problemów.

Wdrażaj gałąź na środowisko testowe

Jeśli masz przyzwoity czas przeznaczony na pracę DevOps, polecam ustawić automatyczne wdrażanie otwartych pull requestów. Zwykle jeśli programista chce sprawdzić, czy kod działa, musi go pobrać i zbudować lokalnie. To zajmuje czas, a bywa też problemem – gdy nową funkcję chce zobaczyć dział QA albo product owner jeszcze przed scaleniem.

Przygotowanie automatycznych wdrożeń PR-ów kosztuje czas na start, ale pozwoli zespołowi – także osobom nietechnicznym – szybko sprawdzać bieżącą pracę.

Dodatkowe wskazówki od zespołu Ideamotive

Commituj często i publikuj PR-y w toku

Złą praktyką jest czekanie całymi dniami, zanim pokaże się jakąkolwiek pracę. Zachęcaj do częstego commitowania i wypychania zmian. To nie tylko zabezpieczy pracę na wypadek utraty kodu lokalnie (kradzież, zepsuty sprzęt), ale też podniesie produktywność zespołu. Otwarcie gałęzi „w toku” pozwoli innym ocenić ogólną koncepcję zmian, a nie tylko śledzić implementację. Jest to szczególnie ważne przy juniorach, gdy recenzent po kilku linijkach może powiedzieć, że to po prostu zły kierunek. Lepiej usunąć 50 linii kodu niż 500 albo 5000.

Wybieraj recenzentów, którzy znają temat

Raczej nie ma sensu prosić frontendowca o sprawdzenie kodu backendowego. Jeśli zespół jest na tyle duży, by wybierać recenzentów, to świetny sposób na poprawę jakości kodu. Jedni lepiej rozumieją domenę, inni specjalizują się w wąskich problemach technicznych. Lepiej sprawdzą się tam, gdzie mogą dać dużo wartościowej informacji zwrotnej.

Nowoczesne serwisy gitowe ułatwiają to, wykrywając i podpowiadając odpowiednich recenzentów na podstawie historii zmian albo właścicieli kodu.

Umów spotkanie na żywo przy dużych zmianach

Jeśli pull request jest ogromny (nie powinien, ale się zdarza), odbijanie piłeczki w setkach komentarzy online potrafi kosztować mnóstwo czasu. W takim wypadku lepiej umówić spotkanie przy biurku, na którym autor wyjaśni pozostałym zmiany.

Jak ograniczyć konflikty podczas code review?

Code review, jak każda dyskusja, może rodzić konflikty między programistami. Opiera się też na dawaniu informacji zwrotnej, co jest trudne zarówno dla recenzenta (żeby zrobić to z empatią), jak i dla autora (żeby przyjąć krytykę).

Prawdopodobieństwo konfliktu zależy oczywiście w dużej mierze od charakteru poszczególnych osób, ale jeśli już do niego dojdzie, jest kilka zasad, jak ograniczyć go na przyszłość.

Spisujcie jak najwięcej

Konflikty rodzą się, gdy na stole są dwie różne decyzje, a żadna ze stron nie chce ustąpić.

Wiele decyzji zostało już jednak podjętych – tylko zaginęły w czasie. Wspominałem wcześniej o przewodniku po stylu kodu – to znakomity przykład, bo nikt nie będzie się spierał o „tabulatory kontra spacje”, jeśli zostało to oficjalnie ustalone i zapisane w dokumentacji projektu.

Taką dokumentację można tworzyć na różne sposoby. Lubię narzędzia w rodzaju Notion do budowania i utrzymywania stron typu wiki z decyzjami biznesu albo zasadami ustalonymi przez programistów.

Do takiego dokumentu można się odwoływać w trakcie przeglądów, żeby unikać niepotrzebnych konfliktów.

Ucz, jak dobrze robić code review

Istnieją zasady, jak przeprowadzać przegląd, żeby osiągał swoje cele. Nie każdy programista jest ich świadomy.

Przegląd powinien opierać się na faktach, nie domysłach. To nie miejsce na sprawy osobiste – liczy się wyłącznie zmiana w kodzie i jej wpływ na projekt.

Każdy komentarz z informacją zwrotną powinien zawierać wyjaśnienie („to jest złe, ponieważ…”) i propozycję lepszego rozwiązania („może spróbuj tak: …”). Dodatkowe punkty za podlinkowanie źródeł zewnętrznych, np. dokumentacji, żeby autor kodu mógł się na przyszłość nauczyć.

I najważniejsze – programiści muszą rozumieć, że mają wspólny cel: najlepszy kod, jaki potrafią napisać. To nie jest miejsce na ego ani na rywalizację o to, kto jest lepszym inżynierem.

Wprowadź dodatkowego programistę do rozstrzygania sporów

Gdy trwa spór, w którym dwóch programistów nie może się dogadać, można zaprosić trzeciego, żeby przechylił szalę i rozwiązał problem. Ten dodatkowy inżynier to nie tylko kolejna opinia, ale też mediator między skonfliktowanymi stronami.

W jaki sposób kod staje się lepszy dzięki code review?

Wymieniłem wiele powodów, dla których code review skutecznie podnosi ogólną wydajność zespołu. A jak wpływa na istniejącą bazę kodu?

Code review to miejsce dyskusji, która dobrze poprowadzona powinna kończyć się działaniami. Jednym z nich jest ujednolicony zestaw zasad, który można później sprawdzić w całej aplikacji.

Dzięki code review programiści są na bieżąco ze zmianami w projekcie, więc nie zdziwią się, „skąd to się wzięło”. Będą wiedzieć, że dodano jakieś funkcjonalności i że mogą je później wykorzystać bez duplikowania. Zrozumieją też, co jest wycofywane i co refaktoryzowane, więc będą się do tego stosować.

Podczas code review wiele umysłów łączy siły, żeby stworzyć najlepsze rozwiązania. Jeden programista nie będzie świetny w każdym obszarze, ale dzięki informacji zwrotnej od innych kod może być znacznie lepszy niż na początku.

Jak rozpoznać po przeglądach, że coś jest nie tak?

Zawsze zachęcam, żeby analizować, monitorować i wyciągać wnioski z każdych danych, jakie mamy – łącznie z procesami.

Pull requesty z przeglądami dostarczają informacji, którymi można się kierować, żeby usprawniać pracę i sprawdzać kondycję zespołu.

Polecam obserwować przynajmniej kilka wskaźników:

• jak długo PR jest otwarty
• ile czasu mija między otwarciem PR-a a rozpoczęciem przeglądu
• jak długo trwa przegląd
• ile czasu mija między zaakceptowaniem PR-a a jego scaleniem
• jaki jest stosunek czasu przeglądu do wielkości pull requesta

Idealny scenariusz to oczywiście taki, w którym przegląd zaczyna się dość szybko po otwarciu PR-a (w kilka godzin), otwarty przegląd trwa nie dłużej niż kilka dni (to nie tylko dyskusje, ale też poprawki, testy itd.), a scalenie następuje natychmiast po akceptacji.

Obserwując to w czasie, zobaczysz, jak jedne czynniki zmieniają się względem innych. Może przeglądy zaczęły trwać długo, bo pojawił się nowy programista, który daje dużo uwag? Wtedy warto sprawdzić, czy ta informacja zwrotna jest wartościowa (co oznaczałoby, że kod wcześniej był słaby), czy to zwykłe czepianie się?

Jeśli rośnie czas między otwarciem PR-a a przeglądem, może funkcji jest za dużo i programiści nie mają kiedy sprawdzać cudzego kodu? A może PR-y zrobiły się zbyt duże i nikomu się nie chce?

Długi czas między przeglądem a scaleniem może z kolei oznaczać zepsuty proces wdrożeniowy.

Ogólnie – im więcej danych, tym więcej wniosków i tym szybciej można się poprawiać. Polecam monitorować jak najwięcej procesów; przeglądy i pull requesty to tylko mały przykład.

Podsumowanie

I… to tyle! Mam nadzieję, że wykorzystasz tę wiedzę, by wdrożyć u siebie dobre code review albo ulepszyć istniejące. Szczerze mówiąc, są też głosy przeciw przeglądom, ale każda firma jest inna i nie ma innej drogi niż eksperymentować, wyciągać wnioski, poprawiać i eksperymentować dalej.

Wyślij ten artykuł zarówno menedżerom, jak i programistom, żeby efekt był największy!

Źródła i materiały dodatkowe

Why code reviews matter (and actually save time!)

Why Review Code?

Good Code Reviews, Better Code Reviews

10 Reasons Why Code Reviews Make Better Code and Better Teams

Google Engineering Practices Documentation