Nie jesteś przekonany do code review? Oto kilka porad na start

Jako programiści każdego dnia tworzymy niezliczone ilości kodu. Testujemy go, upiększamy, a na koniec weryfikujemy po raz kolejny jego spójność i niezawodność podczas continuous integration. Natomiast prawdziwa wartość wykorzystanego rozwiązania może być sprawdzona jedynie przez drugiego programistę, który, czytając kod, zna domenę biznesową, firmowe praktyki i style guide, a do tego zna i wprowadza na co dzień reguły czystego kodu.

Robert Duraj. Programista w zespole Evojam, na co dzień zajmujący się technologiami frontendowymi i mobilnymi; ewangelista pracy zdalnej i asynchronicznej, pozwalającej na zdrowy work-life balance; po godzinach rycerz Jedi, który jednak chętnie zamienia X-Winga na kawę i dobrą książkę.

Największą zaletą sprawdzania kodu przez drugą osobę jest fakt, że posiada ona zupełnie inny punkt widzenia od naszego. W tym artykule postaram się pomóc niezdecydowanym, zajrzeć w głąb procesu code review: czym jest i jak może nam pomóc w codziennej pracy.

Zróbmy sobie review!

Czym dokładnie jest code review? Najprościej rzecz ujmując, jest to czytanie naszego kodu, przez kogoś innego. Kropka.

Jedną z głównych zasad czystego kodu jest pisanie go w ten sposób, by inni ludzie mogli go zrozumieć. Cytując Martina Fowlera:

Byle głupiec potrafi pisać kod zrozumiały dla komputera. Dobry programista pisze kod zrozumiały dla ludzi.

Code review staje się zatem pierwszym i najbardziej krytycznym krokiem do wprowadzenia tej reguły w życie. Jeżeli Twój kolega z zespołu nie jest w stanie zrozumieć kod, który właśnie został wrzucony do repozytorium, to znaczy, że coś poszło nie tak.

W dzisiejszych czasach jako deweloperzy mamy tysiące różnorakich narzędzi, pozwalających nam na przeprowadzenie takiego przeglądu. Github, Bitbucket czy Gitlab posiadają specjalne rozwiązania w swoich interfejsach, pozwalające na śledzenie zmian i dodawanie komentarzy do konkretnych linii czy nawet znaków. Dzięki temu, code review może być przeprowadzone sprawnie, nawet jeśli nad głowami wisi nam deadline.

Budujemy zespół bazując na code review

Programowanie jest pracą twórczą i jako taka, jest widziana przez każdego w inny sposób. Każdy problem może zostać rozwiązany na kilka(naście) różnych sposobów, a na dodatek – każdy z nich może być poprawny! Podczas review nie skupiasz się nawet tak bardzo na kodzie, zmiennych czy funkcjach, ale na sposobie, w jakim Twój kolega podszedł do rozwiązywanego zadania. Zaczynasz patrzeć na problem oczami kogoś innego.

W trakcie code review zaczynasz myśleć o problemie w nowych kategoriach – z różnych punktów widzenia, które konfrontujesz ze swoim własnym. Ostatecznie prowadzi to do dyskusji nad konkretnymi partiami kodu.

Właśnie ten ostatni punkt ma największy wpływ na budowanie zespołu z pomocą code review. Wszystkie nieporozumienia wokół kodu są zebrane w jednym miejscu – w komentarzach. Tam bowiem możesz jasno wyrazić swoje obawy, oczekiwania i wątpliwości oraz omówić je z całym zespołem w trakcie developmentu.

Uwaga! Istnieje jednak bardzo duże niebezpieczeństwo w tym podejściu. Przede wszystkim musisz zachować pełną neutralność w swoich komentarzach. To tylko Twoja prywatna opinia, do której masz prawo, ale musi być wyrażona właśnie w ten sposób – jako prywatna opinia, nie jako dyrektywa ex cathedra. Nawet jeśli jesteś liderem technicznym czy programistycznym bogiem, przede wszystkim powinieneś szanować swoich kolegów i sposób, w jaki próbują rozwiązać dany problem.

Miej w głowie, że rozwiązując problem w ten czy inny sposób, podlegali różnym wpływom, takim jak choćby przyzwyczajenia z poprzedniej pracy czy innych technologii. Najważniejszą cechą podczas przeprowadzania code review jest pozostawienie otwartego umysłu na nowe rozwiązania, mając w głowie jednak cały czas dobro projektu i konsekwentne stosowanie tych samych reguł we wszystkich przypadkach.

Oczywiście wszystkie te sugestie mają rację bytu, gdy mówimy o rozwiązaniach stricte koncepcyjnych. Pod względem czystości kodu zawsze powinieneś pozostać bezlitosny dla wszelkich uchybień.

