Zalety Code Review

Code review, czyli inspekcję kodu, traktuje się jako zło konieczne pomimo wielu korzyści, jaki za sobą niesie. Programiści są przekonani, że przeglądanie kodu to marnotrawienie pracy, prowadzące do wydłużenia czasu dostarczenia produktu, oraz że jest to ich nieprzyjemny obowiązek polegający na przeglądaniu ogromnej liczby niezrozumiałych zmian lub nieprzyjemnych komentarzy.

Jednak jeśli podejdziemy do inspekcji kodu w odpowiedni sposób, to znajdziemy w nich potężne narzędzie, które nie tylko poprawia jakość tego, co tworzymy jako programiści, ale również zmniejsza liczbę błędów występujących na późniejszych etapach rozwoju produktu. Wartość inspekcji i rzeczywistą poprawę jakości naszej pracy można z łatwością poczuć, przy założeniu, że pamiętamy o kilku prostych zasadach podczas inspekcji.

Jakie są korzyści code review?

Programiści znajdą wiele wymówek, aby nie wykonywać inspekcji kodu. Najczęstsze z nich to brak czasu lub nuda. Jednak korzyści płynące z czytania kodu współpracowników są niepodważalne, a trzy najważniejsze z nich to:

• znajdowanie błędów – wszyscy wiemy, że testy są bardzo ważne w procesie weryfikacji kodu, ale czy zdajemy sobie sprawę, że przeglądy kodu również zmniejszają liczbę błędów w kolejnych wersjach? Pisząc kod łatwo utknąć w swoim własnym sposobie myślenia. Perspektywa innej osoby może naprawdę otworzyć nam oczy.
• jakość kodu – kiedy kilka osób pracuje nad tą samą częścią kodu, staje się on po prostu lepszy. Wymiana pomysłów prowadzi do synergii, a końcowy rezultat jest lepszy niż suma jego części.
• dzielenie się wiedzą – każdy programista ma jakąś wiedzę i doświadczenie w pisaniu kodu. Jednym z najszybszych sposobów na dzielenie się tą wiedzą jest programowanie parami wprowadzone w ramach procesu code review. Niezależnie od tego, czy chodzi o rzadko używaną metodę w pakiecie java.util, czy nowy framework – każda wskazówka pomaga w samorozwoju.

Jak mogę zrobić to lepiej?

Skoro już wiemy, że inspekcje kodu są ważne, to musimy wiedzieć, jak robić je dobrze. Poniżej znajdziesz kilka wskazówek, które wniosą najwięcej wartości, ale śmiało możesz wdrożyć własne:

• styl kodu – spójny i jednolity styl kodu pozwoli uniknąć bezsensownych dyskusji o spacji lub średnikach. Istnieje wiele gotowych stylów kodu, które można zaimportować do swojego ulubionego IDE. Google udostępnia zestaw takich stylów (https://github.com/google/styleguide).
• małe zmiany – im więcej zmian zawiera pojedynczy przegląd, tym mniej uwag otrzymasz. Programista chętniej przejrzy Twój kod, jeśli zawiera on 7 plików, niż jeśli wyślesz efekt tygodniowej pracy z 40 plikami. Jeśli rozwijasz jedną funkcję przez cały tydzień, przesyłaj zmiany do przeglądu małymi partiami raz dziennie lub nawet kilka razy dziennie. Będzie je znacznie łatwiej przeczytać.
• próbki kodu – większość narzędzi do przeglądu kodu pozwala na łatwe dołączenie próbek kodu, czy to w komentarzach między wierszami kodu, czy w postaci dłuższych fragmentów. Jeśli pokażesz próbkę kodu współpracownikowi, łatwiej będzie mu zrozumieć Twoje podejście.
• uzasadniaj decyzje – zostawiaj wyczerpujące komentarze. Napisanie „Popraw to.” jest nie tylko niegrzeczne, ale nie dostarcza żadnych informacji o tym, co jest nie tak lub co można poprawić.
• podejdź i porozmawiaj – w niektórych przypadkach można zaoszczędzić sporo czasu po prostu podchodząc do biurka kolegi, by omówić fragment kodu. Nie twórz dziesięciostronicowej dyskusji w Crucible, która rozciągnie się na całe dni lub tygodnie. Po prostu podejdź i porozmawiaj.
• pozytywne nastawienie – nigdy nie używaj inspekcji kodu do rozładowywania złości lub pokazania swojej wyższości. Każdy popełnia błędy, a jeśli znajdziesz jeden w czyimś kodzie, napisz o tym w miły i uprzejmy sposób. Pamiętaj również, aby napisać coś pozytywnego lub pochwalić dobry fragment kodu – przeglądy kodu służą także do chwalenia dobrej pracy.
• integracja w procesie – o code review łatwo zapomnieć, jeśli stanowi części codziennej pracy. Zrób z nich obowiązkowy element: stwórz hooki na Git do ich raportowania, blokuj wdrożenia bez inspekcji kodu, wymuszaj code review – masz do dyspozycji wiele możliwości, aby się do tego przyzwyczaić.

A co z oprogramowaniem?

Aby przeglądy były przyjemniejsze i łatwiejsze można skorzystać z wielu dostępnych na rynku narzędzi. Niektóre z nich są darmowe, inne wymagają zapłaty. Dobrym pomysłem jest wcześniejsze porównanie ich przed podjęciem ostatecznej decyzji. Poniżej znajdziesz kilka najpopularniejszych narzędzi, ale oczywiście jest ich więcej:

• Gitlab – obok Githuba jest to jedno z najczęściej używanych narzędzi do przechowywania i udostępniania kodu źródłowego. Oparte na Gicie,
• Crucible – narzędzie pochodzące z Australii, stworzone przez firmę Atlassian. Posiada wiele przydatnych funkcji do przeglądania kodu i łatwo integruje się z JIRA – innym popularnym narzędziem w codziennej pracy,
• Gerrit – narzędzie stworzone przez Google, idealne dla tych, którzy potrzebują wsparcia dla społeczności open source,
• Phabricator – działa z Git, SVN lub Mercurial. Jego początki sięgają Facebooka.

Inspekcja kodu i jej potencjał

Spośród szeregu narzędzi, które wykorzystujemy jako programiści, inspekcje kodu mają naprawdę ogromny potencjał. Nadają się do wykorzystania w każdym języku programowania, w każdym biurze i przez każdego programistę. Nie musisz spędzać wielu godzin na nauce z książek, testowaniu ich na dziwnych kompilatorach lub platformach. Wiesz, jak to zrobić. Więc „just  do it”.