Prompt-Vorlagen zum Refaktorieren von Code

Refaktoriere [Komponente/Modul/Funktion], um [konkretes Wartbarkeitsproblem] zu verbessern.

Verhaltenserhaltung: Behalte [öffentliche API, sichtbares Verhalten, Ereignisse,
Fehlerbehandlung, Barrierefreiheit, Leistungsmerkmal] unverändert.

Umfang: Begrenze Änderungen auf [Dateien/Grenze]. Ändere [explizite Nicht-Ziele] nicht.

Tests: Identifiziere die bestehenden Tests, die den aktuellen Vertrag beweisen. Füge
fokussierte Regressionstests hinzu, wenn ein geschütztes Verhalten nicht abgedeckt ist.

Akzeptanzkriterien: Die Duplizierung oder Kopplung ist reduziert, öffentliches Verhalten
ist unverändert und der Diff enthält keine nicht zusammenhängende Bereinigung.

Validierung: Führe [fokussierten Testbefehl], Typprüfung und [manuellen Workflow] aus.
Beschreibe vor der Bearbeitung den aktuellen Vertrag und die kleinste sichere Extraktion.

Extrahiere den wiederholten [UI-Bereich] aus [übergeordneten Komponenten] in die kleinste
wiederverwendbare Komponente.

Verhaltenserhaltung: Behalte sichtbare Bezeichnungen, Tastaturfokus, aria-Attribute,
Ladezustand, Analytics-Ereignisse und mobiles Layout identisch.

Umfang: Nur [übergeordnete Komponenten], die neue Komponente und direkte Tests. Verlege
das Abrufen von Daten oder die Zuständigkeit für Mutationen nicht in die extrahierte Komponente.

Tests: Bewahre oder ergänze Tests für die Zustände [leer, Laden, Fehler, befüllt] und
das interaktive Verhalten, auf das sich Nutzer verlassen.

Akzeptanzkriterien: Die übergeordneten Komponenten verwenden die neue Komponente, das
unterschiedliche Verhalten bleibt explizit und keine öffentlichen Props oder Links ändern
sich unerwartet.

Validierung: Führe fokussierte Komponententests aus, prüfe die gerenderten Zustände bei
Desktop- und mobilen Breiten und melde Verhalten, das nicht überprüft werden konnte.

Analysiere die bestehenden Unterschiede, bevor du etwas extrahierst.

Finde die duplizierte Logik in [Dateiliste] und schlage die kleinste gemeinsame
Abstraktion vor.

Verhaltenserhaltung: Bewahre das öffentliche Verhalten, Standardwerte,
Fehlerbehandlung, Telemetrie und Timing jedes Aufrufers.

Umfang: Verallgemeinere nicht über diese Aufrufer hinaus. Halte Unterschiede sichtbar,
wenn sie Produktregeln statt versehentlicher Duplizierung darstellen.

Tests: Ordne jeden bestehenden Test dem gemeinsamen Verhalten zu, das er schützt. Füge
für jede bedeutungsvolle Abweichung einen Test hinzu.

Akzeptanzkriterien: Wiederholte Logik wird nur dort zentralisiert, wo der Vertrag
tatsächlich gleich ist; Aufrufer bleiben lesbar und im Verhalten gleichwertig.

Validierung: Führe die fokussierten Tests der Aufrufer aus und vergleiche ihre
beobachtbare Ausgabe vor und nach der Änderung.

Gib vor Code eine Analyse gemeinsamer im Vergleich zu beabsichtigten Unterschieden zurück.

Untersuche ein Performance-Problem in [Ansicht/Workflow].

Belege: [Messung, Trace, Timing, Nutzerbericht oder reproduzierbares Szenario].
Nimm nicht an, dass [Memoization/Caching/Code Splitting] die Antwort ist.

Verhaltenserhaltung: Behalte nutzerseitiges Laden, Aktualität, Barrierefreiheit,
Autorisierung und Fehlerverhalten unverändert.

Umfang: Prüfe zuerst [Pfade]. Füge ohne gemessenen Bedarf kein persistentes Caching,
keine neue State-Bibliothek und keine Serverabhängigkeit hinzu.

Tests: Behalte bestehende Verhaltenstests. Füge nur dann einen Regressions- oder
Mess-Check hinzu, wenn das Projekt dafür eine stabile Konvention hat.

Akzeptanzkriterien: Benenne den Engpass, zeige eine Baseline und ein Ergebnis und
erhalte das geschützte Verhalten.

Validierung: Führe relevante Tests aus, erfasse die vereinbarte Messung und dokumentiere
Abwägungen wie Aktualität oder Speicher.

Refaktoriere [Legacy-Modul], sodass [konkretes Risiko oder Wartungsaufwand] reduziert
wird, ohne sein von außen beobachtbares Verhalten zu ändern.

Verhaltenserhaltung: Liste die Legacy-Eingaben, -Ausgaben, Fehlermodi, Nebeneffekte,
Dateiformate und Kompatibilitätsanforderungen auf, auf die Clients angewiesen sind.

Umfang: Arbeite innerhalb von [Modul/Grenze]. Aktualisiere keine nicht zusammenhängenden
Abhängigkeiten und schreibe Aufrufer nicht in derselben Änderung um.

Tests: Charakterisiere zuerst das aktuelle Verhalten mit Tests oder Fixtures, wo Abdeckung
fehlt. Beziehe bekannte Randfälle und fehlerhafte Eingaben ein.

Akzeptanzkriterien: Die neue Struktur ist leichter nachzuvollziehen, das charakterisierte
Verhalten bleibt stabil und Kompatibilitätshinweise sind explizit.

Validierung: Führe Charakterisierungstests, bestehende Integrationstests, Typprüfung und
ein repräsentatives manuelles oder Kommandozeilen-Szenario aus.

Erkläre unbekanntes Verhalten und Risiken, bevor du eine Implementierung vorschlägst.

Plane ein schrittweises Refactoring von [System], um [Zielarchitektur] zu erreichen.

Verhaltenserhaltung: Bewahre [öffentliche APIs, Datenkompatibilität, Berechtigungen,
Nutzer-Workflows, Bereitstellungsverhalten und Rollback-Pfad].

Umfang: Teile die Arbeit in unabhängig testbare Meilensteine auf. Identifiziere Dateien,
die sich im ersten Meilenstein nicht ändern sollten.

Tests: Definiere die fokussierten Tests, Vertragstests, Migrationsprüfungen und manuellen
Workflows, die jeder Meilenstein bestehen muss, bevor der nächste beginnt.

Akzeptanzkriterien: Jede Phase hat eine klare Eintrittsbedingung, ein beobachtbares Ergebnis,
eine Rollback-Strategie und keine versteckte Abhängigkeit von einer späteren Phase.

Validierung: Prüfe den Plan gegen die aktuelle Architektur, führe die Prüfungen jeder Phase
aus und halte an, falls ein Meilenstein die ursprüngliche Annahme ungültig macht.

Bearbeite keinen Code, bevor du die Phasen, Risiken und Alternativen präsentiert hast.