Pętla Iteracyjnego Doskonalenia

Główna idea

Nie oczekuj perfekcji od pierwszego podejścia. Planuj iteracje od początku. Każde przejście ma inny fokus:

Przejście 1: Struktura — Ustaw kształt. Poprawne, kompletne, działające. Przejście 2: Jakość — Utwardź. Edge case'y, obsługa błędów, testy. Przejście 3: Szlif — Zrób to świetnym. Wydajność, czytelność, dokumentacja.

Dlaczego to działa

Pierwszy output z AI (lub od ludzi) ma przewidywalne słabości:

• Happy path działa, edge case'y nie
• Struktura jest dobra, szczegóły złe
• Działa, ale nie jest utrzymywalne
• Rozwiązanie jest poprawne, ale nieeleganckie

Planowanie iteracji pozwala pierwszemu przejściu być szybkim i kreatywnym bez presji na perfekcję. Kolejne przejścia są skupione i chirurgiczne.

Pętla

┌─→ Buduj (szybko, kreatywnie, niech działa)
│     ↓
│   Krytykuj (co jest źle? czego brakuje? co jest kruche?)
│     ↓
│   Dopracuj (napraw ustalenia krytyki, popraw)
│     ↓
│   Wystarczająco dobre? ──Nie──┘
│     │
│    Tak
│     ↓
│   Shipuj

Przejście 1: Struktura i poprawność

Cel: Niech działa. Wszystkie wymagania spełnione. Bez crashy.

Pytania krytyki:

• Czy spełnia wszystkie wymagania ze specyfikacji?
• Czy happy path działa end-to-end?
• Czy ogólna architektura jest solidna?
• Czy są problemy strukturalne, które będzie drogo naprawić później?

Akcja: Napraw tylko problemy strukturalne. Nie szlifuj.

Przejście 2: Jakość i solidność

Cel: Niech będzie solidne. Obsługuj edge case'y. Dodaj testy.

Pytania krytyki:

• Co się dzieje z nullem/pustym/brakującym inputem?
• Co się dzieje z bardzo dużym inputem?
• Co się dzieje gdy zewnętrzne serwisy zawodzą?
• Czy błędy są obsługiwane gracefully?
• Czy jest pokrycie testami dla krytycznych ścieżek?
• Czy są podatności bezpieczeństwa?

Akcja: Dodaj obsługę błędów, edge case'y, walidację, testy.

Przejście 3: Szlif i wydajność

Cel: Niech będzie świetne. Optymalizuj. Posprzątaj.

Pytania krytyki:

• Czy kod jest czytelny dla kogoś widzącego go po raz pierwszy?
• Czy są wąskie gardła wydajności?
• Czy jest martwy kod lub niepotrzebna złożoność?
• Czy nazwy są opisowe?
• Czy dokumentacja jest aktualna?
• Czy byłbyś dumny pokazując to seniorowi?

Akcja: Optymalizuj, refaktoryzuj, dokumentuj, posprzątaj.

Kiedy przestać

Przestań iterować gdy:

• Wszystkie kryteria akceptacji przechodzą
• Nie ma ustaleń KRYTYCZNYCH ani WYSOKICH
• Następne przejście przyniosłoby malejące zyski
• Time box się skończył

Nie przestawaj bo:

• „Działa" (działanie to Przejście 1, nie koniec)
• Masz dość patrzenia na to (wtedy właśnie bugi się chowają)
• Deadline jest jutro (obcinaj zakres, nie jakość)

Zastosowanie w różnych domenach

Kod

• Przejście 1: Działająca implementacja, główny test przechodzi
• Przejście 2: Testy edge case'ów, obsługa błędów, review bezpieczeństwa
• Przejście 3: Optymalizacja wydajności, czyszczenie kodu, dokumentacja

Pisanie

• Przejście 1: Struktura i treść kompletna, wszystkie punkty pokryte
• Przejście 2: Sprawdzenie faktów, logiczny przepływ, kalibracja pod odbiorcę
• Przejście 3: Styl, zwięzłość, formatowanie, korekta

Architektura

• Przejście 1: Zidentyfikowane komponenty, zmapowany przepływ danych, zdefiniowane interfejsy
• Przejście 2: Tryby awarii, skalowalność, analiza bezpieczeństwa
• Przejście 3: Optymalizacja kosztów, kwestie operacyjne, dokumentacja

Design

• Przejście 1: Layout, hierarchia informacji, przepływ użytkownika
• Przejście 2: Edge case'y (puste stany, błędy, ładowanie), dostępność
• Przejście 3: Wizualny szlif, mikro-interakcje, responsywność

Antywzorce

• Szlifowanie w Przejściu 1 (strata czasu jeśli struktura się zmieni)
• Pomijanie krytyki (dopracowanie bez feedbacku to po prostu przepisywanie)
• Za dużo przejść (3 zwykle wystarczą; 5+ oznacza, że spec był zły)
• Ta sama krytyka co przejście (każde przejście powinno znajdować NOWE problemy, nie powtarzać starych)
• Dopracowywanie bez jasnych kryteriów „gotowe" (nieskończona pętla)