Mentionsy

W dzisiejszym odcinku porozmawiamy o tym, dlaczego trzeba robić Code Review.

Powiemy też o 7 dobrych praktykach robienia Code Review.

Po co w ogóle robić Code Review i na co to komu?

Jest bardzo wiele powodów, żeby robić Code Review.

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.

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.

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.

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.

Jedna rzecz to jest to, że czasami w Code Review lubię zadawać pytania.

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.

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.

A to koniec końców prowadzi do mniejszego Code Review, bo po prostu

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.

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.

Zaplanuj czas na Code Review.

Istotne jest to, żeby te Code Review robić.

No i teraz wyobraźmy sobie, że mamy dobry flow i czekamy na Code Review.

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.

Ale ja zgadzam się jak najbardziej z tym, żeby mieć po prostu jakiś taki punkt, punkt dnia, gdzie robimy Code Review.

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.

No więc zachęcamy do tego, żeby robić to Code Review no w miarę regularnie.

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?

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

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ć.

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.

Jak widzisz przyszłość, jeżeli chodzi o Code Review?

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...

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.

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.

Taki uber code reviewer, taki po prostu będzie człowiek i on będzie sobie weryfikował.

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.

Jak wy robicie Code Review?

I czy spotkaliście się z jakimiś dziwnymi przypadkami w związku z Code Review?

No i pamiętajcie, Code Review nie jest opcjonalne.

No dobra, no chyba, że jesteś jedynym programistą, no to wtedy trochę bez sensu sobie samemu robić Code Review.