Fortgeschritten
Patterns & Anti-Patterns
Was funktioniert und was nicht
Was funktioniert – und was nicht
Diese Patterns sind erprobte Vorgehensweisen für verschiedene Situationen. Die Anti-Patterns zeigen dir, was du vermeiden solltest.
Pattern: Explain First
Wann: Wenn du Code verstehen willst, bevor du ihn änderst.
Bevor Claude was ändert, soll es erklären. Das gibt dir die Kontrolle und hilft, Missverständnisse früh zu erkennen.
Pattern: Show Options
Wann: Bei Architektur-Entscheidungen oder wenn mehrere Lösungen möglich sind.
Pattern: Planning First
Wann: Vor größeren Features oder Refactorings.
Tipp
Wenn du mehr als 2-3 Dateien anfassen musst, lohnt sich ein Plan. Die 2 Minuten Planung sparen 20 Minuten Korrektur.
Pattern: Step by Step
Wann: Für größere Features oder wenn du die Kontrolle behalten willst.
Pattern: Test First
Wann: Wenn du sicherstellen willst, dass die Änderung funktioniert.
Wann welches Pattern?
| Situation | Pattern |
|---|---|
| Code verstehen wollen | Explain First |
| Architektur-Entscheidung | Show Options |
| Großes Feature | Planning First |
| Kontrolle behalten | Step by Step |
| Neue Funktionalität | Test First |
Anti-Pattern: Der Einzeiler
Zu wenig Information → Claude muss raten
"Fix it"
Was fixen? Wo? Welches Verhalten ist gewünscht?
Besser:
Mindestens Kontext + Aufgabe. Was ist wo und was soll passieren?
Anti-Pattern: Der Roman
500-Wörter-Prompt → Claude verliert den Fokus
"Ich habe hier dieses Projekt und das macht XYZ und früher haben wir ABC gemacht aber jetzt wollen wir DEF und dabei sollte man beachten dass GHI und außerdem JKL..."
Zu viel Information auf einmal. Claude weiß nicht, was wichtig ist.
Besser:
Kurz und klar, dann iterieren. Fokus auf EINE Sache.
Anti-Pattern: Alles auf einmal
"Füge Validierung hinzu, ändere das Layout, optimiere die Query, schreibe Tests und update die Docs"
5 Aufgaben = 5 Fehlermöglichkeiten. Schwer zu reviewen.
Besser:
Eine Aufgabe nach der anderen. Teste dazwischen.
Anti-Pattern: Blindes Vertrauen
"Claude hat das geschrieben, wird schon passen."
Besser:
Änderungen reviewen. Verstehen was passiert. Tests laufen lassen.
Anti-Pattern: Code-Diktator
"Füge in Zeile 42 'if user.valid?' ein und dann in Zeile 45..."
Du denkst noch wie bei Copy-Paste. Claude könnte es besser lösen.
Besser:
Beschreibe das gewünschte ERGEBNIS, nicht den genauen Code.
Zusammenfassung
Tu das
- Erst erklären lassen, dann ändern
- Optionen zeigen lassen
- Planen vor großen Features
- Schritt für Schritt vorgehen
- Ergebnisse beschreiben
Vermeide das
- Zu wenig Kontext
- Zu viel auf einmal
- Blindes Vertrauen
- Code diktieren
- Nach einem Versuch aufgeben
Wichtig