Code Review – Nie wiesz jak pisać lepszy kod? Skup się na code review (przegląd kodu)!

Chcesz pisać lepszy kod – ale nie wiesz, od czego zacząć? Skup się na code review!
Code review to jedna z tych praktyk programistycznych, która świetnie się sprawdza zarówno w małym startupie, jak i u wielkich gigantów rynku takich jak Google, czy Facebook.

Jak działa ta „cudowna” technika? – Zapraszam do lektury! 🙂

Wpis o code review jest dla Ciebie jeżeli 👇

• chcesz dowiedzieć się co to jest code review,
• chcesz wiedzieć jak z technicznego punktu widzenia przeprowadzić przegląd kodu (ang. code review),
• chcesz poznać dobre praktyki i narzędzia, które pozwolą Ci wdrożyć code reivew zarówno w małym, jak i większym zespole,
• pracujesz lub uczysz się programowania samodzielnie i chcesz podnieść jakość swojego kodu.

Code review 🔍

Code review NIE jest nowym pojęciem, które zostało wymyślone i wprowadzone przez geeków programistycznych.
Jest raczej bardzo podstawowym pomysłem, z którego większość z nas korzystała już wcześniej np. w dzieciństwie – nawet często nie zdając sobie z tego sprawy…

Nie wierzysz? 🙂

Hipotetyczny pierwowzór code review

To przypomnij sobie swoją szkołę podstawową.
Mamy to? 🙂

Piszesz swoje wypracowanie z polskiego – powiedzmy, że opisujesz swoje wakacje lub wymarzony pokój.
Co się dzieje później?

– Mamo! Mamo! Przeczytaj, proszę moje wypracowanie na polski. Tak może być?!

Biegniesz do rodzica z prośbą o sprawdzenie, czy wszystko jest dobrze, czy nie ma literówek, błędów ortograficznych, czy struktura się zgadza itp.
Chcesz upewnić się, czy jak jutro pokażesz swoje zadanie w klasie, to nie będzie z nim problemów.

Można powiedzieć, że to był swego rodzaju przegląd Twojego rozwiązania (Twojego kodu) – czyli właśnie code review.

W takim wypadku można powiedzieć, że nasz nauczyciel robił za serwer ciągłej integracji, który testuje zmianę lub za klienta, który później z niej korzysta. 😉

Analogiczne rozwiązania możemy znaleźć również w innych branżach – np. przed ostateczną publikacją książki (zazwyczaj) przekazuje się ją jeszcze do weryfikacji przez recenzentów – to też jest swego rodzaju „przegląd rozwiązania/kodu”.

Jak to ma się do IT?

W przypadku programistów sprawa wygląda teraz bardzo podobnie.
Junior napisze swoje rozwiązanie – i biegnie do Seniora, żeby mu sprawdził.

Taki układ prawie jak za czasów dzieciństwa. 😉

Co to jest code review❓

Sformalizujmy odrobinę te pojęcia.

Dzięki takim przeglądom możemy:

• znacząco poprawić jakość naszego kodu,
• wyedukować nowe osoby w zespole,
• uspójnić wiedzę,
• oraz wiele, wiele innych – ale o tym za chwilę. 🙂

W dużym uproszczeniu polega to na przeglądaniu kodu przez inną osobę przed ostatecznym dołączeniem go do naszej aplikacji i przekazaniem do dalszych testów.

Code review – dlaczego?

Ale czemu musimy to robić?
Bo programy, które wytwarzamy to kod źródłowy, który pisany jest przez człowieka – a co za tym idzie, mogą wystąpić w nim błędy.

ZAWSZE, gdy w procesie wykorzystywany jest człowiek, to musimy liczyć się z potencjalnymi problemami i błędami. 😉

Code review jest jednym ze sposobów na ich ograniczenie – nie wyeliminowanie, ale właśnie ograniczenie.

Sposoby na code review

Sposobów na code review jest naprawdę całkiem sporo.
Przyjrzyjmy się im – zaczynając od tych najbardziej podstawowych.

Jak to może wyglądać w praktyce?

Wysłanie swojego rozwiązania mailem, messengerem, na grupie, czy nawet gołębiem…

Pracujesz nad swoim kodem i gdy już uznasz, że warto by ktoś zweryfikował Twoje rozwiązanie „utrwalasz je” i przekazujesz dalej.

Jak możemy utrwalić taki kod?

Opcji jest kilka:

