Legacy-PHP refactoren ohne alles kaputt zu machen

Es gibt einen Moment beim Öffnen einer fremden PHP-Codebase den jeder Entwickler kennt. Man schaut die erste Datei an, sieht global $db, $user, $config; in der ersten Zeile, scrollt runter, findet 1.400 Zeilen ohne eine einzige Funktion, und denkt: "Ich zünde das an."

Man zündet es nicht an. Man refactort es. Langsam, vorsichtig, mit der Geduld eines Menschen der gelernt hat dass Schnelligkeit hier Feind ist.

Regel 1: Von außen nach innen, nicht von oben nach unten

Der häufigste Fehler: man fängt oben an und refactort sich durch. Dabei bricht man alles. Stattdessen: fang am Rand an. Isoliere kleine, abgeschlossene Teile. Eine Hilfsfunktion. Eine Datenbankabfrage. Extrahiere sie, schreib einen Test dafür – auch wenn der Test hässlich ist – und deploy das.

Regel 2: Tests vor Refactoring, nicht danach

Characterization Tests sind dein Freund. Du schreibst keinen Test der sagt "das soll so funktionieren" – du schreibst einen Test der sagt "das funktioniert gerade so, und wenn sich das ändert will ich's wissen". Das ist kein TDD, das ist Absicherung für eine Codebase die du noch nicht vollständig verstehst.

Regel 3: Klein committen, oft deployen

Nicht eine Woche refactorn und dann einen Riesencommit machen. Jeden Tag kleine Änderungen, jeden Tag auf Staging deployen, jeden zweiten Tag auf Produktion. So sieht man sofort was gebrochen ist statt es drei Wochen später rauszufinden.

Gesamtdauer für ein solches Projekt: Monate, nicht Wochen. Wer das nicht akzeptiert verbrennt sich daran. Ich hab mich einmal daran verbrannt. Seitdem akzeptiere ich's.