Code review — standard ProfessNet
Review to nie kontrola — to współpraca
Code review w ProfessNet ma dwa cele: złapać błędy przed produkcją i dzielić się wiedzą o kodzie. To rozmowa o kodzie, nie ocena człowieka. Dobry review podnosi jakość i poziom całego zespołu.
Na co patrzy recenzent
Kolejność ma znaczenie — od najważniejszego:
- Poprawność — czy kod robi to, co PR obiecuje? Przypadki brzegowe?
- Bezpieczeństwo — brak sekretów w kodzie, walidacja wejścia, autoryzacja.
- Czytelność — czy zrozumiem to za pół roku?
- Testy — czy zmiana jest pokryta? Czy testy faktycznie sprawdzają logikę?
- Spójność — zgodność z konwencjami i wzorcami repo.
- Wydajność — dopiero gdy realnie istotna; bez przedwczesnej optymalizacji.
Wskazówka: Nie recenzuj formatowania ręcznie. Od tego są Prettier/ESLint i CI. Twój czas jako recenzenta jest cenny — skup go na logice i bezpieczeństwie, nie na spacjach.
Jak pisać komentarze
Komentarz ma być konkretny, życzliwy i wskazywać kierunek, nie tylko problem.
| Zamiast | Napisz |
|---|---|
| "To jest złe" | "Tu przy null poleci wyjątek — dodaj guard?" |
| "Po co to?" | "Możesz wyjaśnić, czemu liczymy to dwa razy?" |
| "Brzydkie" | "Wydzielmy to do funkcji formatTotal dla czytelności" |
Oznaczaj wagę uwagi, by autor wiedział, co jest blokujące:
- blocker — musi być poprawione przed merge.
- nit — drobiazg, opcjonalny ("nit: literówka w komentarzu").
- question — chcę zrozumieć, niekoniecznie zmiana.
Obowiązki autora PR
- Opis PR: co i dlaczego, jak testować, link do preview na Vercelu.
- Mały zakres: jeden cel na PR.
- Self-review: przejrzyj własny diff przed poproszeniem o review.
- Reaguj na komentarze: odpowiadaj, nie ignoruj; zaznacz "resolved" po poprawce.
# Przypisz recenzentów i etykietę przez gh CLI
gh pr create --base main --title "fix: poprawny redirect po logowaniu" \
--reviewer jan-kowalski --label fix
Kiedy approve, kiedy request changes
| Sytuacja | Decyzja |
|---|---|
| Kod poprawny, testy zielone, ewentualne nity | Approve |
| Drobne uwagi, ufam autorowi | Approve z komentarzem |
| Błąd logiczny / luka bezpieczeństwa | Request changes |
| Nie rozumiem zmiany | Comment + pytania |
Standard ProfessNet w skrócie
- Każdy PR wymaga min. jednego approve.
- CI (GitHub Actions) musi być zielone.
- Preview na Vercelu przejrzany dla zmian w UI.
- Recenzent odpowiada w rozsądnym czasie — review nie blokuje zespołu na dni.
- Po merge gałąź jest usuwana.
Podsumowanie
Review to wspólna odpowiedzialność za jakość. Recenzent patrzy najpierw na poprawność i bezpieczeństwo, komentuje życzliwie i konkretnie, oznacza wagę uwag. Autor dostarcza mały, opisany PR i reaguje na uwagi. Formatowanie zostawiamy maszynom.