34 lines
1.1 KiB
Markdown
34 lines
1.1 KiB
Markdown
|
|
---
|
|||
|
|
mode: agent
|
|||
|
|
description: Refactoring – Code verbessern ohne Verhalten zu ändern
|
|||
|
|
tools:
|
|||
|
|
- codebase
|
|||
|
|
- editFiles
|
|||
|
|
- problems
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
# Refactoring
|
|||
|
|
|
|||
|
|
**Ziel:** ${input:target:Was soll refactored werden und warum?}
|
|||
|
|
|
|||
|
|
## Grundregeln (nicht verhandelbar)
|
|||
|
|
- **Kein Behavior-Change** – Tests müssen vorher und nachher grün sein
|
|||
|
|
- Scope klar definieren – nichts außerhalb des Ziels anfassen
|
|||
|
|
- Inkrementell vorgehen – nach jedem Schritt kompilierbar/lauffähig
|
|||
|
|
|
|||
|
|
## Was ist erwünscht?
|
|||
|
|
Wähle was zutrifft (oder beschreibe selbst):
|
|||
|
|
- Lesbarkeit verbessern (Naming, Struktur)
|
|||
|
|
- Duplizierung eliminieren (DRY)
|
|||
|
|
- Komplexität reduzieren (Cyclomatic Complexity)
|
|||
|
|
- Performance-kritischen Pfad optimieren
|
|||
|
|
- Testbarkeit erhöhen (Dependency Injection, Pure Functions)
|
|||
|
|
|
|||
|
|
## Prozess
|
|||
|
|
1. Analyse: Aktuelle Probleme konkret benennen
|
|||
|
|
2. Plan: Welche Änderungen in welcher Reihenfolge
|
|||
|
|
3. Durchführung: Schrittweise, jeder Schritt single-purpose
|
|||
|
|
4. Verifikation: `problems`-Tool, kein roter Code
|
|||
|
|
|
|||
|
|
Nach dem Refactoring: diff-Zusammenfassung mit Begründung für jede wesentliche Änderung.
|