Code review, lubię to!

Czy na pewno code review to strata czasu?

Cóż może być nudniejsze i bardziej kosztowne niż przeglądanie cudzego kodu źródłowego? Chyba już tylko poprawnianie w nim błędów. Jeszcze kilka lat temu koncepcja przeglądania mojego kodu przez kolegów z zespołu była dla mnie totalną abstrakcją. Aczkolwiek, z czasem zrozumiałem, że w tym szaleństwie jest metoda. W kilku punktach chciałbym przedstawić benefity, które może wprowadzić Code Review do Twojego ekosystemu projektowego drogi Czytelniku.

Edukacja

Mam w zespole kolegę, które właśnie przez code review nauczył mnie na nowo pisać obiektowo. Było to trochę karkołomne, gdyż po pierwszym review dostałem ~30 komentarzy do kilku plików kodu, ale opłacało się. W ten sposób przekazał mi swoją wiedzę, cenne uwagi, które inaczej zatrzymałby dla siebie, a kod źródłowy pozostałby w ciężkim stanie. Edukacja w obrębie zespołu jest potrzebna, ale nie dokońca wiadomo jak bardziej "ogarnięci" programiści mogą dzielić się swoim doświadczeniem ze swoimi "młodszymi" kolegami (np. inną opcją jest programowanie w parach Junior-Senior). Code review stwarza takie możliwości, wspomniani Juniorzy to mogą być też nowe osoby w projekcie, które nie poznały jeszcze wszystkich meandrów kodu z którym pracują.

Standardy i jakość

Przy większych, a nawet kilku osobowych zespołach wymuszenie pewnych kowencji jest bardzo trudne, chyba, że wszystko zautomatyzujemy StyleCop'em i będziemy wymuszać pewne reguły na poziomie kompilacji. Nie zawsze to może być praktycznym rozwiązaniem, a review może być tutaj dobrym narzędziem do "nadzoru", ponieważ wtedy jest to idealny moment na "zwrócenie uwagi" swojemu koledze z zespołu, że w tym miejscu "dał ciała".

Inną sprawą, że dobry reviewer w pewnym sensie bierze częściową odpowiedzialność za jakość kodu źródłowego. Pomimo, że nie jest on autorem, podpisuje się imieniem i nazwiskiem, że kod, który widział jest "produkcyjny".

Często code review może odkryć więcej błędów, niż proces testowania. Jest to też ważny atut, który można w łatwy sposób przetłumaczyć na gotówkę.

Kanał komunikacyjny

W rozproszonych zespołach, np. nie pracujących razem w jednym pokoju, budynku, mieście, kraju komunikacja między-developerska jest znacząco utrudniona. Code review może być okazją, żeby przedyskutować pewne rozwiązania, ewentualnie zaproponawać bardziej eleganckie rozwiązanie danego problemu. 

Narzędzia

Codre review możę być nieformalne i uwagi mogą być przesłane email'em, lub zapisane w systemie do rejestracji zmian lub bug'ów. Mi zdarzyło się używać Crucible'a, aczkolwiek nie jest on bezpłatny, ale warty swojej ceny, jest też trochę rozwiązań open-source, ale nie miałem z nimi żadnego doświadczenia.

Podsumowanie

Jeżeli masz w zespole spore zróżnicowanie umiejętności, problemy z wprowadzeniem pewnych konwencji, standardów to może na próbę trzeba dać szansę code review. Na koniec kilka wskazówek:

1. Code Review powinno być wykonane przez doświadczonego programistę, mogą być też rotacje dyżurujących reviewer'ów, lub można ustalić pary programistów, które sprawdzają sobie kod. 
2. Code Review można wykonać po zakończonym zadaniu, lub po jakimś etapie zadania
3. Najlepiej jak jedna osoba przegląda modyfikacje wykonane przez tylko jedną osobę, żeby nie wprowadzić zamieszania (tutaj przydaje się system do zarządzania code review i zmianami w repozytorium kodu).
4. Każda zmiana, nawet drobna nadaje się do weryfikacji przez inną osobę, gdyż może to zapobiec potencjalnym błędom, które w przyszłości będą już trudniejsze i bardziej kosztowne do naprawienia.

Jestem ciekawy, czy code review jest już standardem na naszej polskiej ziemi, i jak ono funkcjonuje w Waszych zespołach.

Hope this helps.