Chcąc rozwijać kulturę przeprowadzania code review, zespół musi stosować się do powszechnie przyjętych i zaakceptowanych przez wszystkich reguł. Jednocześnie, każdy programista musi pamiętać o tym, że code review ma na celu pomóc drugiej osobie i tak powinno być to odbierane. Takie podejście buduje silny, wspierający się zespół, z solidnymi fundamentami do rozwoju.

Rozwijaj się, ucz się i nauczaj

Będąc pisarzem, poprawiasz swój warsztat pisząc. To oczywiste. Jednak zanim do tego dotrzesz, obserwujesz, jak inni autorzy tworzą swoje książki. W jaki sposób kreują swoje postacie, w jaki sposób planują całe fabuły, jak rozwiązują wątki. Z takim bagażem wiedzy możesz spróbować robić to na własny sposób. Nie kopiując, tylko wyciągając esencję z ich doświadczenia i przekształcając ją na swoje własne potrzeby.

Ten proces wygląda analogicznie dla programowania. Stajesz się lepszym programistą nie tylko przez pisanie nowych algorytmów czy całych aplikacji. Stajesz się lepszym programistą także przez czytanie czyjegoś kodu. Robiąc to, pasywnie uczysz się nowych rozwiązań i metodologii, zaczynasz myśleć o kodowaniu z szerszej perspektywy.

Możesz myśleć, że Twój kod jest perfekcyjny, ale prawdopodobnie nie jest.

Nikt w krótkiej historii komputeryzacji, nigdy nie napisał kawałka perfekcyjnego kodu. Mało prawdopodobne, że ty będziesz pierwszym, który to zrobi – Andy Hunt

Nie martw się, tworzenie oprogramowania jest procesem, w którym wszyscy uczymy się od siebie. Code review jest jednym z najlepszych narzędzi, oferującym zyski dla obu stron. Korzysta na tym zarówno programista, jak i osoba czytająca kod. Dzięki temu możesz dzielić się swoją wiedzą i doświadczeniem z innymi programistami, po prostu podsuwając niewielkie sugestie usprawnień. Pozwól, by te komentarze były wypadkową Twoich najlepszych programistycznych umiejętności.

Komentarze na temat testów jednostkowych mogą pomóc Twoim kolegom lepiej rozumieć sens ich tworzenia i utrzymywania. Z drugiej strony, Twój chaotyczny kod mógłby być zrefaktoryzowany z pomocą kogoś z doświadczeniem w metodologii Domain Driven Development. Te proste przykłady pokazują, jak potężnym narzędziem potrafi być code review, jeśli opierasz go na czystej chęci pomocy i dzielenia się wiedzą.

Richard Feynman twierdził, że możemy się nauczyć nowych rzeczy jedynie poprzez tłumaczenie tych zagadnień innym w najprostszy możliwy sposób. Rozwijaj się, ucz się nowych metodologii, dziel się wiedzą i dyskutuj o nich z kolegami, żeby utrzymać bystrość umysłu i programistyczne umiejętności na najwyższym poziomie.

Rutynowe code review

Jak zostało powiedziane na początku, code review jest jednym z systemów wczesnego ostrzegania w programowaniu. Kiedy sprawdzasz czyjś kod, dostrzegasz, jak dużo błędów sam popełniasz każdego dnia. Jest to jednym z podstawowych powodów, dla których warto namówić zespół do wdrożenia regularnego code review.

Dojrzałe zespoły traktują code review jako codzienny zwyczaj i nikt w takich zespołach nie jest w stanie sobie wyobrazić, że jakakolwiek zmiana mogłaby zostać wdrożona bez akceptacji. Oto kilka podpowiedzi, o czym warto pamiętać przeprowadzając review, bazujących na doświadczeniach z naszego zespołu:

• Im więcej osób, tym lepiej. Code review przeprowadzane jest zawsze przez dwie bądź trzy osoby. Jeżeli projekt na danym etapie nie jest wystarczająco duży, żeby zebrać taką liczbę recenzentów, zapraszamy kolegów z innych projektów, żeby dołączyli. Nie ma wymówek od tego, nawet jeśli prowadzisz projekt samodzielnie.
• Rób je zawsze. Code review jest obowiązkowe. Niezależnie od tego czy zmiana jest duża czy mała, musi znaleźć się ktoś, kto rzuci na nią okiem i zaakceptuje. Najlepszym sposobem, by utrzymać tę regułę w mocy, jest ustawienie wymaganej liczby akceptacji, zanim kod będzie możliwy do zmerge’owania.
• Zaplanuj czas na review. Jeżeli zespół jest duży i produkuje bardzo dużo kodu do sprawdzenia, najrozsądniejszym wyjściem jest przeznaczenie konkretnej części dnia na przeprowadzenie code review. Pozwoli to uniknąć rozproszeń i utrzymać czystą listę oczekujących pull requestów.
• Rób małe zmiany. Nikt nie lubi dużych partii kodu do sprawdzenia. Jeżeli planujesz wprowadzić bardzo dużą zmianę, podziel swoją pracę na mniejsze partie i wysyłaj je do review. Małe pull requesty są akceptowane dużo szybciej.
• Trzymaj się przyjętych zasad. Bardzo często code review sprowadza się do dostrzegania błędów odnoszących się do stylu kodu. Żeby tego uniknąć, warto przyjąć konkretne zasady prowadzenia projektu w zespole, narzucić wszystkim firmowy style guide i dostosować do niego narzędzia odpowiedzialne za automatyczne sprawdzanie stylu. Dzięki temu w prosty sposób utrzymasz porządek i jednolitość kodu w projekcie, bez potrzeby wspominania o tym na review.
• Czytaj uważnie. Code review nie powoduje, że odpowiedzialność za kod jest rozproszona. Bierzesz pełną odpowiedzialność za kod, zarówno jako developer, jak i recenzent. Skup się na uważnym przeczytaniu i zrozumieniu czytanego kodu. Potraktuj swoją rolę na poważnie.

