5 min.
W tym artykule:
- Code review - proces, w którym jeden programista sprawdza kod napisany przez innego członka zespołu.
- Code review można przeprowadzać na różne sposoby.
- Code review pozwala nie tylko na wczesne wykrycie błędów. To także sposób, aby integrować zespół i podnosić jego kwalifikacje.
Spis treści:
Czym jest code review, czyli inspekcja kodu?
Korzyści z efektywnego przeglądu kodu
Efektywne code review, czyli dzielenie się wiedzą
Techniki przeprowadzania code review
Czym jest code review, czyli inspekcja kodu?
Code review (po polsku inspekcja kodu, przegląd kodu lub czytanie kodu) to proces, w którym jeden programista sprawdza kod napisany przez innego członka zespołu. Przegląd odbywa się zwykle na wczesnym etapie cyklu wytwarzania oprogramowania – przed połączeniem nowych zmian z główną gałęzią projektu (np. w ramach pull request-u). Cel code review jest prosty: wykryć potencjalne błędy i upewnić się, że kod spełnia określone wymagania.
Korzyści z efektywnego przeglądu kodu
Naturalnie przegląd kodu przeprowadzony przez recenzenta przyczynia się do poprawy jakości kodu. Jego sugestie dotyczące nie tylko potencjalnych problemów, ale też czytelności, stylu i spójności kodu czy zgodności ze standardami sprawiają, że zmienne i funkcje mają lepsze nazwy, moduły są krótsze i lepiej wydzielone, zostają usunięte zbędne fragmenty, itd. Dzięki temu:
- Aplikacja jest bardziej stabilna,
- Inni członkowie zespołu mogą dodawać poprawki i/lub nowe moduły,
- Można szybciej wydać program, bo skraca to czas testów,
- Firma mniej jest narażona na utratę wizerunku i pieniędzy przeznaczonych na poprawki w późniejszych fazach,
- Finalny produkt lepiej spełnia kryteria jakości, bezpieczeństwa i zgodności (np. z API).
Przeczytaj także: Wymagania niefunkcjonalne aplikacji – czym są i jak je zdefiniować?
Efektywne code review, czyli dzielenie się wiedzą
Ponadto przeglądanie kodu umożliwia transfer wiedzy między specjalistami. Bardziej doświadczeni programiści mogą dzielić się wiedzą z innymi i pomagać utrwalać dobre praktyki programistyczne. Jednak, aby faktycznie przyniosło to wymierne korzyści, należy przestrzegać kilku zasad.
- Każdy w zespole musi pamiętać, że trudniej dostrzec błędy w swoim kodzie niż w cudzym, dlatego autor nie powinien brać uwag personalnie do siebie. Z kolei recenzent zwraca uwagę na fragmenty kodu, a nie cechy programisty.
- Ton code review powinien być konstruktywny i rzeczowy. W tym celu warto uzasadniać poprawki, odwołując się do standardów lub potencjalnych problemów, które dany fragment może powodować. Lepiej unikać ogólników typu „źle napisane” – zamiast tego należy wskazać, gdzie leży problem i zaproponować kierunek poprawy. Dobrą metodą jest zadawanie pytań w komentarzach (np. „Czy rozważałeś taki przypadek...?”), co skłania do refleksji, a nie wydawanie rozkazów.
- Mniej znaczy więcej. Badania pokazują, że najlepiej ograniczyć się jednorazowo do ok. 200-400 linii kodu. Powyżej tej wielkości skuteczność wykrywania błędów znacząco spada.
- Code review powinien być stałym elementem procesu wytwórczego, a nie sporadycznym wydarzeniem.
- Warto sporządzać checklisty, które mogą zawierać punkty dotyczące np. poprawności działania, zgodności ze standardami kodowania, pokrycia testami, obsługi błędów, bezpieczeństwa danych itp. Na początek lista może być krótka, skupiająca się na najważniejszych elementach, a z czasem można ją rozszerzać wraz ze wzrostem jakości kodu i świadomości zespołu.
- Nie wolno zapominać o tym, jak ważne są krótkie, szczere pochwały i pozytywny feedback.