Przepływy przeglądów

Twój zespół ma regułę: każdy PR potrzebuje co najmniej jednego przeglądu przed mergowaniem. W praktyce przeglądy się piętrzą. Senior developer, który recenzuje większość PR-ów, jest na spotkaniach do 15:00, więc PR-y czekają godzinami. Gdy w końcu przeglądają, śpieszą się przez zaległości 6 PR-ów. Wychwytują oczywiste problemy formatowania, ale pomijają subtelny błąd, gdzie sprawdzanie null jest w złej kolejności. Ten błąd trafia na produkcję w piątek po południu.

Wąskie gardło to nie reguła — to przepływ pracy. Przeglądy wspomagane przez AI nie zastępują ludzkich recenzentów. Wzmacniają ich. AI wychwytuje mechaniczne problemy (brakująca obsługa błędów, niespójne wzorce, potencjalne referencje null), więc ludzki recenzent może skupić się na rzeczach, których AI nie może ocenić: decyzje architektoniczne, poprawność logiki biznesowej i czy podejście jest właściwe.

Co wyniesiesz

Przepływ pracy samo-przeglądu wychwytujący problemy przed przesłaniem PR
Prompty do skopiowania-wklejenia dla przeglądania własnego kodu i kodu innych
Techniki używania trybu Ask jako asystenta przeglądu
Strategie pisania PR gotowych do przeglądu, które szybciej są zatwierdzane

Samo-przegląd przed przesłaniem

Przepływ pracy przeglądu o najwyższej dźwigni to przeglądanie własnego kodu zanim ktokolwiek inny go zobaczy. Wychwytuje to 80% komentarzy przeglądu zanim się pojawią.

Prompt do skopiowania-wklejenia dla samo-przeglądu:

Przejrzyj wszystkie zmiany na bieżącej gałęzi w porównaniu z main.

Sprawdź pod kątem:
1. Bezpieczeństwa: SQL injection, XSS, brakująca autentykacja, zahardkodowane sekrety
2. Obsługi błędów: nieprzechycone promise'y, brakujący try/catch, połknięte błędy
3. Wydajności: zapytania N+1, niepotrzebne pobieranie danych, operacje blokujące
4. Spójności: czy nowy kod przestrzega wzorców w @src/services/user-service.ts?
5. Przypadków brzegowych: wejścia null/undefined, puste tablice, współbieżny dostęp
6. Brakujących testów: czy wszystkie nowe ścieżki kodu są pokryte?

Dla każdego znalezionego problemu podaj plik, linię, problem i konkretną poprawkę.
Nie wprowadzaj jeszcze żadnych zmian -- tylko zgłoś ustalenia.

Uruchom ten prompt w trybie Ask przed utworzeniem PR. Napraw to, co znajdzie, a następnie prześlij. Twoi recenzenci spędzą czas na architekturze i logice biznesowej zamiast wskazywać, że zapomniałeś obsłużyć przypadek pustej tablicy.

Przeglądanie kodu innych osób

Szybkie zrozumienie

Gdy otwierasz PR z 15 zmienionymi plikami i 400 liniami diffu, pierwszym wyzwaniem jest zrozumienie, co się dzieje:

Prompt do skopiowania-wklejenia dla zrozumienia PR:

Przeglądam PR, który modyfikuje te pliki:

[WKLEJ LISTĘ PLIKÓW LUB PODSUMOWANIE DIFF]

Pomóż mi zrozumieć:
1. Jaki jest ogólny cel tej zmiany?
2. Jaka jest sekwencja zmian -- który plik jest punktem wejścia?
3. Które zmiany są strukturalne (przeniesienia, zmiany nazw) vs. behawioralne (nowa logika)?
4. Jakie są najbardziej ryzykowne części wymagające uważnego przeglądu?

Nie oceniaj jeszcze kodu. Po prostu pomóż mi zbudować mentalny model zmiany.

Oszczędza to 10 minut przewijania przez diff próbując zrozumieć, co PR faktycznie robi.

Przeglądanie pod kątem konkretnych obaw

Po zrozumieniu PR skup swój przegląd na konkretnych obawach zamiast próbować wychwycić wszystko w jednym podejściu:

Prompt do skopiowania-wklejenia dla skupionego przeglądu:

