Code review –  dlaczego warto praktykować i jak idealnie zaplanować przegląd kodu?

Weryfikacja kodu to nie jest czas zmarnowany. Wynikiem działania kodu są funkcjonalności, które zapewne zostaną zweryfikowane i przetestowane przez testerów. Jednakże sam kod również musi zostać sprawdzony. Taka weryfikacja to najlepszy sposób na podniesienie jakości i czytelności kodu. Sprawdzenie kodu przez innego dewelopera pozwoli na upewnienie się, że żaden z aspektów odnośnie dobrego programowania nie zostanie pominięty, a może się to zdarzyć nawet najlepszym.

Code review to również idealny sposób na sprawdzenie defektów kodu. W ten sposób można przeprowadzić testy statyczne, które nie zastąpią testów dynamicznych, ale mogą na początku również odsiać część błędów.

Przeglądanie pracy innych programistów przez członków zespołu pozwoli także na poszerzenie wiedzy. Dodanie do code review m.in. osób z mniejszym doświadczeniem i znajomością zagadnienia jest jednym ze sposobów na poznanie szczegółów danego projektu i wdrożenie nowych ludzi do zespołu.

W wielu przypadkach przejrzenie kodu przez inną osobę, nawet spoza projektu, jest idealnym sposobem na poszerzenie horyzontów. Dzięki temu możemy dowiedzieć się o alternatywnych drogach  na rozwiązanie palącego nas problemu.

Code review wymaga czasu zarówno osoby piszącej kod, jak i osoby weryfikującej go. Warto pamiętać, że ten czas nie należy traktować jako okres całkowicie bezpłodny. W tym celu deweloperzy powinni uwzględniać czas przeznaczony na code review w swoich planach, dotyczy to osób tworzących kod,jak i te które go weryfikują. Wg badań w samym Microsofcie ponad 60% deweloperów robi przynajmniej raz dziennie komuś code review. Ten czas trzeba zaplanować i zarządzać nim, aby nie tracić czasu na zmianę „kontekstu”. Jednocześnie warto doceniać code review i osoby weryfikujące, gdyż wpływa to bezpośrednio na jakość kodu w projekcie. Ciężko jest wymagać wysokiej jakości code review, nie doceniając osób go wykonujących.

Warto nadmienić, że proces code review nie może trwać bardzo długo. W tym czasie osoba, której kod jest weryfikowany, może wziąć kolejne zadania, ale komfort prac będzie zapewne zachwiany. Z badań Microsoftu wynika, iż zbyt długie sprawdzanie kodu może u osoby weryfikowanej wpłynąć negatywnie zarówno na satysfakcję z wykonywanej pracy, jak i na produktywność.

Przed przekazaniem kodu do code review ważne jest to, aby odpowiednio przygotować się do tego procesu. Wybór odpowiedniej osoby do weryfikacji pozwoli na uzyskanie najbardziej wartościowych informacji zwrotnych, o czym będzie dalej.

Przed przekazaniem kodu do oceny warto przejrzeć go samemu. Nie ma nic gorszego niż, weryfikacja kodu z trywialnymi  błędami, które można uniknąć szybkim spojrzeniem w kod. Warto jeszcze przed commitem prześledzić co zmieniliśmy, gdyż czasem może się okazać, że niechcący dokonaliśmy niechcianej zmiany.

Kolejną rzeczą jest uruchomienie testów. Pozwoli to szybkie sprawdzenie zmian pod kątem działania zgodnego z wytycznymi w testach. Obecnie wiele narzędzi do code review samo uruchamia testy przed przekazaniem kodu do sprawdzenia.

Krótki opis zmian lub podpięcie zadania ze szczegółowym opisem pomoże osobie weryfikującej na szybsze zaznajomienie się z kodem. W razie potrzeby można również dodać dodatkowe elementy przydatne deweloperowi oceniającemu naszą pracę. Może być to np. zrzut ekranu systemu ze zmianami w GUI, jakie zostały dodane poprzez nasz kod w ocenianym zadaniu.

Warto również uzbroić się w cierpliwość i wyrozumiałość. Wielu deweloperów traktuje napisany kod niemalże, jak swoje dziecko. Nie jest to do końca zdrowe podejście. Kod ewoluuje z czasem, więc nie warto walczyć zaciekle, a przyjąć konstruktywną krytykę i w razie potrzeby dokonać zmian.

Proces przeglądania kodu to finalnie zgłaszanie uwag i komentarzy. Jakość tych zgłoszeń zależy od kilku czynników i powinniśmy dążyć do jak najwyższego poziomu w dostarczaniu informacji zwrotnej dla programisty, który przechodzi przez proces code review.

