Was macht Refactor?
Verwendung
- Der Benutzer bittet um Refactoring, Umstrukturierung, Code-Verschiebung, Modul-Aufteilung oder Zusammenführung, Interface-Vereinfachung, stufenweises Rewriting, Abhängigkeitsinversion oder Entfernung von doppeltem Code.
- Eine Änderung behauptet, das Verhalten zu erhalten, während die Struktur geändert wird.
- Ein Refactor betrifft mehrere Aufrufstellen, öffentliche Symbole, Tests oder Eigentumsgrenzen.
Nicht verwenden
- Die Aufgabe ist eine kleine lokale Fehlerbehebung ohne strukturelle Änderung.
- Der Benutzer bittet explizit um eine Verhaltensänderung und nicht um einen verhaltenserhaltenden Refactor.
- Vor der Entscheidung über ein Refactoring ist eine breitere Design-Überprüfung erforderlich.
- Der richtige erste Schritt ist eine breite technische Überprüfung, da der dominante Risikobereich noch unklar ist.
Workflow
- Definieren Sie das zu erhaltende Verhalten und die zu ändernde Struktur.
- Geben Sie Nicht-Ziele an: keine Funktionsänderungen, keine Kompatibilitätsänderungen, keine Änderungen der Fehlersemantik, keine Leistungsbehauptungen, sofern nicht explizit angefordert.
- Untersuchen Sie Aufrufer, Tests, Dokumentation, Konfigurationen, generierten Code und öffentliche Oberflächen, die vom Refactor betroffen sind.
- Fügen Sie Charakterisierungstests hinzu, wenn das Verhalten wichtig ist und die Abdeckung schwach ist.
- Teilen Sie die Arbeit in kleine, umkehrbare Schritte auf, die zwischen sinnvollen Grenzen kompilieren und getestet werden.
- Trennen Sie mechanische Verschiebungen oder Umbenennungen von semantischen Änderungen.
- Erhalten Sie öffentliche APIs, sofern der Benutzer nicht explizit eine bahnbrechende Änderung anfordert.
- Entfernen Sie alte Pfade erst, nachdem die Aufrufer migriert und das Verhalten überprüft wurden.
Referenzen
- Lesen Sie
references/refactor-playbook.md, bevor Sie einen mehrstufigen Refactor planen. - Lesen Sie
references/characterization-tests.md, wenn Tests schwach sind oder das Verhalten festgelegt werden muss. - Lesen Sie
references/review-checklist.md, bevor Sie einen Refactor abschließen.
Abbruchbedingungen
- Das zu erhaltende Verhalten ist unklar.
- Der Refactor erfordert breite Verhaltensänderungen, um erfolgreich zu sein.
- Öffentliche API, Konfiguration, Protokoll, Speicher, Metriken oder Fehlersemantik können sich ohne explizite Zustimmung des Benutzers ändern.
- Der Diff mischt Refactoring, Feature-Arbeit, Leistungsoptimierung und Bereinigung auf eine Weise, die nicht sicher überprüft werden kann.
Ausgaberegeln
- Berichten Sie, welches Verhalten unverändert bleiben sollte.
- Berichten Sie mechanische Änderungen getrennt von semantischen Änderungen.
- Berichten Sie über Tests oder Prüfungen, die das Verhalten schützen.
- Geben Sie alle Aspekte des Verhaltens, der Kompatibilität oder der Leistung an, die nicht verifiziert wurden.