Zrewiewować — co to jest, jak działa code review i sprawdzanie PR

Co to jest code review

Code review — to systematyczne sprawdzanie kodu przez kolegów przed jego integracją. W kontekście Gita oznacza to: programista tworzy pull request ze zmianami, wyznacza recenzentów, a ci analizują diff, zostawiają komentarze i wydają werdykt. Recenzent może zażądać zmian (Request Changes), zatwierdzić PR (Approve) lub zostawić ogólny komentarz.

Code review ma pięć celów: podniesienie jakości kodu (wykrywanie defektów przed trafieniem do produkcji), rozpowszechnianie wiedzy (recenzent poznaje nowe podejścia, autor otrzymuje informację zwrotną), przestrzeganie standardów (sprawdzenie zgodności z code style i rozwiązaniami architektonicznymi), zmniejszenie bus factor (kod nie jest znany tylko jednemu programiście) i budowanie kultury odpowiedzialności (autor pisze staranniej, wiedząc, że kod będzie sprawdzany).

Przeciwieństwem code review jest blind commit: programista wypycha zmiany do wspólnej gałęzi bez review. Takie podejście jest dopuszczalne tylko w projektach jednoosobowych lub w przypadku pilnych hotfixów z późniejszym review post factum. W profesjonalnym programowaniu zespołowym code review jest obowiązkowym etapem dla każdej zmiany, włącznie z poprawkami dokumentacji i konfiguracji.

Co sprawdzać w code review

Code review powinien być systematyczny, a nie chaotyczny. Doświadczeni recenzenci sprawdzają kod w określonej kolejności: najpierw architektura i logika, potem testy, następnie bezpieczeństwo i wydajność, a na końcu — styl i nazewnictwo. Taka kolejność gwarantuje, że krytyczne problemy zostaną zauważone zanim recenzent się zmęczy.

Architektura i logika: czy kod rozwiązuje zadanie, czy nie ma zbędnych abstrakcji, czy przestrzegane są zasady SOLID i DRY. Skomplikowany kod, który trudno zrozumieć przy pierwszym czytaniu — to sygnał, że wymaga refaktoryzacji. Recenzent musi upewnić się, że kod robi dokładnie to, co jest określone w zadaniu i nie ma skutków ubocznych poza zakresem swojej odpowiedzialności.

Testy: czy nowe testy pokrywają wszystkie scenariusze — pozytywne, negatywne, przypadki brzegowe. Czy istniejące testy przechodzą po zmianach. Czy nie ma flaky-testów, które padają niestabilnie. Bezpieczeństwo: brak SQL-iniekcji, XSS, wycieków wrażliwych danych przez logi lub odpowiedzi API. Wydajność: efektywność algorytmów, zbędne zapytania do bazy danych, wycieki zasobów.

• Architektura — poprawność rozwiązania, przestrzeganie SOLID, brak over-engineeringu.
• Logika — obsługa wszystkich scenariuszy, w tym błędów i przypadków brzegowych.
• Testy — pokrycie nowych zmian, brak zepsutych starych testów.
• Bezpieczeństwo — iniekcje, XSS, CSRF, wycieki danych przez logi.
• Wydajność — złożoność algorytmów, zapytania N+1, wycieki pamięci.

Rozmiar review: dlaczego 400 linii to maksimum

Ograniczenie rozmiaru PR — to najważniejsza metryka efektywności code review. Badanie Cisco (2015) i kolejne eksperymenty SmartBear i Google pokazały: przy objętości review powyżej 400 linii gwałtownie spada zdolność recenzenta do wykrywania defektów. Jeśli PR przekracza 400 linii, błędy w nim są wykrywane z prawdopodobieństwem nie wyższym niż przypadkowe.

Optymalny rozmiar: 200-400 linii na jeden PR. Taka objętość może być sprawdzona przez recenzenta w 30-60 minut, przy zachowaniu koncentracji. Google zaleca nie więcej niż 200 linii na jedną rundę review z pełną koncentracją. Jeśli zmian jest więcej — zadanie należy zdekomponować na kilka kolejnych PR, z których każdy wnosi logicznie zakończoną zmianę.

Czas review: w ciągu 24 godzin od momentu utworzenia PR. Jeśli review przeciąga się na kilka dni, kontekst zadania zostaje utracony, a autor musi tracić czas na odtwarzanie kontekstu przy odpowiedzi na komentarze. Zespoły z wysoką kulturą code review ustalają SLA na review: na przykład 4 godziny dla krytycznych zmian i 24 godziny dla zwykłych.

Jak poprawnie pisać komentarze do review

Ton komentarzy — jest kluczowy dla efektywności code review. Komentarz „To jest nieprawidłowe„ wywołuje reakcję obronną i nie daje autorowi użytecznej informacji. Najlepsze sformułowanie to pytanie-sugestia: „Co myślisz o takim podejściu?„, „Tutaj może wystąpić NPE, jeśli user == nil. Może dodać guard?„. Pytania mniej naciskają i stymulują dyskusję.

