Głębokie rozumowanie dla funkcji

Tworzenie oprogramowania to nie tylko pisanie kodu - to podejmowanie setek wzajemnie powiązanych decyzji, które kształtują system na lata. Możliwości głębokiego rozumowania Claude Code przekształcają planowanie funkcji z zgadywania w systematyczne eksplorowanie możliwości, kompromisów i optymalnych rozwiązań.

Moc głębokiego myślenia

Scenariusz: Twój CEO właśnie ogłosił duży zwrot. Platforma e-commerce musi obsługiwać zamówienia hurtowe B2B ze złożonymi poziomami cenowymi, przepływami zatwierdzania, rabatami hurtowymi i integracją z ERP-ami przedsiębiorstw. Masz 6 tygodni. Tradycyjne podejście? Panika, potem zgadywanie. Z Claude Code? Uwolnijmy jego pełny potencjał rozumowania.

Wyjaśnienie trybów myślenia

> Dodaj uwierzytelnianie użytkowników do naszej aplikacji

Claude: Dodam podstawowy system autoryzacji...
[Szybka implementacja bez głębokiej analizy]

> Pomyśl o tym, jak dodać uwierzytelnianie użytkowników do naszej aplikacji

Claude: Przeanalizujmy wymagania i opcje...
[~5,000 tokenów rozumowania]
- Ocenia różne strategie autoryzacji
- Rozważa implikacje bezpieczeństwa
- Rozważa opcje frameworków
- Planuje podejście do implementacji

> Pomyśl głębiej o naszej architekturze uwierzytelniania

Claude: Dogłębnie przeanalizuję wszystkie możliwości architektoniczne...
[~10,000 tokenów rozumowania]
- Kompleksowa analiza wzorców autoryzacji
- Szczegółowe modelowanie zagrożeń bezpieczeństwa
- Analiza wpływu na wydajność
- Strategia migracji z obecnego systemu

> Ultrathink o projektowaniu naszego systemu autoryzacji dla przedsiębiorstw

Claude: Uruchamiam maksymalną zdolność rozumowania...
[~128,000 tokenów głębokiej analizy]
- Wyczerpująca eksploracja wszystkich opcji
- Szczegółowa analiza kompromisów
- Identyfikacja przypadków brzegowych
- Planowanie długoterminowej skalowalności
- Rozważania zgodności

Przepływ pracy PRD → Plan → Todo

Faza 1: Od PRD do zrozumienia

Przekształć wymagania biznesowe w jasność techniczną:

Wczytaj PRD

> Przeczytaj PRD dla naszej funkcji hurtowej B2B w docs/b2b-wholesale-prd.md
> Podsumuj kluczowe wymagania i zidentyfikuj niejasnośc

Wyjaśnij wymagania

> Pomyśl o potencjalnych przypadkach brzegowych w wymaganiach hurtowych B2B.
> Jakie pytania powinniśmy zadać zespołowi produktowemu?

Eksploracja techniczna

> Pomyśl głębiej o technicznych implikacjach tych wymagań.
> Jakie są główne wyzwania architektoniczne, z którymi się zmierzymy?

Stwórz specyfikację techniczną

> Na podstawie PRD, stwórz specyfikację techniczną, która obejmuje:
> - Zmiany modelu danych
> - Projekt API
> - Punkty integracji
> - Wymagania wydajnościowe
> - Rozważania bezpieczeństwa

Faza 2: Głębokie planowanie

Planowanie architektury

> Ultrathink o architekturze dla hurtowni B2B.
> Rozważ:
> - Ograniczenia obecnego systemu
> - Wymagania skalowalności
> - Złożoność integracji
> - Możliwości zespołu
> - Ograniczenia czasowe
>
> Zaproponuj 3 różne podejścia architektoniczne z
> szczegółowymi kompromisami dla każdego

Analiza ryzyka

> Pomyśl mocno o ryzykach wdrożenia hurtowni B2B.
> Kategoryzuj według:
> - Ryzyka techniczne
> - Ryzyka biznesowe
> - Ryzyka czasowe
> - Ryzyka integracji
>
> Dostarcz strategie mitygacji dla każdego

Mapowanie zależności

> Przeanalizuj zależności dla funkcji B2B.
> Zmapuj:
> - Zależności kodu
> - Zależności usług
> - Zależności danych
> - Zależności systemów zewnętrznych
>
> Zidentyfikuj potencjalne wąskie gardła

Strategia implementacji

