Wprowadzenie
Code review to jeden z tych procesów, które wszyscy uważają za świętość. „Dobra praktyka”, „must-have w zespole”, „podstawa jakości”. Ale czy kiedykolwiek zatrzymałeś się, żeby policzyć, ile czasu Twój zespół spędza na recenzowaniu kodu, a ile realnie zyskujesz na jakości?
Pracuję z kilkoma zespołami programistycznymi i widzę pewien wzór: w firmach, które narzekają na tempo developmentu, code review często jest głównym winowajcą. Nie chodzi o to, że recenzje są niepotrzebne – wręcz przeciwnie. Problem leży w tym, jak są przeprowadzane. Oto 3 ciche sygnały, że Twój proces code review zabija produktywność.
1. Recenzje trwają dłużej niż samo pisanie kodu
Jeśli przeciętny PR (pull request) leży w kolejce do review 2-3 dni, a sam review trwa kolejne 2 godziny, to masz problem. W praktyce oznacza to, że deweloper przełącza się między zadaniami, traci kontekst i wraca do poprawiania rzeczy, które już dawno wyparowały z pamięci.
Przykład z życia
W jednej z firm z którymi współpracowałem, zespół 8 osób narzekał na tempo. Po analizie okazało się, że średni czas oczekiwania na review wynosił 2,5 dnia, a sam review to około 1,5 godziny. Tymczasem samo napisanie kodu dla przeciętnego PR zajmowało 3-4 godziny. Prosty rachunek: deweloperzy spędzali 40% czasu na czekaniu i poprawkach, zamiast na tworzeniu nowych funkcji.
Co robić?
Ustal limit czasowy na review – np. maksymalnie 4 godziny od momentu wysłania PR. Jeśli recenzent nie zdąży, PR powinien być automatycznie przypisany do innej osoby. Wprowadź też zasadę, że review nie może trwać dłużej niż 30 minut – jeśli wymaga więcej, to znaczy, że PR jest za duży.
2. Recenzenci koncentrują się na szczegółach, które można zautomatyzować
Widzę to nagminnie: deweloperzy spędzają czas na dyskusji o formatowaniu kodu, nazewnictwie zmiennych czy używaniu pojedynczych cudzysłowów zamiast podwójnych. Tymczasem istnieją narzędzia – lintery, formatter, automatyczne sprawdzanie typów – które robią to lepiej, szybciej i bez emocji.
Przykład z życia
Zespół z jednej agencji webowej spędzał średnio 40% czasu review na komentarzach dotyczących stylu kodu. Po wdrożeniu Prettier i ESLint z surową konfiguracją, czas ten spadł do praktycznie zera. Dodatkowo, każdy PR przed review przechodził przez automatyczne testy i analizę statyczną – recenzenci mogli skupić się wyłącznie na logice i architekturze.
Co robić?
Zainwestuj w narzędzia CI/CD, które wyłapują błędy stylistyczne i potencjalne problemy jeszcze zanim kod trafi do recenzenta. Ustal, że na review trafia tylko logika biznesowa i decyzje architektoniczne – resztę załatwia maszyna.
3. Code review służy wyłapywaniu błędów, które powinny być znalezione w testach
To klasyk: zespół używa code review jako głównej bariery przed błędami produkcyjnymi. Efekt? Recenzenci spędzają czas na szukaniu wyjątków, które nie są obsłużone, dziwnych warunków brzegowych i przypadków, które powinny być pokryte testami jednostkowymi.
Przykład z życia
W startupie z którym pracowałem, code review było jedyną formą kontroli jakości – nie było testów automatycznych. Każdy PR przechodził przez 2-3 recenzentów, którzy wyłapywali błędy, ale i tak co drugi release kończył się hotfixem na produkcji. Po wdrożeniu testów jednostkowych i integracyjnych liczba błędów spadła o 80%, a czas review skrócił się do 15 minut.
Co robić?
Zacznij traktować code review jako uzupełnienie, a nie zastępstwo testów. Wymagaj, żeby każdy PR miał pokrycie testami na poziomie co najmniej 80%. Review powinno sprawdzać, czy testy są poprawne, a nie wyłapywać rzeczy, które testy mogłyby znaleźć.
Podsumowanie
Code review to potężne narzędzie, ale tylko jeśli jest używane z głową. Jeśli Twój zespół spędza na nim więcej czasu niż na pisaniu kodu, targuje się o formatowanie albo szuka błędów, które powinny być wyłapane automatycznie – to znak, że proces wymaga zmiany.
Pamiętaj: celem code review nie jest znalezienie wszystkich błędów, ale dzielenie się wiedzą, poprawa architektury i zapewnienie, że zespół idzie w dobrym kierunku. Resztę zostaw maszynom.
A jakie są Twoje doświadczenia z code review? Daj znać w komentarzu!
