Co to jest code review (CR)? Jak je robić i kiedy użyć AI

Każdy programista prędzej czy później wysyła swój kod do oceny kogoś innego, albo ocenia cudzy. W firmach to codzienność, na kursach i w mentoringu to jedno z najszybszych źródeł nauki. Poniżej wyjaśniam, czym jest code review, jak je zrobić, na co zwracać uwagę oraz kiedy warto użyć AI, a kiedy lepiej poprosić człowieka.

Co to jest code review (CR)?

Code review, po polsku przegląd kodu, często skracane do CR, to proces, w którym ktoś inny niż autor czyta zmiany w kodzie i ocenia je, zanim zostaną włączone do głównej gałęzi projektu. W praktyce najczęściej wygląda to tak, że autor otwiera pull request (PR) na GitHubie lub GitLabie, a recenzent zostawia komentarze do poszczególnych linijek i decyduje, czy zmiana jest gotowa, czy wymaga poprawek.

Skrót CR bywa mylony z innymi znaczeniami, ale w IT prawie zawsze chodzi o przegląd kodu.

Po co robi się code review?

Dla osoby, która się uczy programowania, to ostatni punkt jest najważniejszy. Sama praktyka nie wystarczy, jeśli nikt nie powie Ci, co w Twoim rozwiązaniu można zrobić lepiej. O tym, jak się uczyć, piszemy też w artykule efektywna nauka programowania.

Jak zrobić code review krok po kroku?

1. Zrozum cel zmiany. Przeczytaj opis PR i zadanie, zanim spojrzysz na kod. Bez kontekstu ocenisz tylko styl.
2. Zacznij od całości. Zobacz, jakie pliki się zmieniły i czy rozmiar zmiany ma sens. Bardzo duże PR-y trudno przejrzeć dobrze, więc warto prosić o podział.
3. Przeczytaj kod linijka po linijce. Zwracaj uwagę na logikę, nazwy, obsługę błędów i przypadki brzegowe.
4. Uruchom lub przetestuj zmianę, jeśli to możliwe. Samo czytanie nie wychwyci wszystkiego.
5. Napisz komentarze i na końcu podsumuj swoją decyzję: zatwierdzam, proszę o poprawki albo mam pytania.
6. Wróć do PR po poprawkach, żeby sprawdzić, czy uwagi zostały uwzględnione.

Na co zwracać uwagę podczas code review?

Nie każdy PR wymaga sprawdzenia wszystkiego z tej listy z jednakową uwagą. Ważne jest, by zacząć od tego, co naprawdę może zaszkodzić (poprawność, bezpieczeństwo), a dopiero potem poprawiać styl.

Jak pisać dobre komentarze w code review?

Komentarz ma pomóc autorowi, nie go ocenić. Dobrze działają trzy zasady:

• Pisz o kodzie, nie o człowieku. Zamiast „źle to zrobiłeś” napisz „ta funkcja robi dwie rzeczy, rozważ podział”.
• Wyjaśniaj dlaczego. Sama uwaga „zmień to” niczego nie uczy. Uzasadnienie tak.
• Oddzielaj rzeczy ważne od kosmetycznych. Oznacz drobne uwagi słowem „drobiazg” lub „sugestia”, żeby autor wiedział, co jest obowiązkowe.

Przykład słabego i dobrego komentarza do tego samego kodu:

function p(a) {
  return a.filter((x) => x.active).length;
}

• ❌ „Nazwy są złe.”
• ✅ „Nazwa p nie mówi, co funkcja liczy. Czy countActiveUsers nie byłoby czytelniejsze? Dzięki temu nie trzeba zaglądać do środka, żeby zrozumieć wywołanie.”

Jak przygotować swój kod do code review?

Autor też ma wpływ na jakość review. Zanim poprosisz o ocenę:

• Przeczytaj własny kod jeszcze raz, tak jakbyś widział go po raz pierwszy.
• Dodaj opis: co zmieniasz, dlaczego i jak to sprawdzić.
• Zadbaj, żeby zmiana była mała i dotyczyła jednej rzeczy.
• Uruchom testy i linter, żeby recenzent nie tracił czasu na to, co narzędzia wychwycą same.

Czy do code review warto używać AI?

Tak, jako pomocnika, ale nie jako jedynego recenzenta. Narzędzia AI, takie jak asystenci wbudowani w edytor lub boty do pull requestów, potrafią szybko wskazać oczywiste błędy, niespójności i brakujące przypadki.