Oprócz zarezerwowania czasu na code review, o którym piszę wyżej, ważny jest także dobór osób do weryfikacji. Powinni być to pracownicy z doświadczeniem w danej części projektu. Mogą oni często przekazać ciekawe i czasem unikalne informacje odnośnie zagadnienia, które wpłyną bezpośrednio na sprawdzany kod. Dobrym pomysłem jest również dodanie do code review seniorów.

To oni mają szersze spojrzenie na cały projekt, a także większe doświadczenie w pracy z podniesieniem jakości kodu. W wielu przypadkach weryfikacji może dokonywać także osoba spoza danego zagadnienia czy z innego projektu w firmie. Świeże spojrzenie na kod w wielu przypadkach pomaga na nieszablonowe podejście do danego fragmentu tworzonej aplikacji.

Olbrzymi wpływ na jakość informacji zwrotnej do twórcy kodu ma jego ilość. Nie od dziś wiadomo, że im mniej kodu, tym więcej zgłoszonych uwag. Duże ilości kodu do weryfikacji powodują zaś mniejsze zaangażowanie i większe prawdopodobieństwo na ominięcie ważnych aspektów w kodzie. Ilość zgłaszanego kodu do weryfikacji nie powinna być duża i warto dzielić go na mniejsze „paczki”.

Osoba oceniająca powinna uwagi zgłaszać jak najbardziej konstruktywne i jasne w zrozumieniu. Nie warto tracić czasu na zgłaszanie uwag do kodu niezwiązanego ze zmianami. Także komentarze o kodzie, który dopiero będzie tworzony są również zbędne. Pochwały i gratulacje również nie powinny mieć miejsca przy uwagach od recenzenta.

Proces code review nie może odbyć się bez dedykowanych ku temu narzędzi. To one pozwalają na komfortowe zgłaszanie uwag i śledzenie procesu weryfikacji. Do dyspozycji jest wiele narzędzi, które pozwalają na zautomatyzowanie wielu elementów code review i uprzyjemniają proces zarówno od strony recenzenta, jak i osoby ocenianej. Mogą być to narzędzia tworzone wewnątrz firmy, jak i dedykowane platformy jak chociażby Collaborator czy GitLab.

Dobre platformy do code review powinny być szybkie i pozwalać na proste śledzenie cyklu procesu weryfikacji. Niezmiernie ważnym jest także integracja z innymi platformami, szczególnie w kwestii zarządzania branchami, testami czy automatycznymi narzędziami do weryfikacji statycznego kodu. Wybrane narzędzie powinno mieć również możliwość ustawienia kilku recenzentów czy chociażby blokowanie merga bez akceptacji oceniających.

Oczywiście prócz samych komentarzy warto, aby oceniający i autor kodu mogli się komunikować również nieformalnie. Nie ma znaczenia, czy będzie to czat w samym narzędziu do code review, czy jedno z rozwiązań zewnętrznych jak Skype, Hangouts czy Slack. Liczy się to, aby finalnie, w krytycznym momencie, mogło dojść do spotkania „twarzą w twarz”.

W wielu przypadkach programowanie może odbywać się w parach. Wówczas wiele osób uznaje, że code review jest robione na żywo, w trakcie kodowania i nie trzeba sprawdzać kodu ponownie. Jest to prawdą, ale często code review robione w ten sposób nie do końca się sprawdza. Największym problemem jest to, iż osoby pracujące w parach i oceniające sobie kod są stanowczo zbyt „blisko” zagadnienia i samego procesu tworzenia kodu, aby wykryć w nim ułomności. Dodatkowo problematyczne staje się programowanie w parach, w przypadku osób pracujących w różnych miejscach i czasie, co jest bardzo powszechne w firmach IT. Wadą może być także to, iż nie zostaje żaden ślad po tak robionym code review, coś co pozwoli na zweryfikowanie spostrzeżeń czy zmian w analizowanym kodzie.

Proces code review nie jest lekarstwem na wszystkie problemy w wytwarzaniu oprogramowania. Nie zastąpi QA i nie sprawi, że kod będzie wolny od błędów, a każdy deweloper posiądzie szybko wiedzę tego co się dzieje w projekcie. Pozwoli on jednak na chociaż częściową propagację informacji, umożliwi zadbanie o dobre praktyki w kodzie, czy wykryje podstawowe błędy w statycznej analizie kodu. Code review może wydawać się bolesne, gdyż zajmuje czas, a deweloperzy są cięgle poddawani krytyce. Nie warto jednak powielać takich przesądów. Proces weryfikacji kodu jest świetnym sposobem na tworzenie prostych w utrzymaniu aplikacji, w których z przyjemnością będzie się kodować.