O code review napisano już całkiem sporo. W internecie można znaleźć dokładne opisy jak powinny wyglądać, jakie dają efekty, czy ile kodu sprawdzać na raz. Dlatego nie będę dokładnie analizować tych aspektów. Zamiast tego krótko opiszę najważniejsze korzyści i kilka przydatnych technik na podstawie własnych doświadczeń. Z code review korzystałem już w wielu projektach i zawsze miało to pozytywny wpływ na jakość kodu. Moim zdaniem code review powinno być elementem każdego poważnego projektu.

Co zyskujemy dzięki code review?

Jakie są najważniejsze cele realizowane przez code review? Moim zdaniem można wyróżnić trzy:

• Wykrycie pewnych kategorii błędów trudnych do znalezienia w inny sposób.
• Transfer wiedzy między członkami projektu.
• Wypracowanie jednolitego stylu.

Znajdowanie błędów

Istnieją pewne typy błędów, które ciężko wyłapać dzięki testów, czy narzędzi do statycznej analizy. Jednak osoba patrząca na nasz kod jest w stanie je wychwycić. Szczególnie kiedy wie na co zwrócić szczególną uwagę. W ten sposób możemy znaleźć szczególnie złośliwe błędy związane ze współbieżnością, wskaźnikami czy alokacją pamięci. Recenzent jest też w stanie sprawdzić zgodność kodu z dokumentacją i wymaganiami. Może ocenić poprawność podjętych decyzji architektonicznych i odnieść się do wiedzy dziedzinowej.

Transfer wiedzy

Dzięki code review nowi członkowie zespołu mogą się gwałtownie wdrożyć do projektu. Recenzując kod innych mogą zadawać pytania dotyczące konkretnych decyzji. A kiedy ich kod jest oceniany, mogą gwałtownie poznać różne kruczki i wiedzieć na co zwracać uwagę przy developmencie. To samo tyczy się juniorów, którzy dzięki code review mają dużo materiału do nauki. Ale z transferu wiedzy korzysta każdy członek zespołu. Dzięki temu dobre praktyki są szybciej propagowane.

Wypracowanie wspólnego stylu

Ważnym aspektem jest również wypracowanie stylu pisania, którego wszyscy się trzymają. Zwykle jest on opisany w dokumencie Coding Standard, ale nie jest w żaden sposób wymuszony. Dzięki code review zespół się synchronizuje co do wspieranych i unikanych praktyk, reguł nazewnictwa zmiennych, funkcji i plików. Dzięki temu łatwiej odnaleźć się w kodzie napisanym przez kogoś innego.

Wiemy już dlaczego powinniśmy robić code review, przejdźmy teraz do wskazówek jak je przeprowadzać.

To co się da niech robią za nas toole

Recenzent powinien całą swoją uwagę skupić na ważnych uwagach, a nie rozpraszać się np. złym umiejscowieniem nawiasów klamrowych. W tym celu przed rozpoczęciem review to co możliwe, powinno być wykryte i najlepiej poprawione automatycznie. Dlatego zanim review się w ogóle rozpocznie dobrze najpierw sprawdzić, czy:

• kod się kompiluje,
• nie ma żadnych warningów,
• przechodzi unit testy,
• ma wystarczający code coverage (nie brakuje testów do nowego kodu),
• statyczna analiza nie znajduje błędów,
• nie ma błędów formatowania,
• pliki mają odpowiednie nagłówki.

W dzisiejszych czasach code review jest wspierane przez toole współpracujące z serwerem continuous integration, który potrafi zrobić dla nas te wszystkie rzeczy.

Autor sam robi wstępne review

Autor przed oddaniem kodu do sprawdzenia najpierw sam czyta jeszcze raz wszystkie wprowadzone zmiany. W ten sposób można wychwycić różne głupie błędy typu nieusunięty kod testowy, proste błędy logiczne i tymczasowe komentarze. Poza tym jest to okazja do naniesienia adnotacji dla sprawdzającego. Możemy w ten sposób wytłumaczyć podjętą decyzję albo wskazać fragment do którego mamy jakieś wątpliwości. Dzięki tym zabiegom możemy oszczędzić trochę czasu.

Wymagana akceptacja dwóch recenzentów

Techniką dającą zadziwiająco dobre efekty jest sprawdzenie kodu przez dwie osoby. Jedna może przejrzeć kod bardzo dokładnie, natomiast druga wystarczy jeżeli skupi się na rzeczach bardziej ogólnych i może intereniować, kiedy pierwszy recenzent coś przeoczy. Może również przejrzeć jego uwagi i przedstawić swoje stanowisko. Przydaje się to w sytuacjach spornych.

Aby taki system dobrze działał, recenzentem nie może być autor kodu, ani manager dbający głównie o to, aby feature był jak najszybciej zrobiony. o ile reviewerami są dwaj inni programiści, w ich interesie leży, aby kod spełniał odpowiednie standardy. W końcu sami też będą go wykorzystywać.

Sytuacje sporne

Czasem się zdarza, iż autor i recenzent nie mogą dojść do porozumienia. Szczególnie w pierwszych review może się to często zdarzać, kiedy nie ma jeszcze dobrze wykrystalizowanego stylu i dobrych praktyk. Takie problemy powinny być wyjaśnione na forum całego zespołu, a podjęta decyzja będzie wiążąca w kolejnych podobnych przypadkach. Po takich dyskusjach warto na bieżąco uzupełniać coding standard. Tego typu sporne sytuacje to normalna kolej rzeczy i nie są niczym złym. o ile uważasz, iż jakaś praktyka powinna być stosowana w projekcie, warto o nią walczyć. W końcu od tego zależy komfort przyszłej pracy.

Review checklist

Skoro istnieją pewne typy błędów, które najlepiej znajdować w code review, warto sobie dodatkowo w tym pomóc. Review checklist jest listą rzeczy na które powinniśmy zwrócić szczególną uwagę analizując czyjś kod. Powinna być dosyć krótka, aby można ją było przeczytać przed każdym review. W ten sposób od razu nastawiamy nasz mózg na szukanie konkretnych problemów. W miarę trwania projektu warto rozszerzać listę wiedząc jakie bugi najczęściej nam umykają.

Uwagi końcowe

Code review jest prostą techniką, która ma niesamowity efekt na jakość kodu. W jednym z projektów nad którym pracowałem została wprowadzona dopiero po dłuższym czasie. Dlatego miałem porównanie jak było przed i po. Byłem zaskoczony jak pozytywnie code review wpłynęło na komfort pracy z kodem i ilu potencjalnych błędów udało się uniknąć.

Ciekawym aspektem jest tutaj świadomość, iż nasz kod będzie oceniony przez innych. Przez to bardziej się przykładamy i chcąc oszczędzić czas od razu myślimy do czego można by się przyczepić i to poprawiamy. Nie pomijamy również testów i dokumentacji wiedząc, iż bez tego i tak nie przejdzie review.