Powyższe wskazówki, którymi kierujemy się w naszej codziennej pracy w Evojam, mogą pomóc Ci przeprowadzać code review efektywnie. Nim jednak zaczniesz rewolucję w swoim zespole, porozmawiaj z kolegami i razem stwórzcie konkretne zasady, którymi będziecie się kierować przeprowadzając review. Mam nadzieję, że te podpowiedzi pomogą Ci wprowadzić taką rutynę dla dobra zespołu i projektu.

Problem jednoosobowej armii

Code review zdaje egzamin, gdy przeprowadzane jest przynajmniej przez dwie osoby. Co jednak, gdy tworzymy projekt sami, nie mając wokół nikogo, kto mógłby zerknąć na to, co wrzucamy do repozytorium?

Przede wszystkim powinieneś przestać myśleć o swoim kodzie jak o swojej własności, której nikt nigdy nie zobaczy. Zawsze istnieje prawdopodobieństwo, że kiedyś przyjdzie Ci podzielić się swoim kodem z kimś innym. Nie pozwól, byś musiał się za niego wstydzić.

Nawet jeśli pracujesz sam, nie powinieneś ignorować code review. Możesz go przeprowadzać na wiele różnych sposobów:

• Rób code review samemu sobie. Bierz odpowiedzialność za Twój kod, traktuj go, jakby był napisany przez kogoś innego i sprawdzaj go z taką samą skrupulatnością, jakbyś sprawdzał kod koledze z zespołu. Twórz pull requesty z własnymi rozwiązaniami, próbuj czytać wielokrotnie i rozumieć dokładnie, co napisałeś. Problemem tego podejścia jest tylko jeden punkt widzenia. Sprawdzasz własny kod tylko i wyłącznie z bagażem własnych doświadczeń i umiejętności, co może nie być tak efektywne, jak code review od kogoś zupełnie innego.
• Wysyłaj małe partie kodu do znajomych. Możesz poprosić zaprzyjaźnionych developerów, żeby w wolnej chwili spojrzeli na Twój kod. Szczególnie na ważne części Twojej aplikacji, by upewnić się, że niczego nie zapomniałeś. W tym celu nie musisz wcale dzielić się całym kodem, a jedynie jego niewielką częścią. W tym przypadku wprowadzasz do review różne punkty widzenia, jednak recenzenci mogą nie rozumieć do końca kontekstu i domeny biznesowej, mając niewielką wiedzę o projekcie.
• Publikuj kod na StackOverflow. StackOverflow to nie tylko serwis z odpowiedziami na każde możliwe pytanie programistyczne, to także świetne miejsce do pokazania swojego kodu w celu przeprowadzenia review. Możesz być pewien, że ktoś odpowie na Twoją prośbę w kilka minut. Problem z tym rozwiązaniem jest podobny do tego z poprzedniego punktu – niewielka świadomość kontekstu biznesowego.

Jak widzisz, przeprowadzanie code review w jednoosobowym zespole nie jest czymś niewykonalnym. Jakkolwiek, każda z tych opcji ma jakieś słabe strony. Nie powinno to jednak być dla Ciebie powodem do całkowitej rezygnacji z dyskutowania o swoim kodzie z innymi developerami.

Podsumowanie

Praktykowanie code review popycha Twój zespół do ciągłego uczenia się i dzielenia wiedzą z innymi. Buduje kulturę rozwoju i wzrostu kompetencji. Przy odpowiednim nastawieniu i sposobie komunikowania, buduje także solidne relacje zawodowe.

Code review oferuje bardzo dużo zalet przy stosunkowo niskim koszcie. Zachęcam, aby przekonać się o tym w praktyce i otworzyć nową furtkę do rozwoju swojego zespołu, wprowadzając code review do Waszej codziennej, programistycznej rutyny.

Artykuł został pierwotnie opublikowany na evojam.com. Zdjęcie główne artykułu pochodzi z unsplash.com.

Oferty pracy z