---
name: code-review-protocol
title: Protokół Code Review
description: "Ustrukturyzowana metodologia code review, która wykracza poza „wygląda ok.\" Tworzy listę ustaleń rankingowaną według ważności, obejmującą poprawność, bezpieczeństwo, wydajność, utrzymywalność i design. Każde ustalenie zawiera problem, dlaczego ma znaczenie i konkretną sugestię naprawy. Łapie to, co lintery omijają — błędy logiczne, dryft architektoniczny, ukryte sprzężenia i pominięte przypadki brzegowe."
category: review
tags:
  - code-review
  - jakość
  - najlepsze-praktyki
  - pull-request
  - development
requires:
  - Claude
source: https://madejski.ai/pl/skilloteka/code-review-protocol
locale: pl
license: MIT
---

# Protokół Code Review

## Co robi ten skill

Przeprowadza ustrukturyzowane, zdecydowane code review, które łapie to, czego zautomatyzowane narzędzia nie widzą. Wynikiem jest lista ustaleń rankingowana według ważności — każde z opisem problemu, wpływem i konkretną naprawą.

To nie jest przejście lintera. Łapie:
- Błędy logiczne i pominięte przypadki brzegowe
- Luki bezpieczeństwa (injection, obejście auth, wyciek danych)
- Pułapki wydajnościowe (zapytania N+1, niepotrzebne re-rendery, wycieki pamięci)
- Dryft architektoniczny (wzorce niespójne z codebase)
- Ukryte sprzężenia i naruszenia abstrakcji
- Luki w obsłudze błędów (połknięte błędy, brakująca walidacja)
- Warunki wyścigu i problemy współbieżności

## Poziomy ważności

| Poziom | Znaczenie | Wymagane działanie |
|--------|-----------|--------------------|
| **KRYTYCZNY** | Luka bezpieczeństwa, ryzyko utraty danych lub crash | Musi być naprawiony przed merge |
| **WYSOKI** | Bug, regresja wydajności lub naruszenie designu | Powinien być naprawiony przed merge |
| **ŚREDNI** | Problem utrzymywalności, pominięty edge case lub code smell | Napraw teraz lub stwórz ticket |
| **NISKI** | Styl, nazewnictwo, drobna poprawa | Fajnie by było |
| **NOTATKA** | Obserwacja, pytanie lub sugestia do dyskusji | Brak wymaganego działania |

## Checklist review

### 1. Poprawność
- Czy kod robi to, co deklaruje?
- Czy wszystkie przypadki brzegowe są obsłużone? (null, puste, wartości graniczne, stany błędu)
- Czy są błędy off-by-one?
- Czy logika biznesowa jest poprawna?

### 2. Bezpieczeństwo
- Czy dane wejściowe są walidowane i sanityzowane?
- Czy są wektory SQL/NoSQL injection?
- Czy autentykacja/autoryzacja jest sprawdzona?
- Czy sekrety są zahardkodowane?
- Czy wrażliwe dane są eksponowane w logach, błędach lub odpowiedziach?

### 3. Wydajność
- Czy są wzorce zapytań N+1?
- Niepotrzebne obliczenia w pętlach lub renderach?
- Brakująca paginacja dla nieograniczonych zapytań?
- Wycieki pamięci (niezamknięte połączenia, rosnące kolekcje)?
- Brakujące cache'owanie tam, gdzie by pomogło?

### 4. Obsługa błędów
- Czy błędy są łapane i obsługiwane odpowiednio?
- Czy komunikaty błędów ujawniają szczegóły implementacji?
- Czy jest fallback/retry dla przejściowych awarii?
- Czy błędy async są prawidłowo propagowane?

### 5. Design i architektura
- Czy zmiana podąża za istniejącymi wzorcami w codebase?
- Czy jest niepotrzebne sprzężenie między modułami?
- Czy odpowiedzialności są wyraźnie rozdzielone?
- Czy to mogłoby być prostsze?

### 6. Testowanie
- Czy są testy dla nowego/zmienionego kodu?
- Czy testy pokrywają happy path I edge case'y?
- Czy mocki są realistyczne?
- Czy niepowodzenie testu wskazałoby na rzeczywisty problem?

### 7. Czytelność
- Czy nazwy są opisowe i spójne?
- Czy kod jest samodokumentujący, czy potrzebuje komentarzy?
- Czy funkcje są wystarczająco małe, żeby zrozumieć na pierwszy rzut oka?
- Czy jest martwy kod lub zakomentowany kod?

## Format wyjścia

```markdown
## Code Review: {opis}

### Podsumowanie
{1-2 zdania — przegląd zmiany i ogólna ocena}

### Ustalenia

#### KRYTYCZNY: {tytuł}
**Plik:** `ścieżka/do/pliku.ts:42`
**Problem:** {co jest nie tak}
**Wpływ:** {dlaczego to ma znaczenie}
**Naprawa:** {konkretna sugestia z kodem}

#### WYSOKI: {tytuł}
...
```

## Proces

1. **Zrozum intencję** — przeczytaj opis PR, powiązane issue lub zapytaj, co zmiana robi
2. **Czytaj diff holistycznie** — zrozum całą zmianę przed komentowaniem szczegółów
3. **Zastosuj checklistę** — systematyczne przejście przez każdą kategorię
4. **Rankinguj ustalenia** — ważność determinuje wymagane działanie
5. **Sugeruj naprawy** — każde ustalenie zawiera konkretną naprawę, nie tylko „to jest źle"
6. **Doceń dobrą robotę** — wskaż też dobrze napisany kod

## Antywzorce

- Czepianie się stylu, gdy są prawdziwe bugi do złapania
- „Wygląda ok" bez faktycznego czytania kodu
- Przepisywanie kodu autora w swoim preferowanym stylu
- Blokowanie na ustaleniach NISKI
- Recenzowanie tylko diffa bez zrozumienia kontekstu