> Pomyśl o najlepszym podejściu do implementacji.
> Czy powinniśmy:
> - Budować obok istniejącego systemu?
> - Stworzyć osobną usługę B2B?
> - Refaktoryzować obecny system?
>
> Rozważ strategie wycofania

Faza 3: Przekształć na wykonalne zadania

Przekształć plan w wykonywalne zadania:

> Na podstawie naszego planu hurtowni B2B, stwórz szczegółową listę zadań.
> Dla każdego zadania:
> - Oszacuj złożoność (S/M/L/XL)
> - Zidentyfikuj zależności
> - Zanotuj, który członek zespołu byłby najbardziej odpowiedni
> - Oflaguj wszelkie blokery
>
> Zorganizuj według faz implementacji

Claude generuje ustrukturyzowane zadania:

# Zadania implementacji hurtowni B2B

## Faza 1: Fundament (Tydzień 1-2)

### Aktualizacje schematu bazy danych
- [ ] Zaprojektuj tabelę wholesale_accounts (M)
  - Zależności: Brak
  - Przypisany: Zespół backend
  - Notatki: Zawiera hierarchię zatwierdzeń

- [ ] Stwórz tabelę price_tiers (M)
  - Zależności: wholesale_accounts
  - Przypisany: Zespół backend
  - Notatki: Obsługa cen opartych na wolumenie

- [ ] Dodaj tabelę bulk_orders (L)
  - Zależności: price_tiers
  - Przypisany: Zespół backend
  - Notatki: Złożona maszyna stanów dla zatwierdzeń

### Rozwój API
- [ ] Stwórz endpointy CRUD kont hurtowych (M)
  - Zależności: Schemat bazy danych
  - Przypisany: Zespół API
  - Szczegóły: POST /api/wholesale/accounts, itp.

- [ ] Zaimplementuj usługę kalkulacji cen (XL)
  - Zależności: tabela price_tiers
  - Przypisany: Senior backend dev
  - Bloker: Potrzeba reguł cenowych od biznesu

## Faza 2: Funkcje podstawowe (Tydzień 3-4)

### Przepływ zatwierdzeń
- [ ] Zaprojektuj maszynę stanów zatwierdzeń (L)
  - Zależności: tabela bulk_orders
  - Przypisany: Zespół architektury
  - Notatki: Rozważ użycie temporal.io

- [ ] Zaimplementuj endpointy API zatwierdzeń (L)
  - Zależności: Projekt maszyny stanów
  - Przypisany: Zespół backend

### Warstwa integracji
- [ ] Stwórz interfejs integracji ERP (XL)
  - Zależności: Brak
  - Przypisany: Zespół integracji
  - Bloker: Czeka na dokumentację API ERP

## Faza 3: UI/UX (Tydzień 5-6)
[... kontynuuje ze szczegółowymi zadaniami ...]

Przykłady planowania funkcji z rzeczywistego świata

Przykład 1: Przeprojektowanie systemu płatności

Wyzwanie: Migracja ze Stripe do systemu wieloproviderowego obsługującego 15 krajów.

> Ultrathink o migracji naszego systemu płatności z wyłącznie Stripe
> do obsługi wielu providerów (Stripe, PayPal, Adyen, lokalni providerzy).
> Obecny system przetwarza 10M$/miesiąc. Zero przestojów dozwolone.
> Rozważ:
> - Strategię migracji danych
> - Projekt abstrakcji providerów
> - Możliwości wycofania
> - Podejście testów A/B
> - Wymagania zgodności per kraj

Claude’s głębokie rozumowanie produkuje:

graph TB A[Żądanie płatności] --> B[Router płatności] B --> C{Wybór providera} C -->|Wzorzec strategii| D[Adapter Stripe] C -->|Wzorzec strategii| E[Adapter PayPal] C -->|Wzorzec strategii| F[Adapter Adyen] C -->|Wzorzec strategii| G[Adaptery lokalne] D --> H[API providera] E --> I[API providera] F --> J[API providera] G --> K[API providerów] H --> L[Normalizator odpowiedzi] I --> L J --> L K --> L L --> M[Wynik płatności] N[Wyłącznik obwodu] -.->|Monitoruje| C O[Provider zapasowy] -.->|Backup| C

Flagi funkcji per provider

if (featureFlag.isEnabled('paypal_usa')) {
  providers.register('US', PayPalProvider);
}

