Jak ulepszyć Code Review? 7 Sprawdzonych Praktyk

W dzisiejszym odcinku porozmawiamy o tym, dlaczego trzeba robić Code Review. Powiemy też o 7 dobrych praktykach robienia Code Review. Dodatkowo mamy dla was coś ekstra, więc zostańcie z nami. Nazywam się Jakub Pawlak. Jestem Aleksander Lubych. Was witamy w Subiektywnym Frontendzie. Po co w ogóle robić Code Review i na co to komu? Jest bardzo wiele powodów, żeby robić Code Review. Jest bardzo mało powodów, żeby je nie robić. Słucham. Jednym z głównych powodów, dla których warto robić Code Review jest to, żeby ktoś inny po prostu w zwyczajnym świecie zerknął na twój kod, sprawdził czy nie ma tam jakiejś patologii, czyli jakichś dramatycznych błędów, antypaternów, które warto wyeliminować już na tym etapie, bo jak wiemy wszystko co dotrze do produkcji jest ciężkie do zmiany.

No, zostaje tam na zawsze, jak każda w sumie fuszerka i każda prowizorka. Prowizorka, tak. Każda prowizorka zostaje z nami na dłużej, więc Code Review w zasadzie pomaga nam tych prowizorek robić jak najmniej, czyli po prostu mamy dodatkową parę oczu, która weryfikuje, czy to co wyprodukujemy ma sens. Mówiłeś o tym, że możemy też wyłapać jakieś problemy. Ta weryfikacja pozwala nam też sprawdzić, czy nasz kod spełnia nasze założenia. Oczywiście myślę, że rzadko kiedy wchodzimy jako osoby, które robią review, wchodzą aż tak głęboko, że jakieś tam biznesowe wymagania i tak dalej, co oczywiście też jest na plus, ale nie zawsze się zdarza, więc myślę, że skupiamy się po prostu na tym, żeby kod był sensowny i też wątek taki naukowy tutaj, edukacyjny jest bardzo istotny, bo Code Review może też służyć nam po prostu do nauki.

Ja nie wiem, czy jest jakiś lepszy sposób do nauki tak naprawdę w firmie niż Code Review, no bo pair programming jednak wymaga tego, żebyście razem usiedli i jednak spędzili ten czas dokładnie w tym samym momencie. Code Review pozwala jednak robić to bardziej offline i tak naprawdę uczyć się dzięki tej możliwości asynchroniczności. To w takim razie może przejdźmy do pierwszej dobrej praktyki. Nie jesteś swoim kodem. Jest to dość proste sformułowanie, ale kryje się za tym dość wiele. Nie powinniśmy się przywiązywać do naszego kodu, ponieważ wtedy dość ciężko jest nam się rozwijać, tak naprawdę, bo jeżeli nie pozwalamy zwracać nam uwagi... No właśnie, bo tutaj takie ogólniki. A w zasadzie chodzi o to, że po prostu żeby nie przywiązywać się do tego, że jak ktoś nam skomentuje, że ten kod jest do dupy, to nie chodzi o to, że my jesteśmy do dupy.

Chodzi o to, że ten kod, który napisaliśmy może akurat nie jest najlepszym kodem i to po prostu nie jest jakaś forma... Nie. Nie. Ale o tym opowiemy też później. One służą też temu, żebyśmy ten kod pisali dobry i lepszy. Code Review to też dyskusja. Musimy pamiętać o tym, że Code Review to też jest szansa na to, żeby zaprezentować rozwiązanie na jakiś problem i otrzymać jakąś opinię na ten temat. To znaczy, to nie musi być od razu docelowe rozwiązanie, tylko to może być draft, to może być propozycja czegoś i tak naprawdę oczekujesz od swoich kolegów, że ocenią to w jakiś sposób albo nakierują cię, albo stwierdzą, że hej...

