Code review – jak utrzymać porządek w kodzie

code review

Jeśli czytasz wpisy na bieżąco, z pewnością trafiłeś na ten o elementach pracy programisty i wiesz z niego, że programowanie to tylko część obowiązków jakie na nas spoczywają. Ten zawód niesie za sobą o wiele więcej wyzwań, przez co jest różnorodny i ciężko w nim o nudę. Jednym z zadań, które powierza się developerom jest prowadzenie code review i to właśnie o tym poczytasz w dzisiejszym artykule. Lecimy!

Czym jest code review?

Inspekcja kodu (ang. code review) to proces, który ma na celu sprawdzenie zmian wprowadzonych przez programistę przed dołączeniem ich do systemu kontroli wersji. Aby całość miała sens, musi przeprowadzać je co najmniej dwie osoby. Sprawdzany, który zakłada (prosi o) code review, będący jednocześnie autorem kodu oraz sprawdzający. Zwykle jest to osoba z większym doświadczeniem i wiedzą o projekcie i programowaniu. Głównymi założeniami code review są poprawa jakości wytwarzanego oprogramowania i usunięcie błędów. Jak to jednak w życiu bywa, z tego procesu można wycisnąć znacznie więcej, szczególnie dla pojedynczego developera.

Zalety code review

Inspekcja kodu ma wiele zalet. Dla wszystkich nieprzekonanych do potęgi tego procesu, postaram się je pokrótce opisać.

Dbałość o wysoką jakość aplikacji

Standard. Główny cel i misja code review. Pozwala ono na weryfikację kodu, wyłapanie jego słabych stron i zastąpienie lepszą wersją. Jak wspomniałem wcześniej – to już na tym etapie wytwarzania oprogramowania można wyłapać błędy, których programista po prostu nie zauważył. Code review pozwala też dostosować kod do wzorców projektowych, czy praktyk programowania przyjętych w projekcie lub firmie, co zwiększa spójność rozwijanej aplikacji.

nauka

Szybka nauka

Jest to prywatna opinia, wynikająca z moich doświadczeń jako developer, ale z czystym sumieniem mogę stwierdzić, że code review to proces, z którego bardzo dużo się nauczyłem i ciągle to robię. Nie jest to oczywiście regułą i w dużej mierze zależy od osób współuczestniczących. Rewizję można przeprowadzać byle jak, robiąc z tego sztukę dla sztuki lub bardzo rzetelnie – poświęcając na to odpowiednią ilość czasu i zaangażowania. Ja miałem szczęście uczestniczyć w drugim typie code review i mogę powiedzieć, że wiele się wtedy nauczyłem. Przyspiesza ono zdobywanie wiedzy dotyczącej samej aplikacji nad którą się pracuje – możesz nie wiedzieć, że zmieniając jeden plik trzeba wprowadzić zmiany w innym albo że do określonych zadań jest już przygotowana klasa, a Ty stworzyłeś nową, niepotrzebną. Zdobędziesz tutaj też wiedzę ogólną na temat programowania. Możesz dowiedzieć się, że błędnie nazywasz metody, lub tę, którą stworzyłeś warto rozbić na kilka mniejszych elementów. Mógłbym tak długo wymieniać, jednak wniosek pozostanie taki sam – gdy trafisz na dobrego sprawdzającego możesz zdobyć olbrzymią wiedzę.

Nauka pokory

Rewizja kodu uczy też pokory. Przeglądana jest tam Twoja praca i wytykane Twoje błędy, których sam nie zauważyłeś. Zderzenie z rzeczywistością może być trudne, a smak krytyki – gorzki. Dzięki temu jednak jesteś w stanie spojrzeć obiektywnie na swoją pracę i zrozumieć, że Ty też popełniasz błędy i masz dużo pracy przed sobą. Jakkolwiek strasznie to nie brzmi, patrząc na komentarze w code review z odpowiednim podejściem można potraktować oceny jako konstruktywną krytykę, której przyświeca ten sam cel co Tobie – tworzenie świetnego oprogramowania.

Na co zwrócić uwagę podczas code review?

uczenie

Okej, wiemy już czym jest code review i jakie korzyści ze sobą niesie. Warto zastanowić się nad tym jak powinno ono przebiegać, żeby całość przebiegała sprawnie.

Zacznijmy od momentu, w którym warto stworzyć nowy przegląd kodu. Idealnie byłoby oddawać zmiany ograniczające się do kilku plików. Ciężko o rzetelne sprawdzenie, gdy do przejrzenia jest 100 klas. Lepszym pomysłem byłoby przeprowadzenie kilku review, każdego z mniejszą ilością zmian. Nie będą one tak przytłaczające, a dodatkowo będzie można spojrzeć na nie w szerszym kontekście, np. całej aplikacji lub funkcjonalności, której dotyczy.