Automatyczne wyzwalacze wycofania
- Współczynnik błędów > 1%
- Czas odpowiedzi > 2s
- Współczynnik sukcesu < 98%
Kontrole spójności danych
- Podwójny zapis do starych i nowych systemów
- Asynchroniczne zadanie rekoncyliacji
- Alert przy niezgodnościach
Monitorowanie zdrowia providerów
- Dashboard w czasie rzeczywistym
- Automatyczne przełączanie awaryjne
- Śledzenie SLA per provider

Przykład 2: Funkcja współpracy w czasie rzeczywistym

Wyzwanie: Dodanie współpracy w stylu Google Docs w czasie rzeczywistym do narzędzia zarządzania projektami.

> Pomyśl głębiej o implementacji współpracy w czasie rzeczywistym.
> Obecna architektura: Tradycyjne REST API z PostgreSQL.
> Wymagania:
> - Obsługa 50 jednoczesnych użytkowników per dokument
> - Pokazywanie kursorów i selekcji użytkowników
> - Edycja bez konfliktów
> - Działanie offline z synchronizacją
> - Skala do 10k dokumentów

Analiza Claude produkuje kompleksowy plan:

Wybór technologii Po analizie opcji (WebSockets, WebRTC, SSE, polling), rekomenduje:
- Yjs dla implementacji CRDT
- WebSocket z Socket.io dla transportu
- Redis dla obecności i danych efemerycznych
- PostgreSQL dla persystencji

Projekt architektury

Klient (Yjs) ↔ WebSocket ↔ Usługa współpracy
                                   ↓
                           Redis (Obecność)
                                   ↓
                           PostgreSQL (Persystencja)

Fazy implementacji
- Faza 1: Podstawowa synchronizacja w czasie rzeczywistym (2 tygodnie)
- Faza 2: Obecność (kursory, selekcje) (1 tydzień)
- Faza 3: Wsparcie offline (2 tygodnie)
- Faza 4: Optymalizacja wydajności (1 tydzień)
Krytyczne decyzje
- Użyj Yjs dla automatycznego rozwiązywania konfliktów
- Zaimplementuj łączenie operacji dla wydajności
- Dodaj system migawek dla dużych dokumentów
- Użyj poolowania połączeń dla skalowania WebSocket

## Rekordy decyzji architektonicznych

Claude Code może pomóc tworzyć ADR podczas planowania:

Stwórz rekord decyzji architektonicznej dla wyboru między mikroserwisami vs modularnym monolitem dla naszej funkcji hurtowej B2B. Użyj formatu Y-statement.

Wynik:

