Code review, peer review – o co chodzi i jak zrobić to dobrze?

Code review jest ogólnie polecaną praktyką. Jest z nią taki sam problem jak z wieloma innymi dobrymi procesami… każdy ją chwali, ale zasakująco mało dobrze stosuje. Jeśli jednak uda nam się poprawnie wdrożyć code review, rezultaty mogą być znakomite.

Przed wszystkim, czym jest code review?

W wielkim skrócie, code review (zwane też peer review) oznacza proces przeglądania kodu w celu szukania potencjalnych błędów. Możemy wydzielić dwa główne rodzaje sprawdzania:

Przeglądanie istniejącego kodu

W ten sposób kod przeglądany jest raczej rzadko. Zazwyczaj jeśli jest potrzeba naprawy konkretnego błędu. Zwykle tej czynności nie nazywamy terminem “code review”.

Przeglądanie zmian przed scaleniem ich z resztą kodu

Jeśli temat code review jest podnoszony, to właśnie o ten typ sprawdzania chodzi. Mówi o czymś, co oficjalnie nazywa się “regular change-based code review”. W wielkim skrócie, jest to przegląd zmian, zanim zostaną scalone z resztą kodu. W reszcie artykułu skoncentruje się na tym rodzaju code review. Proces ten dominuje w dzisiejszym IT i są ku temu świetne powody.

Dlaczego przeglądy kodu są takie ważne i co nam dają?

Plusów płynących z tej praktyki jest cała masa. W tym temacie można by napisać oddzielny artykuł : ) Postaram się przybliżyć najważniejsze rzeczy:

Wzrost jakości kodu!

Jest to największy i najważniejszy efekt code review. Spojrzenie kolejnej osoby/osób na ten sam kod ujawnia znacznie więcej defektów, niż autor jest w stanie wykryć. W szczególności chodzi to o zgodność z praktykami i prostotę (pamiętajmy, że KISS jest królem!). Wzrost jakości kodu jest na tyle dramatyczny, że code review stał się wręcz nieodłącznym elementem każdego projektu dbającego o jakość swojego kodu.

Mniejsza ilość błędów.

Code review zmniejsza też ilość późniejszych błędów wymagających późniejszej poprawki. Błędy programistyczne mają różnoraką naturę. Jeden pomylony znak potrafi całkowicie zmienić zachowanie kodu. Często błąd oczywisty dla przeglądającego jest kompletnym zaskoczeniem dla autora kodu.

Wymiana wiedzą.

Sam fakt spojrzenia na kod z innego obszaru powiększa wiedzę przeglądającego. Rozszerza jego horyzonty o to, co robią inni programiści. Fakt ten może pomóc nawet w zarządzaniu projektem. Autor kodu też ma się dużo do nauczenia. Brak znajomości praktyk stosowanych w aplikacji zostanie bardzo szybko wyłapany. Z pewnością powoduje to duży wzrost tempa rozwoju młodych programistów.

Brak “ninja commitów” i lepsza samokontrola.

Sam fakt występowania procesów peer review, zmienia podejście do commitowanego kodu. Nie chcemy wypadać źle przy przeglądających, więc automatycznie dbałość pracy wzrasta. Nie możemy sobie pozwolić też na coś, co potocznie nazywamy “ninja commit”. Jest to nieudokumentowana i samowolna zmiana w kodzie, która zwykle ma naprawić jakiś problem. Taka praktyka kończy się często bardzo nieprzemyślanymi zmianami. Taki kod jest zwykle pisany na kolanie i ma ogromny potencjał do powodowania kolejnych problemów.

Code review idealnie wpasowuje się w styl pracy z repozytorium.

Przy używaniu któregokolwiek z nowoczesnych narzędzi do zarządzania zmianami, code review dostajemy w standardzie. Przeglądanie zmian jest idealne na etapie pull request (czasami zwanymi merge request). Dzięki temu możemy obejrzeć zmianę bez scalania jej z główną gałęzią kodu. Schemat ten jest naturalny i zintegrowany z resztą procesu. Dzięki temu wprowadzenie code review staje się banalne.

