Code review jako skuteczny sposób na zapewnienie długoterminowej jakości projektu IT

Tomasz

Code review, jako integralna część procesu tworzenia oprogramowania, pomaga skupić się na najważniejszych kwestiach i poprawie jakości kodu. Dlaczego code review powinno być powszechną praktyką? 

Krótko mówiąc, code review (CR), czyli przegląd kodu polega na przeanalizowaniu tworzonego kodu przez członków zespołu i wykryciu potencjalnych błędów. Po zakończeniu tworzenia nowej funkcjonalności developer tworzy pull request (PR), aby poinformować wybrane osoby, że kod czeka na przegląd. Następnie, programiści sprawdzają kod, dzielą się swoimi opiniami i wskazówkami. 

Budowanie kultury code review w zespole jest ważne dla utrzymania jakości i spójności w kodzie. Dlatego tak ważne, aby za każdym razem, gdy pojawiają się nowe standardy, zostały one omówione i zatwierdzone przez zespół. Jak możesz zwiększyć efektywność CR? 

Code review — najlepsze praktyki

Jedną z głównych zasad, których powinieneś się trzymać, planując przegląd kodu, jest rozpoczęcie code review tuż po otrzymaniu PR. W idealnym świecie czas od utworzenia PR do ukończenia CR nie powinien przekraczać jednego dnia. 

Aby zwiększyć skuteczność i efektywność code review, skoncentruj się na zakresie zawartym w pull requeście. Ważne również, aby autor kodu podzielił PR na mniejsze części, zawierające maksymalnie 400 linii kodu. Takie podejście zdecydowanie przyspiesza proces i ułatwia wprowadzanie czy proponowanie zmian w poszczególnych częściach systemu. 

Analizując kod, zacznij wysokopoziomowo. Skup się na najważniejszych elementach, zmianach w architekturze czy strukturze, zwróć uwagę na duplikaty i ewentualne bugi. Następnie, podziel klasy na mniejsze (bardziej szczegółowe) podklasy, przejrzyj kod pod kątem redukcji zbędnych linii czy zastosowania nowocześniejszej techniki, a uwagi dotyczące nazewnictwa zmiennych czy komentarzy zostaw na koniec. 

Pamiętaj, że code review może składać się z wielu iteracji, ponieważ nowa wersja kodu może wymagać kolejnych przeglądów.

Ważne również, aby utrzymywać pozytywną atmosferę — lepiej zadawać pytania niż wydawać polecenia czy wymuszać zmiany w kodzie. To, w jaki sposób komentujesz kod, jest zwykle ważniejsze od tego, co mówisz. Bądź uprzejmy, szanuj autora kodu, a proponując zmiany, podaj konkretne przykłady. Zamiast pisać: „To jest źle, zmień to”, napisz: „Rozważ rozdzielenie tego komponentu na osobne funkcje, jak w poniższym kodzie: [przykład kodu]” lub „Co myślisz o rozdzieleniu tego komponentu…”.

Dobrą praktyką jest też unikanie bezpośredniego zwracania się do autora kodu. Zamiast obwiniać kolegę o popełnienie błędu, lepiej użyć formy bezosobowej lub zastosować “my” jako podmiot wypowiedzi. Jeśli sugerujesz zmianę kodu lub zupełnie nowe podejście, wyjaśnij powody swojej decyzji — podaj wytyczne, oparte na regułach czy standardach, a nie na własnej opinii. Twoje przykłady powinny opierać się na dokumentacji, wysoko ocenianych odpowiedziach na Stack Overflow czy treściach z poważanych blogów. Unikaj też powtarzania komentarzy dotyczących tych samych błędów w obrębie tego samego PR.

Code review powinien opierać się na współpracy i obiektywnej dyskusji, a nie osądzaniu. Dlatego w Studio Software zawsze zakładamy, że komentarze osoby przeglądającej kod idą w parze z dobrymi intencjami. Jeśli nie rozumiemy danego fragmentu kodu, prosimy autora o wyjaśnienie. Gdy komentujesz kod, który według ciebie jest nieintuicyjny, twoja uwaga powinna być subiektywna, np.: „Ciężko mi zrozumieć, o co chodzi w tym fragmencie”, zamiast stwierdzenia: „To jest niezrozumiałe”, aby nie wprowadzać w błąd innych przeglądających PR.