• screenshot,
• zdjęcie monitora – [Nie polecam. Poczytaj lepiej o pull request],
• plik z kodem źródłowym w załączniku maila,
• krótkie nagranie wideo np. z dodatkowym opisem rozwiązania [polecam loom lub inne analogiczne rozwiązania].

W kolejnym kroku wysyłamy to do weryfikacji i rozpoczynamy dyskusję nad kodem.

Code Review – Pair Programming

Pair programming

Pair programming, czyli programowanie w parze danego rozwiązania wygląda bardzo podobnie – pracujecie wspólnie nad danym rozwiązaniem i na koniec pokazujesz swój kod do weryfikacji.

Możesz go wysłać – ALE równie dobrze możesz przekazać ekran, klawiaturę, myszkę dla kolegi i też mamy już code review.

Pull request

Tutaj dochodzimy do najpopularniejszego rozwiązania, które genialnie wręcz sprawdza się w praktyce – szczególnie gdy pracujemy nad kodem w więcej niż dwie osoby.

Dzisiejsze zespoły programistyczne dla wydajnej pracy praktycznie zawsze korzystają z jakiegoś systemu kontroli wersji.
W dużym skrócie – systemy kontroli wersji odpowiedzialne są za śledzenie wszystkich zmian dokonywanych w plikach. Za ich pomocą można podejrzeć wcześniej dokonane zmiany oraz, w razie potrzeby, powrócić do starszej wersji pliku. Dzięki nim można również sprawdzić kto i kiedy dokonał tych zmian.

👉 Więcej na temat systemów kontroli wersji oraz najpopularniejszego tego typu rozwiązania możesz przeczytać tutaj – Git tutorial.

Pull request Git

Jedną z bardziej praktycznych rzeczy, jaką możemy zrobić, korzystając z git’a jest przygotowanie pull request’u, który może posłużyć już nam jako początek dla przyszłego code review.

Pull request to jakby powiedzieć członkom zespołu – Hej, ja już skończyłem pracę nad tym zadaniem i tak to wygląda – zweryfikujcie, proszę, bo chcę to wdrożyć do naszej aplikacji.

Wtedy podczas code review sprawdzamy już kod udostępniony w ramach danego pull request.

O tym, jak przygotować w praktyce taki pull request opowiadam w poniższym nagraniu.

Code review – dyskusja 🗣️

Na przesłaniu kodu do weryfikacji code review zdecydowanie się nie kończy!
Tak naprawdę, to można powiedzieć, że dopiero w tym momencie zaczyna się cała zabawa. 🙂

Ostatecznie wysłaliśmy ten kod, żeby ktoś go sprawdził, żeby poddał go ocenie i żeby wyraził swoje zdanie na jego temat.

I tutaj pojawia się pierwszy potencjalny problem – no może potencjalna trudność…
Inne osoby mogą mieć przecież odmienne zdanie na dany temat.

Daną funkcjonalność można zrealizować na wiele różnych sposobów, korzystając z wielu różnych bibliotek, rozwiązań, wzorców projektowych itd.
Wiele tych decyzji nie ma tak naprawdę kluczowego znaczenia dla całości rozwiązania, jednak każdy z nas ma jakieś swoje preferencje.

Naszym zadaniem jako właściciela takiego przeglądu, jest:

• wysłuchanie tych wszystkich opinii,
• odniesienie się do nich,
• czasem dopytanie, jeżeli będzie to niezbędne,
• ostatecznie podjęcie decyzji o dalszych losach zmiany.

Code review – dlaczego warto i co nam daje❓

Dobrze zrobiony code review ma naprawdę bardzo dużo plusów i zdecydowanie jest to jedna z tych praktyk programistycznych, której nie powinno zabraknąć w zespołach. Jeżeli w Twoim zespole tego nie praktykujecie, to… pogadaj z przełożonym! 🙂 I szybko zacznijcie, bo naprawdę warto.

Code review – podstawowe korzyści