Czy są jakieś minusy code review?

Code review jak każda inna praktyka powoduje konkretne koszty. Jest dla mnie oczywiste, że pod żadnym pozorem nie przewyższają one plusów. Tak, czy inaczej warto o nich wiedzieć:

Code review zżera czas innych programistów.

Jest to oczywista prawda. Z pewnością trzeba przeznaczyć pewną ilość czasu na przegląd i warto mieć to na uwadzę.

Code review musi być wykonane przez doświadczonych programistów.

Rzeczywiście, nie możemy zlecić tej pracy młodemu programiście. Wysokie wymagania umiejętności mocno ograniczają ilość programistów zdolnych wykonywać to zadanie.

Nie lubię robić code review!

W praktyce mało kto lubi wykonywać code review. Wymaga to dość dużo wysiłku intelektualnego, bo musimy wejść w buty innych. Wymagane jest zrozumienie logiki w kodzie innej osoby. Nie ma też satysfakcji z tworzenia, co jest moim zdaniem głównym źródłem motywacji programistów.

Kolega z teamu czepia się złośliwie mojego kodu!

Może ciężko w to uwierzyć, ale code review może stać się areną rywalizacji programistów. Zbyt paranoiczne poprawianie nawet najmniejszych niedoskonałości kodu może poważnie zdenerwować. Niestety lider teamu musi nieustannie monitorować sytuację i reagować jeśli którykolwiek z członków teamu bierze do siebie wyniki procesu. Trzeba pamiętać, że team gra do jednej bramki. Żadne “fochy” wynikłe z powodu code review nie mają sensu.

Tips and tricks – jak wykonywać dobrze code review.

Jeśli jesteś po stronie autora, to twoim zadaniem jest po prostu zrobienie super kodu : ) To co mogę podpowiedzieć:

  • ZAWSZE przejrzyj jeszcze raz kod po utworzeniu merge requesta/pull requesta do review, żebyś miał pewność co w rzeczywistości przeglądający zobaczą
  • podziel każdą zmianę na możliwie najmniejsze logiczne commity, im mniejsze tym łatwiej je się przegląda
  • pytaj się starszych kolegów, jeśli nie jesteś pewien czegokolwiek, lepiej się zapytać niż wycofywać, czy przerabiać zmianę

Jeśli jesteś przeglądającym kod, to musisz uważać na kilka rzeczy:

  • przede wszystkim – nie śpiesz się, na spokojnie zrozum każdą zmianę, pamiętaj że jesteś ostatnią zaporą w drodze kodu do głównego repozytorium
  • nigdy nie odkładaj wykonania review, ta czynność powinna mieć większy priorytet niż standardowe zadania, gdyż może blokować wprowadzanie zmian
  • staraj się wykonać od razu przegląd całej zmiany w jednym bloku czasowym(chyba, że jest większa niż ~400 linii i nie da się jej podzielić), zmiany kontekstu mają wielki wpływ na wydajność
  • nie wahaj się od razu odrzucać zmiany, które są za duże, czy za skomplikowane, proś od razu o refactor/podzielenie
  • nie trać nigdy czasu na zmianę, która z pewnością będzie poprawiana, lepiej od razu ją odrzucić i dać autorowi czas na poprawki
  • jeśli narzędzie do przeglądu kodu pozwala na komentowanie, używaj tej funkcjonalności do wyjaśnienia wszelkich niejasności
  • NIGDY nie odnoś się do osoby wytykając błędy w kodzie (np. “źle napisałeś…”), zawsze używaj form bezosobowych (“trzeba poprawić…”), taka forma brzmi znacznie profesjonalniej i nie budzi negatywnych emocji

Podsumowując…

Code review może jest potężnym narzędziem w walce o jak najlepszy kod. Ciężko wyobrazić sobie przykład projektu, w którym porządny code review nie przyniesie dużych plusów.

Leave A Comment