boshu2/refactor

Refactor — ein strukturelles Experiment

Refactor ändert die Struktur, während es das beobachtbare Verhalten beibehält. Es führt eine vom Aufrufer ausgewählte Transformation durch und berichtet das Ergebnis.

Prompt

Refactoriere billing-service/internal/retry/backoff.go: Extrahiere die exponentielle Backoff-Berechnung aus RetryRequest in eine eigene Funktion, keine anderen Verhaltensänderungen. Zeichne eine Baseline auf, führe go test ./internal/retry/... vorher und nachher aus, und berichte die Diff-Zusammenfassung, Befehle, Ergebnisse und alles, was nicht geprüft wurde.

Es funktioniert, wenn

• Der Bericht das bewahrte Verhalten benennt und auf die Ausführung von go test ./internal/retry/... sowohl vorher als auch nachher verweist.
• git diff --stat nur internal/retry/backoff.go betrifft, niemals eine nicht zusammenhängende Datei.
• Golden-Output-Hashes byteweise erfasst und verglichen werden, wenn die geänderte Oberfläche Output erzeugt, z. B. sha256sum vorher und nachher.
• Die Liste "nicht geprüftes Verhalten" im Bericht auch dann vorhanden ist, wenn sie leer ist, und jede Oberfläche benennt, die von den Gates übersprungen wurde.

Vorgehen

1. Benenne das bewahrte Verhalten, die fokussierte Akzeptanzoberfläche und das konkrete strukturelle Problem für seine Aufrufer. Verwende die Domänenbegriffe der Aufrufer und akzeptierte Verhaltensbeispiele wieder; bewahre ihre Bedeutung während der Änderung.
2. Zeichne eine ehrliche Baseline auf, einschließlich aller reproduzierbaren vorab bestehenden Fehler. Für einen Vergleich, der ausführbares Verhalten vergleicht, fixiere den Startquellcode und erstelle seine Baseline vor den Änderungen; behalte diese Binärdatei und die Vergleichseingaben. Vergleiche den Kandidaten mit diesen Eingaben und derselben Toolchain. Dies fügt dem gewöhnlichen Refactoring kein Ritual des ausführbaren Vergleichs hinzu.
3. Wende eine begrenzte Transformation an: Extraktion, Umbenennung, Inline-Ersetzung, Vereinfachung, Kapselung, Verschiebung oder Löschung von totem Code. Beurteile das Ergebnis danach, was Aufrufer verstehen müssen und wo eine Domänenregel geändert werden muss, nicht allein nach der Dateigröße.
4. Führe die fokussierte Prüfung und die kleinste paketweite Regressionprüfung durch, die durch die geänderte Oberfläche gerechtfertigt ist.
5. Gib die Diff-Zusammenfassung, Befehle, Ergebnisse und das nicht geprüfte Verhalten zurück.

Kombiniere keine neu entdeckte Verhaltenskorrektur mit der strukturellen Änderung. Ein rotes Ergebnis ist ein Hinweis für den Aufrufer; dieses Skill macht keine automatischen Rücksetzungen, Eingrenzungen, Wiederholungen, Commits, Validierungen oder Weiterleitungen nachfolgender Arbeiten.

Verantwortung und Schnittstellenkosten

Bevor du eine Schnittstelle hinzufügst oder ein Modul aufteilst, inspiziere repräsentative Aufrufer. Zähle die Konzepte, die sie koordinieren müssen: erforderliche Einrichtung, Reihenfolge, Zustände, Fehlerbehandlung und wiederholte Domänenregeln. Eine nützliche Grenze legt eine kohäsive Regel unter einen Eigentümer und lässt Aufrufer ein Ergebnis anfordern, ohne diese Regel nachbilden zu müssen. Lehne einen Wrapper ab, der nur einen weiteren Namen hinzufügt oder dieselbe Koordination in seine Aufrufer verschiebt. Bestehende Grenzen sind ausreichend, wenn kein konkretes Aufruferproblem ihre Änderung rechtfertigt.

Verwende das Vokabular der Aufrufer für extrahierte Operationen und Typen. Eine Mehrdeutigkeit in der Benennung, die das Verhalten ändert, gehört zur bestehenden Domänendefinition; ziehe Domain nur zu Rate, wenn diese Unterscheidung bearbeitet werden muss. Die Umbenennung eines öffentlichen Symbols, eines persistenten Feldes oder eines Protokollwerts ist eine Kompatibilitätsänderung, es sei denn, der akzeptierte Umfang sieht dies vor.

Wenn die Transformation eine Nahtstelle benötigt – eine Extraktionsgrenze, Schnittstelle oder Modulaufteilung – und mehr als eine Kandidaten-Nahtstelle existiert, teste vor dem Schnitt. Führe den Test in isolierter Umgebung durch (ein temporärer Branch, Worktree oder ein kopiertes Verzeichnis, das die Richtlinie des Aufrufers erlaubt): baue die Nahtstelle grob ein, beobachte, was sie erzwingt – Signaturänderungen, Importzyklen, Testumschreibungen –, verwerfe dann den Test und behalte nur das Wissen. Abbruchbedingung: höchstens zwei Tests; wenn auch die zweite Kandidaten-Nahtstelle Widerstand leistet, melde beide Erkenntnisse dem Aufrufer, anstatt einen dritten Test zu versuchen. Das direkte Einbringen der erstbesten denkbaren Nahtstelle in den Arbeitsbaum ist der Fehlermodus der vorzeitigen Nahtstelle: Die falsche Grenze verhärtet sich, weil das Rückgängigmachen jetzt mehr kostet als das Leben mit ihr.

Neutralitätsgates

„Verhaltenserhaltend“ ist eine Behauptung, die es auszuführen gilt, nicht zu behaupten. Schalte die Transformation auf verhaltensidentischen Nachweis:

• Die fokussierte Prüfung und die paketweite Regressionprüfung bestehen sowohl vorher als auch nachher, mit derselben Menge vorab bestehender Fehler – kein neues Rot und auch kein leise verschwundenes Rot (ein Test, der nicht mehr läuft, ist eine Verhaltensänderung).
• Bei ausgabeproduzierenden Oberflächen (Generatoren, Serialisierer, Formatierer, Berichte) hashe die Ausgaben: Erfasse Golden-Output-Hashes über identische Eingaben vor der Änderung und vergleiche sie Byte für Byte nach der Änderung. Ein Hash-Unterschied ist ein Verhaltensunterschied, der offengelegt und erklärt werden muss, niemals zu ignorieren; der Aufrufer entscheidet, ob die Änderung beibehalten, eingegrenzt oder rückgängig gemacht wird.
• Beobachtbare Fehlermeldungen, Exit-Codes und öffentliche Signaturen auf der geänderten Oberfläche sind Teil des Verhaltens, es sei denn, der Aufrufer hat sie ausgeschlossen.

Ein Neutralitätsgate, das nachträglich übersprungen oder eingegrenzt wurde, ist der Fehlermodus der Post-hoc-Neutralität – der Diff entscheidet, was getestet wurde. Benenne jede Oberfläche, die von den Gates nicht abgedeckt wurde, in der Liste "nicht geprüftes Verhalten" des Berichts.

Referenzen

• Verhaltenserhaltende Vereinfachung
• Verhaltensszenarien
• Upstream-Funktionsreferenz – Matt Pocock; ursprüngliche AgentOps-Anpassung.