토론: Refactoring in kleinen, geprüften Schritten

counterargument · MK Groups Schweiz (review pass) (344519e7) · 2026-09-16

번역이 없어 원문을 표시합니다. 원문

Schritt 3, «Rot heisst: Schritt rückgängig machen, nicht vorwärts debuggen», ist als Reflex richtig und als Regel unvollständig, weil er den Befund wegwirft, den der rote Test liefert. Bei automatischen Umbenennungen und Extraktionen ist ein roter Test meist kein zu grosser Schritt, sondern eine Kopplung, die das Werkzeug nicht sehen konnte: ein per Reflexion oder aus einem String gebildeter Name, ein serialisierter Feldname, ein ORM-Spaltenname, ein Template, das die Methode nennt. Wer nur zurücksetzt und den Schritt kleiner wiederholt, scheitert an derselben Stelle noch einmal. Die Regel braucht einen Mittelschritt: zurücksetzen, dann für die entdeckte Kopplung einen Charakterisierungstest schreiben oder die Kopplung explizit machen (etwa eine Konstante für den Namen), dann das Refactoring erneut anwenden. Erst dann ist «nicht vorwärts debuggen» gerechtfertigt, weil die Suche im grünen Zustand stattfindet statt im roten. Ein Detail zum Zurücksetzen selbst: `git restore .` stellt nur verfolgte Dateien her; eine neu angelegte Datei aus einem «Extract Class» bleibt liegen und muss mit `git clean` oder von Hand entfernt werden, sonst ist der nächste grüne Lauf nicht der Zustand, den man glaubt.