Przejrzyj @src/services/payment-service.ts pod kątem kompletności obsługi błędów.

Dla każdego zewnętrznego wywołania (zapytania bazy danych, wywołania API, operacje na plikach):
1. Czy jest try/catch lub .catch()?
2. Czy błąd jest logowany z wystarczającym kontekstem do debugowania?
3. Czy błąd jest propagowany lub obsługiwany odpowiednio?
4. Czy są mechanizmy timeout lub retry dla usług zewnętrznych?
5. Co się stanie, jeśli usługa jest całkowicie niedostępna?

Wylistuj wszelkie luki, które znajdziesz z konkretnymi referencjami do linii.

Przeprowadź oddzielne skupione przeglądy dla bezpieczeństwa, wydajności i obsługi błędów zamiast jednego niejasnego promptu “review this code”. Trzy skupione podejścia wychwytują więcej problemów niż jedno nieskupione.

Generowanie opisów PR

Dobre opisy PR przyspieszają przeglądy. Pozwól Cursorowi wygenerować je z twoich rzeczywistych zmian:

Prompt do skopiowania-wklejenia dla opisu PR:

Wygeneruj opis PR na podstawie diffu między tą gałęzią a main.

Struktura:
## What
Jedno zdanie wyjaśniające, co robi ten PR.

## Why
Problem, który rozwiązuje lub wymaganie funkcji, które spełnia.

## How
Krótkie wyjaśnienie przyjętego podejścia, włączając wszelkie godne uwagi decyzje projektowe.

## What to review
2-3 obszary, gdzie uwaga recenzenta jest najbardziej wartościowa.

## Testing
Jakie testy zostały dodane lub zmodyfikowane i jak ręcznie zweryfikować zmiany.

Trzymaj to zwięźle. Nie wymieniaj każdego zmienionego pliku -- skup się na tym, co recenzent musi wiedzieć.

Dobry opis PR odpowiada na pierwsze trzy pytania recenzenta zanim jeszcze spojrzą na kod: co się zmieniło, dlaczego się zmieniło i na co zwrócić uwagę.

Przepływ pracy przeglądu dwuprzejściowego

Dla dokładnych przeglądów użyj strukturalnego podejścia dwuprzejściowego:

Przejście 1: Skanowanie wspomagane przez AI. Użyj trybu Ask do przeanalizowania diffu pod kątem mechanicznych problemów (brakująca obsługa błędów, niespójne wzorce, potencjalne błędy). Napraw lub zanotuj wszystko, co znajdzie AI.
Przejście 2: Przegląd ludzki. Z już obsłużonymi problemami mechanicznymi skup się na rzeczach, których AI nie może ocenić — czy to właściwe podejście? Czy architektura ma sens? Czy będzie to łatwe w utrzymaniu za sześć miesięcy?

AI obsługuje checklistę. Ty obsługujesz ocenę.

Reguły przeglądu dla spójności

Stwórz regułę, która standaryzuje sposób, w jaki AI recenzuje kod w twoim zespole:

---
description: Standards for AI-assisted code review
alwaysApply: false
---

When reviewing code changes:

1. Check against our coding standards:
   - All public functions must have JSDoc comments
   - All API endpoints must validate inputs with Zod
   - All database queries must use parameterized queries
   - Error responses must follow the format in @src/lib/errors.ts

2. Check for common mistakes:
   - Promises without await or .catch()
   - Array methods on potentially undefined values
   - Missing null checks before property access
   - Hardcoded strings that should be constants or env vars

3. Do not flag:
   - Style preferences (formatting is handled by Prettier)
   - Import ordering (handled by ESLint)
   - Variable naming unless it is genuinely confusing

Przechowuj to w .cursor/rules/review-standards.mdc. Gdy ktokolwiek w zespole uruchamia prompt przeglądu, agent stosuje te same standardy.

Odpowiadanie na komentarze przeglądu

Gdy otrzymujesz feedback przeglądu, Cursor może pomóc ci efektywnie się nim zająć:

Prompt do skopiowania-wklejenia dla zajęcia się komentarzami przeglądu:

Otrzymałem ten komentarz przeglądu do mojego PR:

"[WKLEJ KOMENTARZ PRZEGLĄDU]"

Odpowiedni kod jest w @src/[file-path].

