Code review – part 1

Słowem wstępu, czyli o czym będzie ten oraz kolejne artykuły

Początkowy temat tego wpisu miał być nieco inny. Koncentrował się na narzędziach do statycznej analizy kodu, które pozwoliłyby odciążyć programistów z naszego zespołu od części wymagającej pracy, jaką jest code review. Jednak zgłębiając temat, zupełnie mimochodem, zebrałam sporo materiałów dotyczących samego review. Wynikiem tego był pomysł, by w pierwszej kolejności, w ramach wprowadzenia przedstawić samą metodykę oraz podzielić się naszymi doświadczeniami w tym zakresie.

W tym artykule skupię się na zdefiniowaniu, czym jest code review oraz jakie są benefity oraz koszty jego (nie)wykonywania. W kolejnych zaprezentuję najpopularniejsze techniki, ewolucję tego procesu w naszym zespole oraz podam wskazówki, jak uczynić opisywany etap workflow jak najefektywniejszym. I w ostatniej części powrócę do genezy całej serii – narzędzi wspomagających code review.

A zatem

Co to jest code review?

Aby na wstępie pozbyć się nieporozumień należy wyjaśnić, że code review w naszym „angielsko-polskim” środowisku funkcjonuje także pod nazwami peer review, przegląd, recenzja lub inspekcja kodu. Polega on, w telegraficznym skrócie, na weryfikowaniu poprawności kodu programu w celu stałego podnoszenia jego jakości oraz wczesnego wykrycia błędów wszelakiego rodzaju. Mowa tu zarówno o prostych przypadkach niepoprawnej konwencji kodu lub błędnej składni, jak i dużo bardziej znamiennych dla projektu: lukach bezpieczeństwa, błędach architektury czy nieprawidłowej implementacji wymagań biznesowych.

Korzyści oraz koszty stosowania

Jak napisałam wyżej, code review służy przede wszystkim wykryciu błędów. Ich usunięcie jest tym łatwiejsze im wcześniej zostaną wyłapane w procesie powstawania oprogramowania.
Nie jest to jednak jedyny benefit wprowadzenia review. Jako kolejne należy wymienić:

• Podniesienie czytelności kodu – wgląd w kod innych osób ma niebagatelny wpływ na poprawę jasności nazewnictwa czy czystość kodu. Ostatecznie o to w tym chodzi – dobrze napisany kod przegląda się szybko, łatwo go zrozumieć, a wymagania biznesowe znaleźć w dokumentacji, jaką są testy jednostkowe. W takim kodzie nietrudno dokonać poprawki czy rozbudować istniejące rozwiązanie, a zatem też szybkość developmentu jest wysoka. W ten punkt wpisuję się także utrzymanie standardów kodu (najlepiej weryfikowane przez odpowiednie narzędzia).

• Poprawa jakości architektury całego systemu – code review większych partii kodu umożliwia skontrolowanie, czy praca nad całością rozwiązania, częstokroć realizowanego przez kilka osób, idzie w dobrym kierunku, czy rozwiązanie jest spójne i zgadza się z ogólną wizją architektury całej aplikacji. Bywa to szczególnie istotne w projektach długofalowych, gdzie co jakiś czas następuje zmiana trendu i stosowane są nowe rozwiązania. Jest to oczywiście prawidłowe i niezbędne, aby możliwy był rozwój. Ale warto starać się, by cały zespół szedł we wspólnie obranym kierunku i nie stosował taktyki „każdy sobie rzepkę skrobie”, ponieważ po krótkim czasie aplikacja będzie wyglądać jak ruchomy zamek Hauru.

• Aspekt edukacyjny – wymiana wiedzy z zakresu domeny, zmian następujących w projekcie, czy praktyk programistycznych.

• Łatwość konserwacji systemu, czyli maintenance – jest o wiele prostszy, dzięki utrzymaniu dobrej jakości kodu.

• Mimo, że wspomniałam o tym już wcześniej, chciałabym podkreślić tą kwestię, jako niezwykle istotną: wykrycie błędów w zabezpieczeniach – niewątpliwie kluczowa sprawa w systemach o podwyższonym ich poziomie, takich jak np. strony internetowe banków, moduły sklepów odpowiedzialne za poprawność procesu transakcyjnego czy aplikacje przechowujące wrażliwe dane osobowe.

Co do kosztów. Code review ma to oczywisty impakt finansowy.

Z jednej strony dodanie tego elementu do procesu wytwarzania oprogramowania oznacza wyższe koszty i wydłużenie developmentu. Jakby nie było jest to dodatkowych czas, który musi zostać poświęcony na przejrzenie, ze zrozumieniem, świeżej partii kodu.

Z drugiej strony prawidłowo przeprowadzone, efektywne code review wręcz przeciwnie – obniża koszty, eliminując błędy, które mogłyby zostać wykryte dopiero przez użytkowników na poziomie produkcyjnego kodu, generując obniżenie przychodu czy wprost straty dla firmy. A ponieważ code review, w aktualnie najczęściej występujących formach, przeprowadza się na wczesnym etapie powstawania kodu, koszt finansowy i czasowy ewentualnych poprawek jest niewspółmiernie niższy niż seria bug fixów do kodu produkcyjnego, przeprowadzanych zazwyczaj w trybie krytycznym.

A Wy jakie widzicie plusy i minusy code review?

Kolejny artykuł dotyczący code review:

Code review – techniki