Kod review - jak to robić dobrze?
Kod review - jak to robić dobrze?
2020-02-01

Kod review - jak to robić dobrze?

Tomasz Rogalski

Kod review (CR) - dla niektórych zmora dla innych niepotrzebna rzecz, jeszcze inni powiedzą że zwalnia proces developmentu. W każdym z tych stwierdzeń jest trochę prawdy i to niestety prawdy negatywnej. A co powiecie gdybym powiedział wam że CR może być źródłem wiedzy, motywacji zespołu i przyśpiesza proces rozwoju aplikacji?

Dla naprawdę niewtajemniczonych, bardzo prosta definicja kod review - jest to proces mający na celu wykrycie błędów popełnionych w kodzie w trakcie tworzenia oprogramowania, co za tym idzie poprawienie jakości tworzonego produktu.

W tym artykule skupię się bardziej na teoretycznej jak i psychologicznej stronie zagadnienia. Techniczna część pojawi się w innych artykułach.

Po co to robić

Głównym celem przeglądania kodu jest zwrócenie uwagi jego jakość. Niezwykle ważne jest spójność z ogólno przyjętymi lub wewnętrznymi standardami, dzięki czemu nowo dołączająca osoba będzie miała poczucie że kod pisała jedna osoba.  Taki kod jest potem łatwiejszy do utrzymania i ewentualnych zmian. Nie mam tutaj na myśli dobrych edytorskich standardów bo to za nas powinien wykonać ESLint, my powinniśmy skupić się na aspektach architektonicznych, strukturze kodu oraz stosowanych wzorcach projektowych, jego czytelności i wydajności.

W swojej pracy często natrafiam na nieczytelny kod. Nie chcę się tutaj rozwodzić na tym co to oznacza że kod jest czytelny lub nie ale odsyłam do świetnej książki Roberta C Martina “Clean Kod” (“Czysty Kod”). Pokrótce powiem że jeżeli nie potrafisz przeczytać ze zrozumieniem co dana linijka wykonuje to znaczy że kod jest zbyt skomplikowany.

Drugim bardzo bardzo ważnym aspektem jest znalezienie ewentualnych błędów. To zadanie stawia przed przeglądającym kod trudne wyzwanie. Aby znaleźć błąd patrząc się tylko na kod trzeba mieć duże doświadczenie i sporo praktycznej wiedzy. Jest to zadanie trudne i nie zawsze kończy się sukcesem. Nawet najsprawniejsze oko czasami nie dostrzeże ukrytego błędu. Jak się uchronić przed taką sytuacją? Pogódź się z nią nie wychwycisz wszystkiego. Błędy powinny być też wyłapywane przez testy automatyczne i to po to programiści je piszą.

Podsumowując tą część uważam że ważniejszy jest pierwszy aspekt czyli struktura, architektura i szeroko pojęta jakość kodu.

Aspekt psychologiczny

Każdy artysta, rzemieślnik, i tutaj na równi postawię też programistę, gdyż uważam że to taki nowoczesny rzemieślnik, stara się aby jego produkt był najwyższej jakości. Często w związku z tym utożsamia się osobiście ze swoim dziełem i wiąże się z nim emocjonalnie. Gdy robisz komuś code review musisz pamiętać o tym że możesz kogoś nieświadomie urazić krytykując jego dzieło.

Postawmy się teraz w roli twórcy oprogramowania. Staraliśmy się wykonać naszą pracę najlepiej jak potrafiliśmy a teraz nas ktoś krytykuje i uważa że nasze pomysły są złe. Jak znaleźć tą granicę pomiędzy przeglądającym a twórcą aby wszyscy się dobrze zrozumieli. O tym więcej w dalszej części ale tutaj taka moja rada. Gdy piszesz komentarz do czyjegoś kodu to staraj się aby to było konstruktywne i asertywne. Używanie sformułowań że ta część kodu jest po prostu zła albo że tak się nie pisze nie jest dobrym komentarzem. Uzasadnij dlaczego coś jest złe i zaproponuj jak to zrobić inaczej. Wrzuć ciekawy artykuł na ten temat aby poszerzać wiedzę. Wtedy ta osoba czytając dodatkową, postronną opinię na dany temat zrozumie sama że źle zinterpretowała tą część kodu i dodatkowo będzie mieć satysfakcję ze czegoś nowego się nauczyła. 

Gdy jesteś twórcą kodu schowaj dumę do kieszeni i nie traktuj tego jako atak na Ciebie bo to tylko kod. Sprawdź co napisał przeglądający i jeżeli miał rację podziękuj za to że czegoś Cię nauczył a jeżeli się z nim nie zgadzasz to niech to będzie konstruktywne, podeprzyj się artykułem lub przykładami.