To się kompletnie nie nadaje, może pójść w tym kierunku, albo powiedzą dobra robota, nie widziałem czegoś takiego wcześniej, więc trzeba być otwartym na dyskusję. Ja dodam w sumie dwie rzeczy. Jedna rzecz to jest to, że czasami w Code Review lubię zadawać pytania. I te pytania nie są po to, żeby ktoś od razu to poprawił, tylko te pytania są faktycznie pytaniami. Ja po prostu czasami jestem ciekaw, dlaczego coś jest zrobione w taki sposób, a nie inny i liczę na właśnie jakąś dyskusję, na jakąś odpowiedź, a niekoniecznie jakby traktujemy czasami pytania w Code Review jako faktycznie pytania, a nie zaproszenia do poprawek. Oczywiście to też jest inna sprawa, że musimy też jako osoby robiące review, musimy być bardzo dosłowni, czyli nie używajmy jakichś tam sarkazmów, czy nie używajmy pytań, jeśli chodzi nam o to, żeby coś poprawić.

Tak się nie robi. Ale czasami pytania są po prostu pytaniami, a to co powiedziałeś, to to jest takie zaproszenie do dyskusji. To jest też fajna sprawa, jeśli robimy coś, czego nie jesteśmy do końca pewni, to Code Review po prostu może nam służyć jako taki etap w robieniu kodu. Kolejna dobra praktyka. Automatyzujmy co się da. Umówmy się. Linter, Pretier to powinien być w zasadzie już standard. Jeśli jeszcze nie masz Lintera i Pretiera w swoim projekcie i współpracujesz z innymi programistami, to wiedz, że coś się dzieje. Coś jest nie tak. Coś jest nie tak. Myślę, że po prostu sprawdzanie takich bezsensownych rzeczy jak zła indentacja czy cudzysłów zamiast podwójnego albo w ogóle dyskusje o tym, jak jest formatowany kod albo o rzeczach, które po prostu możemy zautomatyzować są trochę bez sensu, więc jeśli mamy do tego narzędzia, to fajnie jest.

I tutaj w sumie wspomniałem o Priterze, to jest w kontekście formatowania, ale linter to też nie jest coś co gryzie, no bo tam trzeba jednak tą konfigurację dodać. Możemy oczywiście użyć jakichś predefiniowanych presetów, możemy też dodać nasze własne reguły po uzgodnieniu ich oczywiście z innymi ludźmi, z którymi współpracujemy. A to koniec końców prowadzi do mniejszego Code Review, bo po prostu Nie znajdują się tam takie rzeczy, które są powtarzalne i bez sensu. Od ogółu do szczegółu, czyli plan na robienie Code Review. Jeżeli robisz komuś Code Review, dobrze jest zaczynać od ogólnego umiejscowienia kodu, czyli czy on się nadaje na właśnie takie umiejscowienie. Czyli przeglądamy strukturę plików, nazwy, foldery i tak dalej, takie podstawowe rzeczy.

Oczywiście możemy to zrobić, zautomatyzować, patrz punkt wylej, ale możemy też podczas Code Review wspomnieć o tym, że przydałyby się może jakieś testy jednostkowe, oczywiście jeśli je piszemy. Kolejna dobra rada. Sprawdzajmy przypadki brzegowe i obsługę błędów. Oczywiście powinniśmy zajrzeć do testów jednostkowych jeśli istnieją, ale czasami nie istnieją i wtedy warto sprawdzić czy np. argument, który nasza funkcja przyjmuje może być dowolną rzeczą. A oczywiście w Javascriptie wiemy, że może być absolutnie wszystkim, więc może warto sprawdzić, czy nasz kod po prostu zawiera taką obsługę takich wyjątków i będzie takie bulletproof na przyszłość.

Bo ten kod, który piszemy, jeśli jest dobrze ustrukturyzowany, to ma tendencję do tego, że po prostu dosyć długo żyje i nie powinniśmy też do niego często zaglądać i często go zmieniać. Jeśli go często zmieniamy, to może coś jest nie tak, może go warto podzielić na mniejsze, czyli patrz Punkt wyżej, o którym wspomnieliśmy, czyli no, zaczynamy od ogółu. Więc unikamy rzeczy, które robią zbyt dużo rzeczy zaraz. Ale tutaj wspomniało się o tym, że warto, żeby ten kod był bulletproof, jeżeli chodzi o przyszłość, ale czasem mam wrażenie, że ten kod nie jest nawet bulletproof, jeżeli chodzi o teraźniejszość. Bo nie obsługuje właśnie tych warunków brzegowych. Zaplanuj czas na Code Review. Istotne jest to, żeby te Code Review robić.