Kolejność sprawdzania

Wielu oceniających rozpoczyna sprawdzanie kodu od tego, czy zmienne i metody zostały poprawnie nazwane lub wyszukania podwójnych spacji. Często też na tym kończą, ale przecież to nie jest istota code review! Według mnie, jest to najmniej ważna część do zrobienia, a każdy przegląd powinno się wykonywać w odpowiedniej kolejności:

  1. Weryfikacja, czy kod realizuje zadanie, które miał wykonywać – przykład: jeśli funkcjonalność odpowiedzialna za rezerwację biletów do kina w rzeczywistości pozwala na ich kupowanie to dalsze sprawdzanie nie ma sensu.
  2. Sprawdzenie, czy kod jest napisany poprawnie i optymalnie – warto zweryfikować, czy nie stworzono niepotrzebnych klas, gdy podobnie istnieją w systemie, a można by zaadaptować je do konkretnego celu. Wypadałoby też przejrzeć kod pod kątem podążania za konwencjami przyjętymi w firmie i zespole. Innym ważnym aspektem, na który warto zwrócić uwagę jest to, czy kod będzie działał wydajnie. Czasami takie błędy można zauważyć gołym okiem. To także dobry moment na weryfikację wykorzystanych wzorców projektowych i poprawności ich implementacji.
  3. Testy – kod oddawany do sprawdzenia powinien zawierać testy jednostkowe. Zadaniem sprawdzającego jest dokładne przejrzenie także ich.
  4. Styl – ostatnim punktem według mnie powinno być zaznaczenie wszystkich pozostałych błędów np. błędnej nazwy.

Dyskusja w komentarzach

dyskusja

W tym miejscu warto wspomnieć o dwóch sprawach. Pierwsza z nich to wzajemny szacunek. Zarówno sprawdzający jak i sprawdzany powinni dyskutować w sposób respektujący drugą osobę. Wszystkie komentarze sprawdzających powinny dotyczyć tylko kodu i nie nawiązywać w żaden sposób do autora. Sprawdzany natomiast nie powinien odbierać komentarzy jako atak. To moment, w którym duma, przywiązanie do własnego kodu i przekonanie o swoim geniuszu powinno się schować do kieszeni.

Druga to komunikatywność. Code review będzie przeprowadzane optymalnie tylko w przypadku, gdy w komentarzach nie będzie długich dyskusji. Wiadomości powinny być precyzyjne i zwięźle opisywać co zostało zrobione niepoprawnie i jak to poprawić. W przypadku, gdy problem wymaga dłuższej dyskusji warto porozmawiać twarzą w twarz lub na Skype. Wynik tych ustaleń podsumować w krótkiej informacji dla innych przeglądających. Bardzo usprawnia to pracę.

Czas wykonywania

Code review warto wykonywać jak najszybciej po utworzeniu. Jest tak z kilku powodów – autor dobrze pamięta powody, dla których stworzył taki, a nie inny kod. Wiem też o wszystkich wymaganiach biznesowych i regułach opisanych w kodzie, które często bywają skomplikowane, a ich przypomnienie czasochłonne. Idealnie byłoby gdyby sprawdzający starali się nie zalegać z przeglądami kodu. Oczywiście rzeczywistość to weryfikuje, a ważne spotkania, deadline’y, itp. Mają wyższy priorytet niż sprawdzanie kodu. Warto jednak przeznaczyć na rewizje stałą porę dnia, np. pierwszą godzinę po przyjściu do pracy, aby nie mieć zaległości w tej kwestii.

Narzędzia do code review

Na rynku istnieje wiele rozwiązań, które ułatwiają cały proces. Ich główne funkcjonalności to zaznaczanie wprowadzonych zmian i dodawanie komentarzy. Większość jednak oferuje znacznie więcej, na przykład integracje z systemem kontroli wersji, czy innym oprogramowaniem. Wybierać można z dziesiątek aplikacji. Z najpopularniejszych wymienić można: Collaborator, Crucible, Rhodecode, Phabricator, JArchitect, Veracode, czy Codebrag. Część z nich jest darmowa. W projektach, wybór często narzucony jest przez firmę lub klienta, jednak na własny użytek warto potestować różne rozwiązania i wybrać to, które najbardziej przypadnie nam do gustu.

Podsumowanie

W dzisiejszym artykule zajęliśmy się rewizją kodu. Omówiliśmy korzyści jakie ze sobą niesie, w jaki sposób powinno być przeprowadzone oraz jakich narzędzi do niego używać. Daj znać w komentarzach, czy uczestniczyłeś kiedyś w code review, i czy wszystkie cechy dobrego przeglądu kodu były zachowane. Chętnie poczytam o Twoich doświadczeniach.

Please follow and like us:

Dodaj komentarz

This site uses Akismet to reduce spam. Learn how your comment data is processed.