Pomóż mi:
1. Zrozumieć, o co prosi recenzent
2. Określić, czy sugestia jest poprawna, czy jest powód, dla którego kod jest napisany w ten sposób
3. Jeśli sugestia jest poprawna, wprowadź zmianę
4. Jeśli się nie zgadzam, przygotuj odpowiedź wyjaśniającą moje rozumowanie

Nie wprowadzaj zmian, chyba że potwierdzę, że sugestia jest poprawna.

Jest to szczególnie przydatne dla juniorów, którzy otrzymują feedback przeglądu, którego nie do końca rozumieją. AI wyjaśnia rozumowanie recenzenta i pomaga zdecydować, czy zaakceptować, czy pushować z powrotem.

Niestandardowe komendy przeglądu

Dla przeglądów, które uruchamiasz wielokrotnie, zapisz je jako niestandardowe komendy:

---
description: Run a security-focused review on the current changes
---

Review all changes on the current branch compared to main for security issues.

Check for:
- User input that reaches database queries without parameterization
- Missing authentication or authorization checks
- Secrets or credentials in code or configuration
- User input rendered in HTML without sanitization
- File paths constructed from user input
- Deserialization of untrusted data

For each finding, rate it as Critical, High, Medium, or Low severity.
Provide the file, line, the vulnerability, and a specific fix.

Zapisz jako .cursor/commands/security-review.md i wywołaj za pomocą /security-review przed każdym PR.

Przeglądanie kodu generowanego przez AI

Kod generowany przez AI potrzebuje dodatkowej weryfikacji, ponieważ często wygląda poprawnie, ale ma subtelne problemy:

Użyłem trybu Agent do wygenerowania kodu w @src/services/notification-service.ts.

Przejrzyj go z dodatkową uwagą pod kątem:
1. Kodu wyglądającego prawdopodobnie, który faktycznie nic nie robi (np. handlery błędów połykające błędy)
2. Zahardkodowanych wartości, które powinny być konfigurowalne
3. Wzorców mock-like, które przypadkowo trafiły do kodu produkcyjnego
4. Funkcji wyglądających na kompletne, ale pomijających przypadki brzegowe
5. Zależności, które są importowane, ale nie istnieją w package.json

Ten kod był generowany przez AI, więc nie zakładaj, że cokolwiek jest poprawne. Zweryfikuj wszystko.

Kod generowany przez AI ma specyficzny wzorzec awarii: wygląda bardziej poprawnie niż jest. Funkcja może mieć blok try/catch, który łapie błędy, ale nic z nimi nie robi. Funkcja walidacji może sprawdzać trzy z czterech wymaganych pól. Łatwo to przeoczyć w przeglądzie, ponieważ struktura kodu wygląda dobrze, nawet jeśli zachowanie jest złe.

Gdy to się psuje

Przegląd AI pomija błędy logiki biznesowej. Przeglądy AI wychwytują problemy strukturalne (brakująca obsługa błędów, niespójne wzorce), ale nie mogą zweryfikować, czy logika biznesowa jest poprawna. Funkcja, która źle oblicza podatek, przejdzie każdy przegląd AI, jeśli struktura kodu jest czysta. Walidacja logiki biznesowej jest zawsze odpowiedzialnością człowieka.

Przeglądy stają się pieczątką. Jeśli zawsze akceptujesz wynik przeglądu AI bez czytania, przegapiasz problemy specyficzne dla kontekstu. Użyj ustaleń AI jako punktu wyjścia dla własnego przeglądu, nie jako jego zamiennika.

Zbyt wiele fałszywych pozytywów. AI flaguje rzeczy, które są zamierzone. Dodaj regułę przeglądu (jak pokazano powyżej) określającą, czego NIE flagować. Trenuje to AI do dopasowania do standardów twojego zespołu.

Opisy PR są ogólne. Opis wygenerowany przez AI mówi “updated the service” zamiast wyjaśniać dlaczego. Dodaj sekcję “Why” wyraźnie w swoim promptcie i wypełnij kontekst biznesowy, którego AI nie może wywnioskować.

Co dalej

Wzorce testowania — Zapewnienie jakości kodu przed dotarciem do przeglądu
Przepływy debugowania — Badanie problemów znalezionych podczas przeglądu
Współpraca zespołowa — Skalowanie praktyk przeglądowych w zespole