Bycie programistą nie sprowadza się tylko do pisania kodu. Musimy chodzić na spotkania biznesowe, naprawiać błędy, poszukiwać odpowiedniego narzędzia do rozwiązania danego problemu, analizować kod… no właśnie. Zapoznawanie się z kodem stanowi wręcz największą część pracy programisty. Czytamy kod, aby wiedzieć jak działa dana funkcjonalność, żeby dopisać do niej coś nowego albo naprawić istniejący błąd. Jednak istnieje taki moment w workflow, kiedy kończymy dane zadanie i chcemy je wrzucić do codebase. Dzięki czemu możemy poczuć zastrzyk dopaminy związany z zakończeniem implementacji. Tylko chwileczkę, musimy jeszcze zaliczyć jeden etap, którym jest… Code Review! No właśnie, czym jest Code Review to pewnie każdy programista wie. Pytaniem natomiast jest czy na pewno każdy z nas wykonuje je prawidłowo albo czy dobrze się do niego przygotowuje?
Code Review, czyli droga ku lepszemu oprogramowaniu
Code Review jest niczym innym jak procesem mającym na celu zwiększenie jakości wytwarzanego oprogramowania. Autor kodu po skończonej implementacji prosi kolegów z zespołu, aby przyjrzeli się jego rozwiązaniu. Oni natomiast mogą je zaakceptować bądź też zwrócić mu uwagę na pewne nieścisłości. Po poprawkach oraz pozytywnej weryfikacji deweloper tworzący rozwiązanie może dorzucić swój kod do głównego źródła aplikacji i zakończyć zadanie. Dzięki takiemu podejściu jesteśmy w stanie wyeliminować sporą ilość błędów wynikających z faktu, że człowiek nie jest nieomylny i może mu się przytrafić zawsze jakaś nieścisłość. Stosując Code Review na swoim projekcie można uzyskać naprawdę wiele korzyści, a to są niektóre z nich:
- znacznie zwiększa się jakość wytwarzanego kodu
- wyłapując błędy na tak wczesnym etapie wdrażania biznes może oszczędzić sporo pieniędzy
- odbywa się transfer wiedzy pomiędzy programistami (dla mnie bardzo istotny punkt)
- sprawdza się czy nasz kod jest łatwy do zrozumienia
- powstaje nić porozumienia pomiędzy członkami zespołu
- zwiększa się także odpowiedzialność autora za własne zadanie, ponieważ ma świadomość, że będzie ono podlegało weryfikacji przez osoby trzecie
- istnieje możliwość wypracowania jeszcze lepszego rozwiązania
- zespół może sprawdzić czy przestrzegane są ustalone wytyczne
Trzeba działać jako zespół!
Muszę dodatkowo przytoczyć ciekawe porównanie pisania kodu do pisania książki. W sytuacji, gdy książka ma wielu autorów to każdy z nich nie chce, aby wspólne dzieło było pełne błędów. Będą oni starali się wyłapać jak najwięcej błędów, swoich jak i współautorów. Tak samo w programowaniu musimy czuć odpowiedzialność za to co robimy. Powinniśmy mieć cały czas w świadomości, że gramy do jednej bramki. Sami nie chcielibyśmy mieć problemów spowodowanych błędami innych podczas implementacji. Należy, więc troszczyć się o to, aby nie rzucać nikomu kłód pod nogi.
W jaki sposób można wykonywać Code Review?
Osobiście spotkałem się tylko z jednym sposobem przeprowadzenia Code Review spośród tych przedstawionych na stronie SmartBear. Wydaje mi się on najlepiej dostosowany do ówczesnych realiów pracy. Jeżeli kiedyś wszystko wróci do normy to z chęcią zapoznałbym się z także z innymi polegającymi na kontakcie międzyludzkim. Przyjrzymy się zatem bliżej różnym sposobom wykonywania Code Review.
Wątek mailowy
Prowadzenie Code Review za pośrednictwem maila wydaje mi się naprawdę archaiczny rozwiązaniem. Można go porównać do pakowania swojego kodu w zipy i trzymania ich jako kopii zapasowej z komentarzami. Na pewno na plus można uznać fakt, że jest to podejście asynchroniczne. Wysyłamy nasz kod kolegom jako załącznik do maila i czekając aż się z nim zapoznają możemy wykonywać inne zadanie.
Na tym zalety się jednak kończą, bo według mnie ciężko jest śledzić historię uwag w takim rozwiązaniu. Nie wyobrażam sobie, aby napisać komuś w wiadomości mailowej, że ma literówkę w 243 linii w pliku XYZ, a w 56 linii w pliku ABC nie obsłużył poprawnie wyjątku. Autor rozwiązania w takiej sytuacji musi się sporo napocić, aby ogarnąć o który fragment kodu dokładnie chodziło. Dodatkowo maile z Code Review mogą zawsze gdzieś umknąć reviewerom pod napływem wiadomości od HRów czy klienta. Taki styl Code Review zostawiam tutaj jako ciekawostkę w nadziei, że nikt tak tego nie robi.
Pair programming
Koncepcja programowania w parach jest jednym z elementów Extreme Programming. Jak sama nazwa wskazuje, polega on na pisaniu kodu przez dwóch programistów na jednym komputerze. Oczywiście jeden z nich ma do dyspozycji klawiaturę, a drugi obserwuje pracę, zadaje pytania czy też sugeruje inne rozwiązania. Powinni oni cały czas między sobą dyskutować, aby ograniczyć ilość błędów oraz osiągnąć jak najlepszy efekt. Połączenie w parę juniora z seniorem moim zdaniem nie jest dobrym wyborem w kwestii Code Review. Istnieje duże prawdopodobieństwo, że wygenerowany kod przez taką dwójkę będzie dziełem bardziej doświadczonego dewelopera. Lepiej sprawdzi się duet średniozaawansowanych programistów, ponieważ każdy z nich może posiadać różne doświadczenie w innych dziedzinach IT.
Nie zmienia to jednak faktu, że taki zespół może być po prostu nieobiektywny co do wytworzonego rozwiązania. Para deweloperów będzie wpływać wzajemnie na siebie przez co utracą bezstronność. Wypadałoby, więc aby jeszcze dodatkowa osoba zweryfikowała takie rozwiązanie. W konsekwencji angażujemy kolejnego dewelopera do tego procesu sprawiając, że pair programming nie może istnieć jako samodzielny sposób na Code Review.
Over-the-shoulder
Najprostsza z możliwych metod Code Review, czyli zawołanie kolegi i poproszenie go, aby zweryfikował kod na naszym komputerze. Oczywiście autor rozwiązania siedzi obok i na bieżąco przedstawia swój proces myślowy, który towarzyszył mu podczas implementacji. Jest to ciekawa koncepcja, bo dostajemy wartościowy i rozbudowany feedback na bieżąco. Na minus można zaliczyć fakt, że musimy znaleźć dostępnego członka zespołu, który może nam sprawdzić kod. Jak dla mnie to nie lada wyzwanie, bo każdy jest bardzo zajęty swoimi zadaniami bądź spotkaniami. Nie zmienia to faktu, że tłumaczenie komuś w cztery oczy pewnych zagadnień jest najbardziej skuteczną metodą.
Wykorzystanie oprogramowania wspierającego
Na ówczesnym rynku istnieje wiele rozwiązań umożliwiających wykonanie Code Review. Najczęściej znajdują się one w przeglądarce i są zintegrowane z serwisami hostingowymi typu GitHub czy BitBucket. Dzięki intuicyjnemu interfejsowi są one łatwe w obsłudze przez co cieszą się one naprawdę dużą popularnością. Zaraz po wystawieniu prośby o Code Review reviewerzy są o tym fakcie informowani i mogą przystąpić do weryfikacji rozwiązania. W trakcie ich pracy, czyli dodawania komentarzy do kodu, autor otrzymuje notyfikacje i może od razu przystąpić do poprawek. Cały ten proces odbywa się asynchronicznie. Dodatkiem do tego sposobu Code Review jest możliwość tworzenia statystyk, robienia audytu czy weryfikacji zgodności kodu z przyjętymi normami. Oczywiście brakuje tutaj kontaktu offline z drugim człowiekiem, ale coś za coś.
Jakie błędy najczęściej popełniamy podczas Code Review?
Nawet najlepsze narzędzia nie wyręczą nas ze wszystkiego, przynajmniej na tą chwilę. Dalej musimy skupić na tym co robimy i próbować ułatwić sobie pracę i innym. Przedstawię kilka najczęściej popełnianych błędów podczas Code Review przez:
- reviewerów: + skupianie się na składni zamiast na logice biznesowej (brak spacji, brak entera, złe wcięcia itd.) + pomijanie weryfikacji kodu testów + sprawdzenie tylko kodu dodanego, zapominanie o linijkach, które zostały usunięte + wykonywanie Code Review na szybko, bo czas goni, a trzeba coś pokazać klientowi + brak weryfikacji zmiany pod kątem architektury systemu + pisanie zawiłych i niejasnych komentarzy dla kolegi z zespołu
- autorów: + wysyłanie zbyt dużego changesetu zmian do sprawdzenia na raz + brak komentarzy do kodu (nie mylić z “w kodzie”) po przekazaniu rozwiązania do Code Review + tworzenie zawiłych testów
Jak widać jest kilka aspektów, na które warto zwrócić uwagę. Muszę się przyznać, że sam popełniam wyżej wymienione błędy, ale sukcesywnie staram się je eliminować. Tylko w jaki sposób można to zrobić? Spróbujmy sprostać temu zadaniu i znajdźmy możliwe rozwiązania.
Włączenie statycznej analizy kodu
Jeżeli mamy możliwość, aby komputer nas z czegoś wyręczył to powinniśmy z tego korzystać. Sprawdzenie składni pod kątem brakującej spacji czy też złego wcięcia (odwieczna wojna pomiędzy tabulatorami a spacjami!) możemy w łatwy sposób wyoutsourcować. Na przykład przy wykonywaniu commita (używając Gita) uruchamiamy formater, który wykona za nas statyczną analizę kodu zmienionych plików pod względem wyglądu. Wtedy nie będziemy musieli się martwić o ten aspekt podczas Code Review, tylko będziemy mogli się skupić na istotniejszych elementach kodu.
Przyłożenie się do testów
Należy przestawić swoje myślenie na temat testów. To są nasi sprzymierzeńcy w walce ku lepszej implementacji i spokojniejszym nocom. Każdy kod zasługuje na porządne review, więc należy przyłożyć się również do weryfikacji testów. Jednak tutaj autor ma dużo do powiedzenia w tym temacie. Musi dbać o to, aby napisany przez niego kod testów był czytelny i zrozumiały. Nie może on zniechęcić reviewera już na samym początku przez brak składu i ładu.
Każdy członek zespołu może wykonywać review
Dobrą praktyką jest, aby każdy członek zespołu weryfikował kod swoich kolegów niezależnie od swojego doświadczenia. Okazuje się to dobrym pomysłem, ponieważ jeżeli juniorzy będą brali czynny udział w Code Review i weryfikowany kod będzie dla nich zrozumiały to jest to dobry znak, że kod jest czytelny. Efektem ubocznym jest fakt, że mogą oni się też sporo nauczyć poprzez przyglądanie się efektom pracy swoich starszych kolegów.
Wyższy priorytet ma podejście autora
Jeżeli powstały kod działa i jest wystarczający dobry, aby wrzucić go do codebase to należy przyjąć go jako ostateczną wersję. Nie powinno się narzucać własnego, alternatywnego podejścia do tematu tylko dlatego, że nasze rozwiązanie wydaje nam się lepsze. Najważniejsza jest dowożona wartość biznesowa i nie ma co się przepychać w sprawach mniej istotnych. Przecież reviewer również może się nauczyć tego, że istnieje wiele rozwiązań jednego problemu i należy to uszanować.
Pisanie tylko konstruktywnych komentarzy
Nie o to chodzi w Code Review, aby wylać tam wszystkie swoje żale i udowodnić komuś, że nie ma racji. Powinniśmy starać się uczyć siebie nawzajem i pokazywać to chociażby poprzez pisanie komentarzy do kodu. “Czy zastanawiałeś się nad…” bądź “Czy rozważałaś…” naprawdę przełamuje lody i może być dobrym wstępem do ciekawych dyskusji na temat rozwiązania. Nie zaszkodzi też pisać pochwał jeśli dany fragment kodu wywarł na nas pozytywne wrażenie. To kosztuje niewiele wysiłku, a może kogoś wprowadzić w dobry nastrój na resztę dnia.
Rozbijanie zadania na mniejsze części
Zdarzyło Ci się wysłać do Code Review funkcjonalność zawierającą 100 zmienionych lub utworzonych plików?! Mi na szczęście nie, ale połową tej ilości mogę się pochwalić (chociaż to żaden powód do dumy…). W ten sposób naprawdę utrudnia się zadanie reviewerom, bo będą przekopywali się przez sporą ilość zmian. Zamiast oderwać się na 15 minut i sprawdzić nasz kod w ramach relaksu, muszą poświęcić sporą ilość swojego czasu co każdego może zniechęcić. Z tego powodu połowa reviewerów będzie zachowywała się jakby nie widziała prośby o Code Review, a druga połowa zrobi go tylko po łebkach. Nie chcemy takiego biegu wydarzeń, więc zalecam, aby dawkować nasz kod do weryfikacji.
Podział zadania na mniejsze fragmenty do klucz do sukcesu!
Podejście autora do Code Review
Podejście autora do Code Review może naprawdę ułatwić pracę reszcie zespołu. W momencie, gdy przekazujemy nasz kod do weryfikacji dobrą praktyką jest dawanie komentarzy wyjaśniających dlaczego coś zrobiliśmy w ten sposób a nie inny. Możemy oczywiście też zadawać pytania czy ktoś nie ma pomysłu na lepsze rozwiązanie danej kwestii. Dodatkowo jeśli autor ma zadanie, które zmienia architekturę oprogramowania to powinien przekazywać swój kod do sprawdzenia na jak najwcześniejszym etapie. W ten sposób uniknie sytuacji, w której okaże się, że całe rozwiązanie trzeba napisać od nowa…
Podsumowanie
W mojej ocenie Code Review to naprawdę bardzo przydatne narzędzie, które niskim kosztem potrafi znacznie poprawić jakoś kodu. Oczywiście jest to pewna koncepcja, która w każdej firmie może trochę inaczej wyglądać, ale cel pozostaje ten sam. Należy jednak dbać o to, aby ten aspekt przebiegał jak najsprawniej i nie był utrapieniem. Czasami nawet najmniejsza zmiana w podejściu bądź nastawieniu może wywołać efekt motyla i usprawnić proces dewelopmentu. Warto mieć na uwadze fakt, że kod nie musi być idealny, aby trafił na produkcję tylko wystarczająco dobry i łatwy w utrzymaniu. Przecież zawsze na pierwszym miejscu stoi wartość biznesowa kryjąca się za każdym zadaniem.