Refactoring Laboratory
Kleine und große Umbauten mit Charakterisierungstests, Zwischenschritten und kontrolliertem Risiko. Nutze die Seite während Entwurf und Umsetzung: Arbeite an einem konkreten Codepfad und sichere Fachverhalten, Abhängigkeiten und Wartbarkeit mit passenden Tests.
Arbeitsauftrag
Wann verwenden?
Wenn Wartbarkeit verbessert werden soll, ohne das beobachtbare fachliche Verhalten zu ändern.
Nicht dafür verwenden
Nicht zusammen mit einer großen Funktionsänderung ohne getrenntes Sicherungsnetz.
Definition of Done
Charakterisierungstests bestehen; Schritte sind klein; Verhalten und Performance bleiben nachgewiesen stabil.
Charakterisierung vor Veränderung
Bei unbekanntem Legacy-Code wird zuerst beobachtbares Verhalten abgesichert. Diese Tests beweisen nicht, dass das Verhalten fachlich richtig ist; sie schützen vor unbeabsichtigten Änderungen.
Seiteneffekte werden über Seams isoliert, bevor Kernlogik verschoben wird.
@Test
void preservesExistingRoundingBehavior() {
BigDecimal result = legacyCalculator.total(
new BigDecimal("10.005"),
new BigDecimal("0.20"));
assertThat(result).isEqualByComparingTo("12.01");
}
God Service zerlegen
Ein großer Service wird nicht blind in viele kleine Services zerlegt. Zuerst werden Verantwortlichkeiten, Transaktionsgrenzen, Invarianten und externe Effekte markiert.
Danach werden pure Berechnungen extrahiert, Ports eingeführt und Use Cases getrennt. Jeder Schritt bleibt baubar und getestet.
1. Öffentliche Verhaltensfläche inventarisieren
2. Charakterisierungstests ergänzen
3. Pure Berechnung extrahieren
4. Externe Zugriffe hinter Ports verschieben
5. Use Cases nach fachlicher Absicht schneiden
6. Transaktionsgrenzen neu prüfen
7. Paket- und Modulgrenzen durch Tests schützen
Strangler-Migration
Bei einer Strangler-Migration werden neue Funktionen an einer kontrollierten Grenze implementiert und alte Pfade schrittweise verdrängt. Routing, Datenverantwortung und Rückfallstrategie müssen explizit sein.
Praxisartefakt · Refactoring-Plan
- Sicherungsnetz
- Fünf Charakterisierungstests für Rabattgrenzen und Berechtigungsfehler.
- Schritt 1
- Audit-Schreiben hinter bestehenden Port verschieben.
- Schritt 2
- Berechtigungsprüfung als benannte Policy extrahieren.
- Schritt 3
- Rabattregeln einzeln modellieren; Verhalten nach jedem Commit prüfen.
- Stoppkriterium
- Test, Latenz oder fachliches Ergebnis weicht von der Baseline ab.