Jeśli jesteś reviewerem, pamiętaj, aby motywować programistów, dzielić się pozytywnymi komentarzami oraz wyrazić uznanie, gdy kod jest dobry.  Recenzja kodu jest okazją do nauki zarówno dla autorów, jak i recenzentów, dlatego jako autor zachowaj otwarty umysł i okaż wdzięczność recenzentom. Nie spodziewaj się też drastycznego wzrostu jakości już po pierwszym PR, niektóre zmiany wymagają więcej czasu.

Zalety code review

Najważniejszymi zaletami code review są poprawa działania i jakości kodu, wyeliminowanie bugów, czy unikanie zepsutych buildów. Równie ważny jest transfer wiedzy, dzięki czemu zespół jest lepiej zaznajomiony z kodem i każdy ma podobne pojęcie o wprowadzanych zmianach, stosowanych praktykach czy regułach nazewnictwa zmiennych. 

Code review podnosi też standardy zespołu, ponieważ programiści uczą się jak pisać lepszy kod, szukać alternatywnych rozwiązań i rozumieć problemy biznesowe. Tym bardziej że CR organizowane są również w postaci regularnych, zazwyczaj kwartalnych, spotkań, podczas których omawiamy kod w szerszym kontekście, aby zespół wiedział, co można poprawić podczas kolejnego przeglądu kodu. 

CR to również okazja do poprawy komunikacji w zespole, zwiększenia zaangażowania i zbudowania zaufania. To także sposób na zdobycie wiedzy i nauczenie się nowych rzeczy, zarówno podczas recenzowania, jak i przeglądania komentarzy. CR może być też pomocnym rozwiązaniem przy wdrażaniu nowych członków do zespołu programistów. 

Checklista dla code review

Poniżej znajdziesz listę rzeczy, na które warto zwrócić uwagę, aby usprawnić i przyspieszyć proces przeglądu kodu. 

  • Czy kod działa?
  • Czy kod jest przejrzysty i zrozumiały?
  • Czy zachowane są dobre praktyki, takie jak SOLID, DRY, KISS itp.?
  • Czy kod powiela schematy już wypracowane w projekcie? 
  • Czy komentarze wyjaśniają powody zastosowania danego rozwiązania, a nie sposób ich implementacji? 
  • Czy komentarze wyjaśniają wszystkie hacki, skróty, rozwiązania tymczasowe?
  • Czy kod jest samoopisujący? Jeśli tak to czy komentarze nadal są potrzebne?
  • Czy funkcjonalność jest zrozumiała dla użytkownika końcowego?
  • Czy biblioteki/zewnętrzne zależności są dobrze udokumentowane i nadal utrzymywane? 
  • Czy wyjątki są dobrze opisane? Czy komunikaty o błędach są zrozumiałe? Czy są obsługiwane?
  • Czy zmodyfikowany kod jest teraz w lepszej kondycji niż przed modyfikacją?
  • Czy algorytm jest napisany w najbardziej wydajny sposób?

Wykorzystuj podane wskazówki i podziel się nimi z zespołem!

Related Posts
2 marca 2020
Software house, freelancer czy własny zespół — jak zbudować projekt IT?
Gdy masz pomysł na produkt, budżet i plan dalszego rozwoju, czas znaleźć idealny zespół, który…
Czytaj więcej
11 sierpnia 2022
React.js z punktu widzenia dewelopera — plusy i minusy
React JS wydaje się być wszędzie. Firmy duże i małe, używają go do tworzenia swoich…
Czytaj więcej
18 marca 2020
Legacy code: Jak sprawdzić, czy twój projekt wymaga zmian?
Mimo że ostatnie zmiany w projekcie były wprowadzane kilka lat temu, system nadal działa bez…
Czytaj więcej