Struktura dobrego komentarza zawiera trzy części: co jest nie tak, dlaczego to problem i jak to naprawić. Przykład: „W tej pętli używane jest O(n²) z powodu zagnieżdżonego contains, co może spowalniać przy 10k+ rekordów. Spróbuj zastąpić Set dla wyszukiwania O(1)„. Takie sformułowanie jednocześnie wskazuje problem, wyjaśnia jego wagę i proponuje rozwiązanie — autor nie musi domyślać się.

GitHub i GitLab obsługują suggestions — wbudowane propozycje zmian kodu. Recenzent może napisać: „```suggestion Odfiltrować puste linie przed przetwarzaniem```„ — a autor zastosuje zmianę jednym kliknięciem. To przyspiesza drobne poprawki i zmniejsza liczbę rund review. W przypadku dużych poprawek lepiej napisać ogólny komentarz niż wstawiać duże bloki w suggestion.

# Szablon dobrego komentarza code review

# ŹLE: „Ten kod jest nieprawidłowy„
# DOBRZE: „Możemy stracić dane przy pustej odpowiedzi.
#         If response.data == nil, the guard returns nil,
#         and user sees empty screen without error.
#         Maybe add a fallback error message?"

# Składnia sugestii GitHub:
# ```suggestion
# let result = try? parse(response, fallback: .defaultValue)
# ```

Workflow code review w zespole

Efektywny workflow review opiera się na czterech etapach. Pierwszy — autor przygotowuje PR: pisze zrozumiałą nazwę (np. „feat: add password reset screen„), dodaje opis zmian, linki do zadania w trackerze i instrukcje testowania. Drugi — autor wyznacza recenzentów przez auto-assign (na podstawie CODEOWNERS) lub ręcznie.

Trzeci etap — recenzent sprawdza kod i zostawia komentarze. Czwarty — autor wprowadza poprawki, odpowiada na komentarze i prosi o ponowne review. Cykl powtarza się do uzyskania zatwierdzenia. Po zatwierdzeniu autor wykonuje merge (lub merge wykonuje bot). Automatyzacja przez Mergify lub GitHub Auto-merge przyspiesza końcowy etap.

Ważnym elementem workflow jest zarządzanie stale PR. Jeśli PR wisi bez review dłużej niż 3 dni, proces się blokuje. Rozwiązania: rotacja recenzentów (jeśli wyznaczony jest niedostępny), powiadomienia przez Slack/Teams, limit czasu na review (SLA). W niektórych zespołach PR bez review dłużej niż 7 dni jest automatycznie zamykany, a autor tworzy nowy po synchronizacji z main.

• Tworzenie PR — zrozumiała nazwa, opis, linki do zadania, zrzuty ekranu przy zmianach UI.
• Wyznaczenie — auto-assign przez CODEOWNERS lub ręczny wybór 1-2 recenzentów.
• Review — sprawdzanie w kolejności: architektura → logika → testy → bezpieczeństwo → styl.
• Poprawki — autor odpowiada na wszystkie komentarze, naprawia blocking issues, prosi o re-review.
• Merge — po zatwierdzeniu i zielonym CI autor lub bot wykonuje scalenie.

Typowe błędy code review

Pierwszy błąd — powierzchowne review. Recenzent pobieżnie przegląda diff, nie wnikając w logikę, i naciska Approve. Przyczyny: duży PR, deadline, zmęczenie. Konsekwencje: bugi trafiają do produkcji. Rozwiązanie: jeśli nie ma czasu na jakościowe review — uczciwie napisz „Nie mogę sprawdzić dzisiaj, przełóż na jutro„ zamiast formalnego zatwierdzenia.

Drugi błąd — nadmierna krytyka (nitpicking). Recenzent zostawia dziesiątki komentarzy dotyczących stylu formatowania, nazewnictwa zmiennych, trywialnych szczegółów. To demotywuje autora i przeciąga review. Rozwiązanie: StyleGuide i lintery powinny sprawdzać styl automatycznie. Człowiek w review sprawdza logikę, architekturę i bezpieczeństwo.

Trzeci błąd — review bez pytań. Jeśli recenzent stawia tylko Request Changes i Approve, ale nie zadaje pytań, traci możliwość nauczenia się czegoś nowego. Najlepszym wskaźnikiem zdrowia code review jest obecność dyskusji, w których obie strony uczą się czegoś nowego. Jeśli review to monolog jednego z uczestników — proces jest zepsuty.

• Powierzchowne review — Approve bez zagłębienia się. Rozwiązanie: nie recenzować, jeśli nie ma czasu.
• Nitpicking — krytyka stylu, który jest sprawdzany przez linter. Rozwiązanie: zautomatyzować style checks.
• Osobiste odczucie — „ja bym napisał inaczej„. Rozwiązanie: kod ma działać, a nie podobać się recenzentowi.
• Przeciąganie — review dłuższe niż 24 godziny. Rozwiązanie: SLA na review, eskalacja przy naruszeniu.
• Ignorowanie kontekstu — review kodu bez zrozumienia zadania. Rozwiązanie: czytać opis PR przed diff.