Kompendium Code Review - dobre praktyki oceniania kodu
- Czas potrzebny na przeczytanie:8 minut
- Opublikowane:
Jak oceniać i przyjmować feedback odnośnie kodu? Oto złote zasady Code Review - jednego z najważniejszych procesów podczas tworzenia projektów komercyjnych.
Proces oceniania kodu nieustannie ewoluuje, nie jest stały i nie da się wskazać idealnie przeprowadzonego review. Dlatego zapytałem kilkudziesięciu programistów o to, jakimi zasadami warto się kierować. Dorzuciłem własne spostrzeżenia i oto tak powstało wielkie Kompendium Code Review.
Ten artykuł, tak jak wszystkie na tym blogu, jest Open Source - serdecznie zachęcam do dodawania własnych złotych rad. Razem stwórzmy miejsce, które pomoże wielu programistom lepiej otrzymywać i dawać feedback.
Wprowadzenie
Code Review to proces, w którym jeden lub więcej programistów ocenia Twoje zmiany do istniejącej bazy kodu.
Zmianą może być nowa funkcjonalność w systemie, usprawnienia architektury, czy narzędzi.
Proces oceniania kodu niesie za sobą wiele benefitów:
Wcześniejsze wyłapywanie błędów i jakość kodu
Podczas tworzenia kodu często nie dostrzegamy miejsc, w których popełniliśmy błąd, czy moglibyśmy zrobić coś lepiej. Inny Developer ma odmienne spojrzenie na kod, z chłodną głową może podejść do wprowadzanych zmian i wypunktować miejsca, które można by usprawnić.
Dzielenie się wiedzą
Ocenianie kodu to świetny sposób na rozwój naszych umiejętności, zarówno z perspektywy oceniającego, jak i przyjmującego feedback. Każdy z nas dysponuje innym zestawem doświadczeń, które podczas code review są niezwykle istotne. Bardzo często, podczas recenzji danej zmiany, powstają ciekawe dyskusje, z których możemy wynieść bardzo wiele. Oceniając poznajemy domenę zmiany, co idzie w parze z lepszym zrozumieniem całości naszej aplikacji.
Zwiększanie świadomości systemu
Code Review to idealny proces nie tylko dla doświadczonych programistów w projekcie, ale również dla tych początkujących. Projekt dla nowych programistów w zespole jest jak piaskownica pełna tajemnic. Dzięki ocenianiu kodu szybciej poznamy nasz codebase.
Pull Request
Wszystko zaczyna się od Pull Requesta. To narzędzie, które pozwala innym programistom zobaczyć jakie zmiany wprowadzamy. Pull Request jest podstawą dobrego Code Review.
Traktujmy nasze PR'ki jak wizytówki wprowadzanych zmian. Każda taka wizytówka powinna mieć wyszczególniony opis i cel zmieniania obecnej bazy kodu. Pomóżmy oceniającemu jak najlepiej zrozumieć to, nad czym pracowaliśmy.
Jeśli Twój zespół korzysta z dedykowanego narzędzia do zarządzania projektem i zadaniami (Jira/Asana/Clickup), to w Pull Requescie warto umieścić link do stworzonego wcześniej zadania. Twoje zmiany dotykają UI? Prawdopodobnie warto wrzucić screenshoty - dzięki temu mamy lepszy obraz tego, co oceniamy.
W przypadku Pull Requestów rozmiar ma znaczenie, serio. Im mniej wprowadzanych zmian na raz, tym lepiej. Mając przed sobą 10 linijek kodu, każdej poświęcimy uwagę, nie można tego powiedzieć, gdy oceniamy PR z 1000 zmienionych linii. Jeśli Twój zespół ma problem ze zbyt dużymi Pull Requestami, może warto ustalić granicę rozmiaru? Nie musimy od razu podpisywać paktu z diabłem, ale warto o tym porozmawiać.
Zacznij od siebie
Pierwszym recenzentem Twojego kodu, powinieneś być Ty sam. Najgorszą rzeczą, jaką możemy zrobić jest nieprzejrzenie wcześniej stworzonego przez nas kodu. Szanujmy swój czas.
Podczas pracy debugujemy, zakomentowujemy, przenosimy kawałki kodu. Nie ma nic w tym złego, dopóki takie smrodki nie wychodzą na światło dzienne. Nie marnujmy czasu recenzenta na wypominanie nam o nieusuniętym console.log().
Traktujmy nasze zmiany jak referaty w podstawówce. W brudnopisie możemy robić co nam się żywnie podoba - skreślać, bazgrać i rysować szlaczki. Jednak finalna wersja naszej pracy powinna być jak najlepsza, bez zbędnego chaosu.
Nikt gorszy, nikt lepszy
Code Review to proces, który nie powinien dyskredytować programistów ze względu na umiejętności, czy doświadczenie w projekcie. Kropka.
Dzielenie się wiedzą nie przebiega jedynie od Seniora do Juniora. Mniej doświadzczeni programiści nie tylko mogą zdobywać wiedzę, ale również się nią dzielić, nawet z dużo bardziej doświadczonymi developerami.
Jeśli jesteś Juniorem:
Nie bój się oceniać kodu bardziej doświadczonym programistom. Oni nie są Alfami i Omegami, każdy z nich popełnia błędy. Nie dość, że podczas oceny kodu możesz się wiele od nich nauczyć, to jednocześnie przekazujesz swoje doświadczenia, które są niezwykle cenne.
Jeśli jesteś Seniorem:
Oceniaj kod mniej doświadczonych programistów. Dziel się swoim doświadczeniem i pomagaj zrozumieć zmiany. Schowaj ego do kieszeni, przyjmuj krytykę od mniej doświadczonych developerów. Nie bądź Rockstar Senior Developerem, którego nikt nie lubi :)
Czy rozumiem dany kod?
Jednym z głównych celów Code Review jest lepsze zrozumienie systemu, w którym pracujemy. Jeśli oceniając kod, nie rozumiesz jego przeznaczenia, tracisz jeden z benefitów.
Czegoś nie rozumiesz? Dopytuj, dopytuj i jeszcze raz dopytuj, serio. Nie ma nic złego w niewiedzy. Nie wiesz co robi dany kod, albo dlaczego coś zostało zrobione w ten sposób, a nie inny? Poproś autora kodu o wyjaśnienie, jeśli będzie miał on odpowiednie nastawienie, na pewno z chęcią wytłumaczy Ci, dlaczego tak podszedł do rozwiązania problemu.
W takich sytuacjach często uczymy się podejścia drugiej osoby, rozumiemy lepiej istotę zmian - z dopytywania wynikają same dobre rzeczy. A jeśli autor kodu potraktuje Twoje pytanie jako "atak", podeślij mu ten artykuł, musi nadrobić wiele zalogłości :)
Jak formułować poprawki?
Formułowanie poprawek to zdecydowanie najcięższa rzecz w całym procesie. Każdy z nas chce się dobrze czuć w projektach, w których pracujemy. Recenzje tak jak mogą bardzo usprawnić proces wytwarzania oprogramowania, tak mogą również zniechęcać innych do dalszej pracy. Aby uniknąć takich sytuacji, warto kierować się kilkoma zasadami:
Zrozumienie
Postaraj się jak najbardziej zrozumieć drugą osobę. Bądź miły. Każdy z nas jest inny, każdy odbiera krytykę w inny sposób. Kluczem do właściwej recenzji jest poznanie perspektywy innego programisty. Może jest on nowy w projekcie i nie rozumie pewnych zasad, którymi się kierujecie? Może ta osoba nie jest najlepsza w danym temacie?
Wejdź w skórę drugiej osoby, oceniaj kod tak, jak chciałbyś, żeby ktoś oceniał Twoją pracę.
Brak roszczeniowości i odpowiedni ton
Inaczej będziesz oceniał kod nowego Juniora w projekcie, a inaczej kod swojego kolegi z zespołu, z którym pracujesz kilka lat. Dostosuj się do osoby, która wystawiła swój kod do oceny. Nie bądź sędzią, który wymierza karę. Postaw się w roli osoby, która wyciąga rękę, chce pomóc, a nie skrytykować dane rozwiązanie.
Nie krytykuj osoby, krytykuj kod. Nie próbuj udowadniać komuś, że to on jest głupi i nie rozumie jak powinien być napisany dany kod.
Zadawaj pytania
Dobrą techniką formułowania poprawek jest zadawanie pytań i wchodzenie w dyskusję.
Nie pisz:
Masz zmienić to i to, to jest źle.
Zamiast tego zadawaj pytania:
Uważam, że lepiej by było jakbyś zrobił to tak, bo... Co o tym myślisz?
Taka formuła jest znacznie mniej inwazyjna, pozwala zrozumieć drugiej osobie swój błąd. Dzięki temu nie stajemy się wielkim dyktatorem, sędzią czystego kodu, a kolegą z zespołu, który pomaga usprawnić nasz wspólny kod w projekcie.
Operuj na konkretach
Upewnij się, że druga osoba rozumie co starasz się przekazać. Bądź konkretny.
Zamiast pisać:
Ale ta funkcja jest zawalona, weź to jakoś rozdziel.
Napisz:
Ta funkcja operuje na różnych poziomach abstrakcji, uważam, że warto wydzielić to, to i to...
Newsletter dla Frontend Developerów 📮
Przyjmowanie krytyki
Perspektywa osoby, która wystawia na świat swoją pracę i przyjmuję krytykę jest nieco bardziej bolesna. Aby nasze Code Review było skuteczne, obie strony barykady muszą mieć właściwe podejście.
Nie jesteś swoim kodem. Nie bierz do siebie merytorycznej krytyki kodu, to tylko zbiór głupich literek. Nie definiuje Ciebie jako człowieka, ani Twoich umiejętności. Mogłeś czegoś nie zauważyć, mogłeś mieć gorszy dzień. Każdy popełnia błędy, nawet ci najlepsi.
Traktuj kod jako osobny byt, spróbuj oddzielić emocje od wyników swojej pracy. Jeśli ktoś proponuje Ci lepsze rozwiązanie, nie brnij na siłę w to, co już zrobiłeś. Bądź otwarty na poprawki i zdobywanie wiedzy. Jeśli nie rozumiesz krytyki, dopytuj, staraj się zrozumieć i znaleźć najlepsze rozwiązanie.
Nie tylko krytyka
Code Review to nie tylko wytykanie błędów we wprowadzanych zmianach. Doceniajmy swoją pracę i zaangażowanie. Widzisz, że ktoś zrobił dobrą robotę? Powiedz mu to!
Rozwiązywanie konfliktów
Nawet jeśli będziemy stosować się do powyższych założeń, to nadal jesteśmy tylko ludźmi - mogą pojawić się zgrzyty. Co w takich sytuacjach robić?
Pierwsze i najważniejsze, postaraj się jak najbardziej zrozumieć drugą osobę. Co kieruje innym programistą, czy na pewno zrozumiał on Twoje intencje?
Bądź konkretny, spraw, żeby ocena kodu była rzetelna. Popieraj swoje uwagi dodatkowymi źródłami. Staraj się wytłumaczyć istotę proponowanych zmian, dlaczego warto usprawnić dany kawałek kodu.
A co jeśli nadal nie możecie znaleźć złotego środka? Warto w takich sytuacjach przenieść "konflikt" na światło dzienne. Włączcie innych programistów w proces decyzji. Spotkajcie się, wymieńcie opiniami na dany temat, wspólnie podejmijcie decyzję.
Dostosuj odpowiednią formę
W przypadku większych usprawnień, forma pisemna może okazać się nieoptymalna. Wymienianie się asynchronicznie komentarzami może przeciągnąć znacząco cały proces.
Wtedy warto pomyśleć na przeniesieniem oceny na inną formę. W obecnych czasach, gdzie duża część z nas pracuje zdalnie, nie jest problemem poświęcenie kilkunastu minut na zdzwonienie się. Taki sposób często okazuje się być bardziej efektywny. Szybciej możemy zrozumieć, co druga strona miała na myśli, mamy natychmiastowy feedback.
Nie skupiaj się na pierdołach
Procesy są ważne, jeśli możesz coś zautomatyzować - zrób to.
Formatowanie i lintowanie kodu to rzeczy, które powinna załatwiać za nasz maszyna. Zamiast wytykać komuś źle sformatowany kod, skonfiguruj np. Prettiera w swoim projekcie, będziesz mógł wtedy skupić się na ważniejszych aspektach review.
Spójność z resztą projektu
Każdy z nas ma własne preferencje, jedni lubią arrow functions, inni stawiają na klasyczne function. Spieranie się o to, która wersja jest lepsza nie ma sensu.
Jeśli projekt nie ma wyznaczonego style guide, warto poświęcić czas na jego przygotowanie. Oszczędzajmy swój czas, korzystajmy z automatycznych reguł lintera i rozróżniajmy opinie od właściwych propozycji zmian.
Nie wszystko na raz
Wprowadzanie nowości do istniejącego już kodu często może prowadzić do sytuacji, w której recenzent zasugeruje mały refactor.
A może poprawiłbyś przy okazji jeszcze to?
Chęć usprawnienia kodu to nic złego. Musimy jednak z tym uważać i nie dać się temu pochłonąć. Skupmy się na wystawionej do review funkcjonalności, usprawnienia pobliskiego kodu mogą być wykonane w osobnym Pull Requeście.
Podsumowanie
Code Review to proces, w którym możemy stracić dużo czasu i nerwów. Stosując wspomniane "dobre praktyki" recenzje kodu nie będą nieprzyjemną i czasochłonną krytyką, a okazją do nauki i ciągłego usprawniania istniejącego kodu.
Jeszcze raz dziękuję wszystkim, którzy przyczynili się do powstania tego artykułu - przyda się każdemu z nas w codziennej pracy :)
Chciałbyś coś dodać / usprawnić w tym artykule? Śmiało wrzucaj swoje propozycje w repo na GitHubie!