```markdown
# ADR-001: Wzorzec architektury hurtowni B2B

## Status
Proponowany

## Kontekst
Musimy dodać możliwości hurtowe B2B do naszej platformy e-commerce. Obejmuje to złożone ceny, przepływy zatwierdzeń i integracje ERP. Zespół ma 5 programistów, termin 6 tygodni.

## Decyzja
W kontekście **dodawania hurtowni B2B do naszej platformy e-commerce**,
w obliczu **złożoności wymagań i napiętego terminu**,
zdecydowaliśmy się na **podejście modularnego monolitu**,
a nie na **architekturę mikroserwisów**,
aby osiągnąć **szybszą początkową dostawę i prostsze wdrożenie**,
akceptując **potencjalne przyszłe koszty refaktoryzacji**.

## Konsekwencje

### Pozytywne
- Pojedyncza jednostka wdrożenia (redukuje złożoność DevOps)
- Wspólne transakcje bazy danych (spójność danych)
- Łatwiejszy rozwój lokalny
- Szybszy początkowy rozwój
- Niższe koszty operacyjne

### Negatywne
- Trudniejsze skalowanie pojedynczych komponentów
- Ryzyko sprzężenia między modułami
- Pojedynczy punkt awarii
- Potencjalne wąskie gardła wydajności

### Mitygacja
- Ścisłe granice modułów używając osobnych pakietów
- Czyste interfejsy między modułami
- Separacja schematu bazy danych
- Planuj punkty ekstrakcji dla przyszłych usług

Używanie subagentów do złożonej analizy

Dla ekstremalnie złożonych funkcji, wykorzystaj subagentów:

> Użyj subagentów do analizy różnych aspektów naszej funkcji B2B:
> 1. Implikacje bezpieczeństwa i wymagane kontrole
> 2. Wpływ na wydajność istniejącego systemu
> 3. Wymagania migracji danych
> 4. Złożoność integracji z top 3 ERP-ami
>
> Zsyntezuj ustalenia w macierz ryzyka

Claude orkiestruje wielu wyspecjalizowanych agentów:

Antywzorce planowania, których należy unikać

1. Przepisanie typu Big Bang

❌ "Przepisz cały system płatności naraz"
✅ "Stwórz warstwę adaptera, migruj stopniowo"

2. Paraliż idealnego planowania

❌ "Ultrathink o każdym możliwym przypadku brzegowym"
✅ "Pomyśl mocno o podstawowej architekturze, iteruj nad szczegółami"

3. Ignorowanie rzeczywistości zespołu

❌ "Użyj najnowocześniejszego stosu technologicznego, którego nigdy nie używaliśmy"
✅ "Wykorzystuj znane narzędzia, wprowadzaj nowe stopniowo"

4. Pomijanie analizy ryzyka

❌ "Ten plan wygląda dobrze, zacznijmy kodować"
✅ "Co może pójść nie tak? Jak to zmienimy?"

Interaktywne sesje planowania

Spraw, by planowanie było współpracujące:

Początkowy zrzut mózgu

> Jakie są wszystkie rzeczy, które musimy rozważyć dla hurtowni B2B?
> Nie organizuj jeszcze, po prostu wylistuj wszystko

Kategoryzuj i priorytetyzuj

> Zorganizuj te rozważania w:
> - Musieć mieć dla MVP
> - Powinno mieć
> - Miło mieć
> - Przyszłe rozważania

Spike niepewnych obszarów

> Nie jesteśmy pewni złożoności integracji ERP.
> Stwórz plan technicznego spike'a do zbadania

Przejrzyj i dopracuj

> Przejrzyj nasz plan. Co przegapiliśmy?
> Jakie założenia robimy?

## Tłumaczenie planów na kod

Po zakończeniu planowania, płynnie przejdź do implementacji:

Zdecydowaliśmy się na podejście modularnego monolitu. Stwórz początkową strukturę modułu dla hurtowni B2B:

Podstawowe modele domeny

Struktura modułu API

Migracje bazy danych

Definicje interfejsów między modułami

Claude generuje podstawową strukturę kodu opartą na planie, zapewniając zgodność między decyzjami architektonicznymi a implementacją.

## Najlepsze praktyki planowania funkcji

### 1. Zacznij od dlaczego

Zawsze rozumiej powód biznesowy:

Zanim zaplanujemy rozwiązanie techniczne, pomóż mi zrozumieć dlaczego hurtownia B2B jest ważna dla naszego biznesu. Jakie problemy rozwiązuje dla naszych klientów?

### 2. Rozważ cały system

Jak hurtownia B2B wpłynie na:

Obecnych klientów B2C

Wydajność systemu

Obciążenie zespołu wsparcia

Przyszły rozwój funkcji

### 3. Planuj obserwowalnośc

Jakie metryki i monitorowanie potrzebujemy dla hurtowni B2B? Zaprojektuj strategię obserwowalnośc wraz z funkcją

### 4. Dokumentuj uzasadnienie decyzji

Dla każdej ważnej decyzji w naszym planie, udokumentuj:

Co zdecydowaliśmy

Dlaczego to zdecydowaliśmy

Jakie alternatywy rozważaliśmy

Co sprawiłoby, że byśmy to ponownie rozważyli

## Powiązane lekcje

<LinkCard
  title="Od planu do implementacji"
  description="Przekształć swoje starannie opracowane plany w działający kod"
  href="/pl/claude-code/lessons/implementation"
/>

<LinkCard
  title="Wzorce architektury"
  description="Głębokie zanurzenie w projektowanie systemów z Claude Code"
  href="/pl/claude-code/lessons/architecture"
/>

<LinkCard
  title="Inicjalizacja projektu"
  description="Skonfiguruj nowe projekty zgodnie z twoimi decyzjami architektonicznymi"
  href="/pl/claude-code/lessons/project-setup"
/>

## Następne kroki

Nauczyłeś się, jak wykorzystać możliwości głębokiego rozumowania Claude Code do planowania funkcji. To przekształca cię z kodera w architekta, z wykonawcy zadań w strategicznego myśliciela.

Pamiętaj: Najlepszy kod to kod, którego nie musisz pisać, ponieważ zaplanowałeś prostsze rozwiązanie. Najszybsza funkcja to ta, w której uniknąłeś pułapek dzięki starannej analizie. Pozwól, by możliwości myślenia Claude Code wzmocniły twoje własne, przekształcając złożone wymagania w jasne, wykonalne plany, które prowadzą do udanych implementacji.