Code review to jeden z najlepszych sposobów, aby pomóc zespołowi upewnić się, że pisze najlepszy możliwy kod. Daje możliwość nie tylko wyłapania błędów, ale również przedyskutować wprowadzane zmiany, dając wszystkim członkom zespołu możliwość zapoznania się z nowymi funkcjonalnościami.

Z jednej strony code review wydawać się może zbędnym wysiłkiem w sytuacji gdy aplikacja jest pokryta testami TDD. W tej sytuacji możemy bez większych przeszkód zmieniać kod lub dopisać jego nowe elementy wraz z kolejnymi testami, które obrazują jak oczekujemy, aby kod działał. Uruchamiamy testy i w jednej chwili wiemy czy aplikacja działa lub nie.

Z drugiej strony jako autor kodu zawsze stawiam pewne założenia dotyczące sposobu działania systemu i czego użytkownik potrzebuje, dlatego przegląd kodu przez drugiego programistę daje szanse wyłapania błędów logicznych lub problemów strukturalnych, których komputer nie może zobaczyć. Dodatkowo osoba wykonująca code review zaznajamia się z fragmentem systemu, nad którym może aktualnie nie pracować i w sytuacji kryzysowej dokonać niezbędnych poprawek lub zmian.

W niniejszym artykule chciałbym podzielić się paroma praktykami, w którym code review przebiega płynnie niezależnie po której stronie procesu oceny stoimy.

1. Nie karz. Celem code review jest powstanie najlepszego możliwego kodu. Staramy się być pomocni i upewniajmy się, że komentarze nie wydają się oskarżycielskie.

2. Zadawaj pytania. Należy zadawać pytania odnośnie wszystkiego, czego nie mamy pewności. Kod jest jasny dla autora, niemniej dla recenzenta duże partie kodu nie zawsze bywają oczywiste. Dzięki pytaniom i odpowiedziom uzyskujemy większą klarowność nad daną funkcjonalnością. W zespole pracujemy razem. Kompromis wymaga rozmowy i zrozumienia.

3. Nikt nie jest właścicielem kodu. Staramy się unikać sytuacji „własności kodu”. Gdy któryś z członków zespołu przypisuje własność kodu, wówczas staje się mniej podatny na sugestie i zmiany sądząc, że pierwotna wersja jest doskonała.

4. Przekaż pełną recenzję. W trakcie code review przeglądamy cały kod, a nie skupiamy się wyłącznie na fragmentach lub klasach. Jeśli czegoś nie wiemy… patrz pkt. 2. W przeciwnym wypadku narażamy autora na wykonywanie bezproduktywnych poprawek tylko dlatego, że recenzent nie przejrzał całego kodu.

Reasumując, staramy się nie tylko patrzeć na składnie kodu, ale także na jego architekturę. Przekazujemy własne opinie i sugestie dochodząc wspólnie do jak najlepszych rozwiązań.

W internecie oczywiście jest wiele tipów i praktyk code review. Najlepiej znanym jest artykuł na gitlabie: https://gitlab.com/help/development/code_review.md niemniej mam nadzieje, że i nasze drobne sugestie przekonają czytelnika o pozytywnych aspektach niniejszego procesu.

Autorem tekstu jest Marek Rode.