W jednym z naszych testów ChatGPT nie potrafił nawet poprawnie wykonać prośby o komentarze w kodzie (zobacz artykuł o nauce programowania z ChatGPT). Narzędzia szybko się zmieniają, ale zasada pozostaje: wynik AI trzeba sprawdzić, a nie przyjmować na wiarę.

Jak używać AI w code review, żeby naprawdę pomagało?

1. Podaj kontekst. Napisz, co kod ma robić, w jakiej technologii i na jakim poziomie jesteś.
2. Poproś o konkretne rzeczy, a nie o „ocenę kodu”.
3. Weryfikuj odpowiedzi. Jeśli AI proponuje zmianę, upewnij się, że rozumiesz, dlaczego jest lepsza.
4. Nie wklejaj tajnych danych. Kod firmowy, hasła i klucze nie powinny trafiać do zewnętrznych narzędzi bez zgody pracodawcy.

Przykładowy prompt:

Jestem początkującym programistą JavaScript. Poniżej jest moja funkcja,
która ma [opis działania]. Sprawdź ją pod kątem: 1) błędów logicznych,
2) przypadków brzegowych, 3) czytelności nazw. Nie przepisuj całości,
tylko wskaż, co poprawić i wyjaśnij dlaczego.

Kiedy code review lepiej zostawić człowiekowi?

Są sytuacje, w których AI nie zastąpi człowieka, bo ocena kodu zależy od tego, kto go napisał i po co.

• Przy nauce. Mentor wie, co już umiesz, a czego jeszcze nie. Potrafi zostawić prostsze rozwiązanie, bo na Twoim etapie ważniejsze jest zrozumienie niż elegancja. AI często podpowie zaawansowany wzorzec, którego nie zrozumiesz i którego nie umiesz jeszcze obronić.
• Gdy chodzi o decyzje projektowe. Wybór architektury, nazewnictwa i kompromisów wynika z kontekstu zespołu i produktu, którego AI nie widzi.
• Gdy potrzebna jest odpowiedzialność. Człowiek, który zatwierdza zmianę, bierze za nią odpowiedzialność. Narzędzie nie.
• Gdy ważna jest relacja. Dobre review w zespole buduje zaufanie i wspólne standardy, a tego nie da się zautomatyzować.

Uczenie się z wyłącznie automatycznego feedbacku niesie jeszcze jedno ryzyko: łatwo przestać myśleć samodzielnie i tylko stosować to, co podpowiada narzędzie.

Dlaczego w nauce code review nie może przytłaczać?

Przy nauce ważna jest nie tylko treść uwag, ale też ich ilość. Kod początkującego prawie zawsze da się poprawić w kilkudziesięciu miejscach, ale nie warto wskazywać wszystkiego naraz. Lista kilkudziesięciu komentarzy potrafi zniechęcić młodego adepta IT i sprawić, że zamiast z czegoś się nauczyć, uzna, że „nic mu nie wychodzi”.

Dobry mentor wybiera więc to, co jest najważniejsze na tym etapie, a resztę zostawia na później. Szczególnie ostrożnie warto z tym postępować, gdy w krótkim czasie pojawia się kilka kolejnych review pod rząd, bo wtedy uwagi zaczynają się kumulować. Człowiek, który zna poziom ucznia i jego ostatnie review, potrafi dobrać dawkę feedbacku. AI tego nie zrobi: poda pełną listę wszystkich uwag, bo nie wie, że to już trzecie review w tym tygodniu.

Jak połączyć AI i code review wykonywane przez człowieka?

Najlepiej działa podział ról:

1. Autor sam sprawdza swój kod i poprawia oczywiste rzeczy.
2. AI robi wstępny przegląd, który wyłapuje drobiazgi i pozwala poprawić je przed ludzką oceną.
3. Człowiek ocenia to, co zostało: logikę, decyzje projektowe i zgodność z celem zadania.

Dzięki temu recenzent nie traci czasu na literówki, a uwagi dotyczą rzeczy, które naprawdę wymagają doświadczenia.

Jak wygląda code review w mentoringu devmentor?

W devmentor każde zadanie i projekt w programie jest sprawdzane przez mentora, który zostawia informację zwrotną, czyli właśnie robi code review. Feedback zwykle przychodzi następnego dnia, kiedy jeszcze pamiętasz temat i możesz od razu nanieść poprawki. Więcej o tym, jak code review wpisuje się w pracę z mentorem, przeczytasz w artykule co to jest mentoring i kim jest mentor.

Jeśli chcesz uczyć się z regularnym feedbackiem od mentora, który zna Twój poziom, zobacz wszystkie dostępne ścieżki mentoringu albo umów bezpłatną rozmowę.