Wprowadzenie
Code review to jeden z tych procesów, które wszyscy znają, ale niewielu wdraża dobrze. Widzę to regularnie – nawet w firmach, które mają budżet na narzędzia i kadrę inżynierską. Zamiast zdrowej wymiany opinii, code review staje się formalnością: „LGTM” na czacie, mergowanie bez komentarzy, albo przeciwnie – tygodnie oczekiwania na feedback. W obu przypadkach Twój zespół traci czas, a produkt nabywa dług techniczny. W tym artykule pokażę 3 najczęstsze błędy w code review i jak je realnie naprawić.
Błąd 1: Code review jako przegląd po fakcie
Najczęściej spotykam się z przekonaniem, że code review to etap po skończeniu funkcji. „Napiszemy, a potem ktoś to sprawdzi”. Problem w tym, że takie podejście zamienia review w audyt – programista czeka dni, feedback przychodzi hurtem, a poprawki są kosztowne, bo kod już osadzony w kontekście.
Przykład: W jednej z firm, z którą współpracowałem, zespół czekał średnio 3 dni na review. W tym czasie programista zaczynał kolejne zadanie, a potem musiał wracać do poprzedniego. Efekt? Część poprawek nigdy nie była wdrażana, bo kontekst uciekał.
Rozwiązanie:
- Review powinno być ciągłe – małe zmiany, małe recenzje. Zamiast jednego dużego PR, dziel pracę na logiczne kawałki.
- Ustal limit czasu na odpowiedź – np. 4 godziny w godzinach pracy. To zmienia kulturę z „jak znajdę czas” na „sprawdźę teraz”.
- Korzystaj z pair programmingu przy krytycznych fragmentach – to prewencja, a nie kontrola.
Błąd 2: Brak kryteriów oceny – „to działa, to mergujemy”
Drugi częsty grzech to brak standardów. Każdy recenzuje według własnego uznania – jedni zwracają uwagę tylko na styl, inni na wydajność, a jeszcze inni nie zwracają uwagi na nic. Skutek? Jakość kodu jest nierówna, a nowi programiści nie wiedzą, czego się trzymać.
Przykład: W startupie, który audytowałem, code review ograniczało się do sprawdzenia, czy kod się kompiluje i czy testy przechodzą. Nikt nie patrzył na architekturę ani na to, czy kod jest nadmiarowy. Po pół roku mieli taki bałagan, że każda zmiana wymagała refaktora.
Rozwiązanie:
- Stwórz checklistę review: czytelność, testy, bezpieczeństwo, zgodność z architekturą, wydajność.
- Ustal wagę błędów – np. blokujące (bezpieczeństwo), krytyczne (logika), kosmetyczne (formatowanie).
- Używaj automatycznych linterów i formatterów – niech maszyna robi to, co może. Dzięki temu recenzent skupia się na tym, co ważne.
Błąd 3: Ocenianie ludzi, a nie kodu
Code review to najbardziej polityczna aktywność w zespole. Niby mówimy „to tylko kod”, ale emocje są realne. Jeśli recenzent używa sformułowań „to jest źle”, „nie rozumiem, dlaczego tak zrobiłeś”, autor zaczyna się bronić, a nie słuchać. Powstaje napięcie, które hamuje rozwój.
Przykład: W jednej firmie senior developer regularnie komentował PR młodszych z ironią. Po trzech miesiącach dwóch programistów odeszło, a reszta bała się wysyłać PR-y bez konsultacji. Code review stało się buteleczką wąskiego gardła.
Rozwiązanie:
- Ucz recenzentów języka: zamiast „to jest źle” – „widzę ryzyko w tej części, czy rozważałeś inną implementację?”
- Oddzielaj fakty od opinii. Jeśli coś jest błędem – wytłumacz, dlaczego. Jeśli to kwestia gustu – zostaw autorowi decyzję.
- Wprowadź rotację recenzentów – wtedy nikt nie czuje się atakowany personalnie, a zespół buduje wspólną odpowiedzialność.
Podsumowanie
Code review to nie formalność – to narzędzie do podnoszenia jakości, dzielenia się wiedzą i budowania kultury inżynierskiej. Jeśli Twój zespół skacze na głęboką wodę bez procesu albo traktuje review jako przeszkodę, zmień podejście. Małe PR-y, jasne kryteria i szacunek dla autora – to trzy filary, które realnie oszczędzają czas i pieniądze. U mnie w JurskiTech.pl wdrożyliśmy te zasady i widzimy efekty: szybciej wypuszczamy funkcje, mniej bugów, lepsza atmosfera. Spróbuj, a zobaczysz różnicę.