Robić je w miarę szybko, bo ktoś jest zależny od tego, że my spojrzymy na ten kod. I czasem ta osoba nawet nie może skończyć swojego zadania, bo nikt nie spojrzał na ten kod. No i teraz wyobraźmy sobie, że mamy dobry flow i czekamy na Code Review. Here we go again. I czekamy na to Code Review tydzień. Dlatego dobrą praktyką jest, żeby wbić sobie do kalendarza jakieś spotkanie cykliczne, na przykład codziennie, półgodzinne, zarezerwowane na Code Review. Dzięki temu będziesz zawsze dostać powiadomienie o tym, że hej, trzeba zrobić Code Review. No dobra. A czy ty się do tego stosujesz? Fifty-fifty, szczerze mówiąc. Jak zobaczę powiadomienie i wiem, jakby jest chwila na to i mam na to przestrzeń, to odpalę na pewno Bitbucketa.

Wow. Ale se mógł bit paketa. A później przejdziesz dalej, okej. Ale ja zgadzam się jak najbardziej z tym, żeby mieć po prostu jakiś taki punkt, punkt dnia, gdzie robimy Code Review. To spotkanie w zasadzie nie musi być, jakby nie musimy się do niego stosować zawsze, ale dobrze mieć taką przypominajkę, że hej, tam może ktoś na ciebie czeka. Ja nawet, jeśli mam to spotkanie w kalendarzu wbite, Nie zawsze robię to Code Review w tym czasie, ale robię to na przykład chwilę wcześniej, chwilę później, bo akurat przeglądałem kalendarz, co tam mnie czeka, jakie wspaniałe spotkania dzisiaj będą i po prostu zaglądam sobie do Code Review, też odpalam Bitbucketa, nawet czasem odpalę jakiegoś pull requesta, sprawdzę jeden plik i później proza życia. I 4 godziny później patrzysz na drugi plik.

I tak to się ciągnie przez tydzień. No więc zachęcamy do tego, żeby robić to Code Review no w miarę regularnie. Sprawdzajmy, czy ktoś na nas nie czeka. A myślę, że czasami też warto komuś przypomnieć i poprosić o to Code Review wprost. Jak ustrukturyzować komunikację w Code Review, czyli Conventional Comments? Jest takie podejście, które nazywa się właśnie Conventional Comments. To podejście polega na tym, że strukturyzujemy w pewien sposób nasze komentarze w Code Review, czyli dodajemy im taki jakby prefiks, czyli dodajemy Kiedy się czepiamy, nazywamy to po prostu, że się czepiamy.

Więc to pozwala nam też w pewien sposób uprzedzić naszego kolegę, który oczekuje na nasze review, że dany komentarz jest danego typu, co trochę upraszcza zrozumienie. No tak, bo od razu mówisz czego oczekujesz tak naprawdę w odpowiedzi na ten komentarz. Tak, więc myślę, że to jest fajne podejście. Nam się to całkiem nieźle sprawdza. Ja lubię tego używać. Nie jest to jakieś specjalnie skomplikowane. To jest po prostu kwestia tego, że dodajemy dodatkową informację, która pomaga zrozumieć, o co nam w tym komentarzu chodzi. Następnie powiedzieliśmy, że będzie coś ekstra, czyli ekstra punkt. I ten punkt dotyczy tego, że warto chwalić ludzi. Warto ich chwalić za to, jak robią coś fajnie.

