Lekcja 20 · Faza 2 · Krok 6 z 6 — zamknięcie głównego cyklu
code-review: przegląd dwuosiowy, równolegle
Ostatni krok z README. Zamyka pętlę zaczętą w Lekcji 15: to-issues opublikował issue jako specyfikację, tdd ją zaimplementował, a code-review sprawdza obie rzeczy naraz — czy kod jest dobrze napisany, i czy robi to, o co prosiła specyfikacja — jako dwie całkowicie osobne osie.
Polecane źródło
Lokalny plik .agents/skills/code-review/SKILL.md w tym repo.
Dwie osie, dwa różne pytania
Oś
Pytanie
Źródło
Standards
Czy kod trzyma się udokumentowanych standardów tego repo?
CODING_STANDARDS.md / CONTRIBUTING.md + stały "smell baseline"
Spec
Czy kod wiernie realizuje issue/PRD, z którego wyszedł?
referencje do issue w commitach, ścieżka podana przez Ciebie, albo plik PRD
Kluczowy wniosek: zmiana może przejść jedną oś i oblać drugą — kod trzymający się każdego standardu, ale robiący złą rzecz (Standards pass, Spec fail), albo kod robiący dokładnie to, o co prosił issue, ale łamiący konwencje repo (Spec pass, Standards fail). Raportowanie ich osobno, bez łączenia w jeden ranking, chroni przed tym, żeby jedna oś maskowała problem z drugiej.
Stały baseline zapachów kodu (Fowler)
Niezależnie od tego, co repo dokumentuje, oś Standards zawsze niesie stały zestaw "code smells" z Refactoring Fowlera — ale z dwiema zasadami:
Repo zawsze wygrywa — udokumentowany standard repo bije baseline, gdy się z nim kłócą.
Baseline to zawsze ocena, nie wyrok — w przeciwieństwie do złamania udokumentowanego standardu, które może być "twardym" naruszeniem.
Zapach
Sygnał
Mysterious Name
nazwa nic nie mówi o tym, co robi/trzyma
Duplicated Code
ten sam kształt logiki w więcej niż jednym miejscu diffa
Feature Envy
metoda sięga do danych innego obiektu bardziej niż do własnych
Speculative Generality
abstrakcja pod potrzebę, której spec nie ma
Shotgun Surgery
jedna logiczna zmiana wymusza rozproszone edycje w wielu plikach
(Pełna lista to 12 zapachów — reszta w źródłowym pliku SKILL.md.)
Proces: dwa subagenty równolegle
Przypnij punkt odniesienia — commit/branch/tag, sprawdzony git rev-parse zanim cokolwiek dalej ruszy.
Znajdź źródło specyfikacji — referencje do issue w commitach, argument od Ciebie, plik PRD, albo brak (oś Spec wtedy raportuje "no spec available").
Znajdź źródła standardów — pliki repo + stały smell baseline.
Odpal oba subagenty naraz, jednym komunikatem z dwoma wywołaniami Agent tool (general-purpose dla obu) — żeby nie zanieczyszczały sobie nawzajem kontekstu.
Zbierz wyniki pod osobnymi nagłówkami ## Standards i ## Spec, bez łączenia w jeden ranking.
Zadanie praktyczne — zamknij cały cykl na prawdziwym kodzie
Na branchu, na którym implementowałeś TDD z Lekcji 17, wpisz /code-review (podaj punkt odniesienia, np. main):
Sprawdź, czy dostałeś dwa osobne raporty, a nie jeden połączony ranking.
Znajdź w raporcie Standards choć jeden zapach z baseline'u — czy rozpoznajesz go jako trafny, czy to fałszywy alarm?
Sprawdź raport Spec: czy trafił na coś z issue, co zostało pominięte albo zaimplementowane inaczej niż prosił opis?
Sprawdź się
1. Kod łamie konwencje nazewnictwa repo, ale robi dokładnie to, o co prosił issue. Jaki będzie wynik przeglądu?
To dokładnie przykład z lekcji: kod robiący to, co prosił issue, ale łamiący konwencje repo — Spec przechodzi, Standards nie. Obie oceny są raportowane osobno.
2. Repo ma udokumentowany standard, który wprost pozwala na coś, co baseline Fowlera nazwałby "Speculative Generality". Co wygrywa?
Zasada "repo overrides": udokumentowany standard repo zawsze wygrywa z baseline'em, gdy się z nim kłócą — smell zostaje wyciszony.
3. Dlaczego oba subagenty (Standards i Spec) uruchamiane są równolegle, w jednym komunikacie?
Każda oś analizuje inne źródła (standardy vs spec) — uruchomienie ich osobno w równoległych subagentach zapobiega mieszaniu się kontekstu jednej analizy z drugą.
4. Dlaczego "Duplicated Code" i inne zapachy z baseline'u są traktowane jako ocena, nie wyrok?
Skill wprost odróżnia: złamanie udokumentowanego standardu repo może być twardym naruszeniem, ale każdy baseline smell jest zawsze etykietowaną heurystyką ("possible Feature Envy"), nigdy pewnikiem.
5. Nie podałeś żadnego argumentu ze ścieżką do specyfikacji, a commity nie referencjonują żadnego issue. Co zrobi oś Spec?
Gdy żadne źródło spec się nie znajdzie, skill pyta użytkownika; jeśli spec faktycznie nie istnieje, subagent Spec pomija ocenę i raportuje "no spec available" — Standards i tak działa normalnie.
Coś niejasne? Zapytaj mnie wprost — to zamyka główny cykl z sześciu kroków. Zaraz zrobię dla Ciebie pełne podsumowanie i diagramy przepływu na żądanie.