• Pomaga wychwycić błędy jeszcze przed wdrożeniem zmiany, przez co wpływa na jakość oraz stabilność kodu – dodatkowa para oczu (lub więcej, jeżeli więcej osób robi przegląd), to zawsze inne spojrzenie na dany problem i większe prawdopodobieństwo wykrycia potencjalnych błędów w kodzie.
• Motywuje do dokładniejszego pochylenia się nad danym zagadnieniem – code review motywuje programistów do rozmowy o danym rozwiązaniu, zarówno pod kątem technicznym, jak i biznesowym.
• Motywuje do dopracowania swojego rozwiązania i zwiększa poczucie własności danego rozwiązania – sama świadomość, że ktoś za chwilę będzie weryfikował mój kod i publicznie go oceniał, dla wielu osób jest bardzo motywująca, żeby lepiej go dopracować.
• Lepsze rozprzestrzenianie się wiedzy, czyli edukacja innych członków zespołu (nie tylko juniorów!) – mowa tutaj o wiedzy zarówno technicznej, jak i biznesowej. Przeglądając różne fragmenty kodu, zwyczajnie uczymy się od innych osób.

Code review – dobre praktyki ✅

Wiemy już co to jest code review, wiemy również jak go przeprowadzić oraz dlaczego warto to robić – teraz przyjrzyjmy się dobrym praktykom, które przybliżą nam jak robić to dobrze.

Code review – przygotowanie przeglądu

• Fragment kodu poddawany ocenie powinien być stosunkowo mały – przyjmuje się, że około 200 LOC (ang. line of code), a najlepiej nie więcej niż 400 LOC.
  Czemu nie więcej? Każda większa zmiana przytłacza człowieka i zwyczajnie nie chce nam się jej sprawdzać lub robimy to „na odwal”…
  Jest na tę sytuację nawet taki żart programistyczny. 😉

  10 lines of code = 10 issues
  500 lines of code = „looks fine”

• Opis problemu, który rozwiązujesz – pull request musi mieć swój opis! Opisujemy, czego dotyczy zmiana, jaki był jej cel oraz jak i dlaczego tak chcemy to rozwiązać. Warto również podlinkować zadanie z dokładniejszym opisem i historią zagadnienia.
• Wyjaśnienie danego rozwiązania – pamiętaj, że oceniający widzą tylko efekt końcowy, czyli Twoje rozwiązanie. Czasem warto jednak nakreślić przynajmniej pobieżnie tok rozumowania, jaki za nim stoi. Może po drodze pojawiły się inne alternatywne rozwiązania, które jednak z jakiegoś powodu zostały przez Ciebie odrzucone – warto wtedy o nich wspomnieć oraz wyjaśnić, dlaczego właśnie to rozwiązanie Twoim zdaniem jest najlepsze.
• Zawsze zostaw kod odrobinę lepszy, niż go zostałeś – tutaj chodzi przede wszystkim o pracę z zastanym już kodem (ang. legacy code). Jeżeli dotykamy takiego kodu i zobaczymy, że coś lekko można usprawnić albo brakuje jakiegoś testu – to pamiętajmy o tym i nie bójmy się drobnych usprawnień.
• Design review, czyli przegląd na bardzo wczesnym etapie – nikt nie powiedział, że nie możemy wykorzystać analogicznego procesu do weryfikacji samego pomysłu – czyli robimy przegląd idei, a nie już gotowego rozwiązania. Dzięki temu potencjalnie możemy uniknąć długotrwałej pracy nad rozwiązaniem, które i tak byłoby odrzucone. W takim review można przygotować fragment pseudokodu, który pomoże lepiej zrozumieć, co chcemy osiągnąć.
• Dodanie niezbędnych osób do przeglądu – na koniec dodajemy do przeglądu wszystkie niezbędne osoby, które powinny się z nim zapoznać. Często jest to przynajmniej architekt rozwiązania, inna osoba z naszego zespołu oraz właściciel danego fragmentu aplikacji.

Code review – przegląd

• Zaczynamy od przeprowadzenia code review sobie samemu – aplikacja z Twoją zmianą się kompiluje i wszystkie testy przechodzą lokalnie – prawda? 🙂
  W kolejnym kroku warto zrobić sobie samemu code review. Przejść przez całe rozwiązanie i je zwyczajnie sprawdzić. Jeżeli są jakieś nieoczywiste rozwiązania lub masz jakieś wątpliwości – to zwyczajnie sami zadajemy pytania. Jeżeli nie my, to może ktoś inny będzie znał na nie odpowiedź.