To akurat prawda, bo Code Review bardzo często skupiamy się na tym, żeby wytknąć komuś błąd, albo znaleźć jakąś nieścisłość, albo po prostu doszukać się dziury w całym, a po prostu takie czasami pochwalenie, że hej, wow, ale fajny pomysł, albo bardzo podoba mi się ten kod, albo super, że są testy jednostkowe i wcale nie musiałem o nich wspominać. To jest miła rzecz, po prostu osładza nam trochę... Praca. To, co zauważyłem po sobie, to jest to, że kiedyś po prostu pewne rzeczy sobie myślałem, jak czytałem Code, na przykład myślałem, o, ja czegoś takiego wcześniej nie widziałem i leciałem dalej i zwracałem uwagę tylko na to, co mi się nie podoba, a teraz właśnie dzięki tym conventional comments dodaję taką informację, że hej. Fajne. Czegoś takiego nie widziałem. No właśnie, bo powiedziałeś bardzo ciekawą rzecz, że w Code Review trochę skupiamy się na tym, co jest złe.

I dlatego to Code Review przeistacza się po prostu w takie szepialstwo. Ale to w zasadzie jest praktyka, z której można zrobić... Przejdźmy do przyszłości. Jak widzisz przyszłość, jeżeli chodzi o Code Review? Czy AI tutaj gdzieś się pojawia na horyzoncie? No właśnie, myślałem o tym, czy dodać tutaj AI, bo przecież trzeba wszędzie wrzucić AI. Oczywiście, na pewno będą, będzie coraz więcej narzędzi, które robią to Code Review z automatu, no bo koniec końców polega to na przyjrzeniu kodu i sprawdzenia, czy wszystko jest okej i czy ma to sens i czy ma się kupy, więc no...

Będzie to na pewno szło w tą stronę. Czy zwykłe Code Review z nami zostanie? Na pewno, dopóki piszemy kod i dopóki wrzucamy go na produkcję i dopóki możemy tą produkcję wysadzić, to to Code Review będzie potrzebne w takiej czy innej formie, bo nawet jeśli mamy Code Review robione przez AI, to koniec końców dobrze mieć jednak dodatkową parę oczu, która po prostu powie, że nie wywalimy produkcji. Nie wiem, czy też tak to widzisz. Widzę to podobnie. Myślę, że dużo rzeczy może być zautomatyzowanych, może być pre-code review, to znaczy, że będzie to robione przez AI, a później jest po prostu kolejny krok. Tak, po prostu jako taki pre-commit, żeby zrobić po prostu zanim wypuszczujesz coś, zanim wypchasz ten swój kod, to tam będzie jakaś dodatkowa weryfikacja, czy jest okej. I potem dopiero będzie jakaś inna osoba.

Taki uber code reviewer, taki po prostu będzie człowiek i on będzie sobie weryfikował. Już mogę na to spojrzeć. AI to zaakceptowało. Ja tylko klikam akcept. Z mojej strony chciałem polecić Syntax, czyli podcast od frontend developerów, którzy rozmawiają o bardzo wielu zagadnieniach z frontendu i z programowania. Goście są ze Stanów, bardzo fajnie gadają, bardzo miło się tego słucha. Podcast jest naprawdę na wysokim poziomie, ale też i właśnie w dość przyjemnej formie. Tak, bardzo lekko i też zapraszają ciekawych ludzi, tak więc jest też spotkanie z ciekawym człowiekiem. Myślę, że tak, fajna polecajka. Dzięki.

Ale zastrzeżenie numeru PESEL jest teraz ogólnodostępne, co prawda jeszcze nie wszędzie respektowane, ale na pewno będzie w tą stronę zmierzało, więc żeby się nie obudzić z jakimś kredytem konsumenckim, o którym się nie miało pojęcia. Podsumowując, Code Review to nie tylko czepianie się, to może być też przyczynek do nauki, może być też bardzo fajną dyskusją. Wszystko kwestia tego, jak podejdziemy do tematu Code Review. Jestem bardzo ciekaw, Jak wy robicie Code Review? I czy spotkaliście się z jakimiś dziwnymi przypadkami w związku z Code Review? A może macie jakieś fajne uwagi? Może o czymś nie wspomnieliśmy? Myślę, że możecie dać znać w komentarzach. No i pamiętajcie, Code Review nie jest opcjonalne. Trzeba to robić. No dobra, no chyba, że jesteś jedynym programistą, no to wtedy trochę bez sensu sobie samemu robić Code Review.