• Testy, testy, testy – zwyczajnie pamiętajmy, że je warto też pisać, oraz że warto je również sprawdzać podczas code review. Testy powinny rzeczywiście sprawdzać, czy dana logika działa, dlatego nie ignorujemy ich podczas przeglądów.
• Ocenie podlega kod rozwiązania, a nie sam autor! – to bardzo ważne, bo podczas code review czasem zwyczajnie dochodzi do konfliktów…  Różne opinie na dany temat, odrobinę gorszy dzień i może być różnie. Dlatego warto pamiętać, że oceniamy kod, a nie jego autora.
• Nie porzucamy zmiany i odpowiadamy na komentarze – po rozpoczęciu code review pamiętajmy, że dalej jesteśmy odpowiedzialni za daną zmianę. Dlatego odpowiadamy na wszystkie pojawiające się komentarze i uczestniczymy w całym procesie.
• Dawkowanie sobie czasu spędzonego na przeglądach – tajemnica sukcesu polega na odpowiedniej ilości spędzonego czasu na przeglądach. Jeżeli nie będziemy robili tego wcale lub poświęcimy na to zbyt mało czasu, to niewiele my z tego wyniesiemy oraz nasz zespół. Nie ma jednak też co przeginać w drugą stronę – po pewnym czasie zwyczajnie już nie widzimy niektórych błędów. Najlepiej poświęcić na ten cel max. 1-1,5 h dziennie.
• LGTM – dodanie prostego komentarza w stylu LGTM (ang. looks good to me) pozwala jednoznacznie stwierdzić, że dodająca osoba zapoznała się ze zmianą i nie ma nic przeciwko jej wdrożeniu – zobacz, że nie jest to jednoznaczne ze stwierdzeniem, że nie ma tam błędów!

Na koniec zostaje jeszcze tylko ustalić, kto jest odpowiedzialny za połączenie zmiany z resztą aplikacji – czyli korzystając z gita, za zrobienie merge.

Błędy podczas przeglądów – Jak nie robić code review! ❌

Wymieńmy jeszcze kilka podstawowych błędów, z jakimi możemy się spotkać podczas przeglądów kodu.

• skupienie się na stylu, wyłapywanie literówek itp. – a nie na głównym celu zmiany;
• wytykaniem personalnych błędów, czy ocenianie autora rozwiązania, a nie samego rozwiązania…
• pomijanie testów – recenzowanie testów jest często trudne, ale i nudne… – dlatego właśnie zdarza się je pomijać;
• patrzenie tylko na dodany kod, a nie usunięty – usnąć też można coś ważnego;
• zły moment na code review – gdy jesteśmy zmęczeni lub gdy coś innego pilnego na nas czeka ciężko się skupić nad przeglądem kodu;
• niewnikanie w projekt rozwiązania – może coś da się zrobić lepiej?
• za duże zmiany w ramach jednego przeglądu;
• różne zmiany w jednym pull request – jak to sprawdzać? Jak później wycofać jeżeli w jednym fragmencie znajdziemy błąd na produkcji?
• niejasne komentarze w stylu opuszczonych: fixme, todo itp.

Statyczna analiza kodu

Zasada jest prosta – po co robić coś ręcznie, skoro może zrobić to za nas automat? 🙂

Podobnie jest z code review oraz statyczną analizą kodu. Jeszcze zanim dojdzie do przeglądu kodu, takie rozwiązanie powinno zostać poddane statycznej analizie kodu, czy to z poziomu samego IDE korzystając np. z wtyczki SonarLint, czy później z SonarQube.

Jeżeli mamy na to chęci i możliwości, to można pójść nawet o krok dalej i zautomatyzować sam proces code review o taką analizę – np. definiując własne reguły w SonarQube lub dodając warunki na pokrycie kodu testami (ang. code coverage). Wtedy, jeżeli takie warunki nie zostaną spełnione, cały code review zostanie oznaczony do poprawy jeszcze zanim zaczną go weryfikować ludzie.

Code review – narzędzia

Na rynku mamy sporo narzędzi usprawniających nam code review. Na co dzień korzystam przede wszystkim z GitHub i sprawdza się on całkiem nieźle.

Mamy jednak wiele alternatyw, chociażby Upsource, Gerrit, Collaborator czy Reviewable.

Tak naprawdę wybór narzędzie jest już wtórny – ponieważ sam proces w każdym z nich wygląda bardzo podobnie.

Code review – podsumowanie 💪

Code Review to świetne narzędzie, z którym zdecydowanie warto się zaprzyjaźnić – jedno z tych bardziej użytecznych oraz moich ulubionych. Dobrze zrealizowany proces może przyczynić się do poprawy jakości kodu, szerzeniu wiedzy, ale również większej przyjemności z naszej codziennej pracy  – dlatego właśnie warto go dodać do swoich programistycznych codziennych rutyn.