Refactoring-Strategie für Legacy-Code: Wie man systematisch vorgehen sollte
Refactoring Legacy Code gehört zu den Aufgaben, die jeder verschiebt. Der Code läuft ja. Kunden zahlen. Warum also anfassen?
Irgendwann geht es dann doch los. Ein Entwickler hat zwei ruhige Tage und räumt auf. Drei Wochen später weiß niemand mehr genau, was er geändert hat. Zwei Funktionen verhalten sich plötzlich anders. Und die eigentlichen Probleme bestehen weiter.
So läuft Refactoring in vielen Unternehmen ab. Der Grund ist selten mangelndes Können. Meistens fehlt schlicht eine Strategie. Dieser Artikel zeigt, wie Sie systematisch vorgehen. Mit klaren Schritten, messbaren Ergebnissen und ohne böse Überraschungen im Livebetrieb.
Was Refactoring bedeutet
Refactoring heißt: Sie verbessern die innere Struktur des Codes. Das Verhalten nach außen bleibt gleich. Die Software macht danach exakt dasselbe wie vorher. Sie ist nur leichter zu verstehen, zu testen und zu erweitern.
Das unterscheidet Refactoring von einem Rewrite, also einer kompletten Neuentwicklung. Beim Rewrite entsteht neue Software. Beim Refactoring bleibt die alte und wird Stück für Stück verbessert. Welche Variante wann passt, haben wir im Beitrag Refactoring oder Rewrite ausführlich beschrieben.
Wichtig ist der zweite Teil der Definition. Das Verhalten bleibt gleich. Ein Refactoring, das nebenbei Funktionen ändert, ist keins. Es ist ein Umbau ohne Netz.
Warum Refactoring ohne Plan scheitert
Legacy-Code entsteht über Jahre. Viele Hände, wechselnde Anforderungen, Zeitdruck. Das Ergebnis ist selten schön, aber es funktioniert. Dafür verdient es Respekt. Wer allerdings ohne Plan eingreift, tappt in drei typische Fallen.
Falle 1: Sie verbessern, was gerade auffällt
Ein Entwickler öffnet eine Datei und sieht zwanzig Dinge, die ihn stören. Also bessert er nach. Das fühlt sich produktiv an. Nur: Auffällig und wichtig sind zwei verschiedene Dinge. Die krumme Funktion, die seit 2015 niemand angefasst hat, kostet Sie nichts. Die unübersichtliche Stelle, die jede Woche geändert wird, kostet Sie jedes Mal Geld.
Falle 2: Abhängigkeiten brechen unbemerkt
Alter Code hat versteckte Verbindungen. Eine Funktion wird an zwölf Stellen aufgerufen, drei davon kennt niemand mehr. Wer sie ändert, ohne das zu wissen, produziert Fehler an ganz anderer Stelle. Gefunden werden diese Fehler oft erst Wochen später. Dann ist die Verbindung zur Ursache längst vergessen. Die Fehlersuche beginnt bei null.
Falle 3: Detailpflege statt Kernproblem
Variablennamen aufräumen, Formatierung vereinheitlichen, kleine Funktionen umstellen: alles legitim. Aber wenn das eigentliche Problem eine Datenbankstruktur von 2009 ist, helfen hundert schönere Variablennamen wenig. Wer sich in Details verliert, verbraucht das Budget, bevor er beim Kern ankommt.
Die Folgen: Refactoring bekommt einen schlechten Ruf
Planloses Refactoring hat einen doppelten Preis. Erst zahlen Sie die Arbeitszeit. Dann zahlen Sie für die Fehler, die dabei entstehen. Im schlimmsten Fall zieht die Geschäftsführung eine bittere Konsequenz: Der alte Code wird gar nicht mehr angefasst.
Damit ist das Thema vom Tisch, aber das Problem nicht. Die technischen Schulden wachsen still weiter. Jede neue Funktion dauert länger als die letzte. Jeder Entwicklerwechsel wird riskanter. Und der nächste Anlauf wird teurer, weil sich inzwischen mehr angesammelt hat.
Die Refactoring-Strategie in fünf Schritten
Gegen all das hilft ein strukturiertes Vorgehen. Die folgenden fünf Schritte haben sich in der Praxis bewährt.
Schritt 1: Bestandsaufnahme
Bevor Sie etwas ändern, brauchen Sie ein ehrliches Bild vom Ist-Zustand. Welche Teile hat das System? Welche davon sind kritisch fürs Geschäft? Wo häufen sich die Fehler? Und wo trauen sich Entwickler kaum noch hinein?
Beziehen Sie dabei die Menschen ein, die täglich mit dem System arbeiten. Der Support weiß, wo es regelmäßig knirscht. Die Buchhaltung kennt die Auswertung, die jeden Monat von Hand korrigiert wird. Solche Hinweise stehen in keinem Quelltext, sind aber Gold wert für die Priorisierung.
Für diese Aufnahme reicht oft eine Woche. Nebenbei entsteht dabei der erste greifbare Nutzen: Wissen über das System wird aufgeschrieben. Wie Sie fehlende Dokumentation für Legacy-Software nachziehen, haben wir in einem eigenen Beitrag beschrieben.
Schritt 2: Hotspots priorisieren
Nicht jeder alte Code verdient Aufmerksamkeit. Entscheidend sind zwei Faktoren. Wie oft wird eine Stelle geändert? Und wie fehleranfällig ist sie? Code, auf den beides zutrifft, ist ein Hotspot. Dort lohnt sich Refactoring sofort. Code, den niemand anfasst, darf dagegen unschön bleiben. Das klingt hart, spart aber viel Geld.
Die Daten dafür liefert Ihre Versionsverwaltung kostenlos. Sie zeigt, welche Dateien am häufigsten geändert werden. Und welche Module die meisten Fehlerkorrekturen brauchten. Aus diesen zwei Listen entsteht Ihre Prioritätenfolge.
Schritt 3: Ein Sicherheitsnetz spannen
Refactoring ohne Tests ist Blindflug. Bevor Sie eine Stelle umbauen, sichern Sie ihr aktuelles Verhalten ab. Bei Legacy-Code fehlen automatisierte Tests oft komplett. Dann helfen sogenannte Charakterisierungstests. Diese Tests halten fest, was der Code heute tut, inklusive aller Eigenheiten. Sie bewerten nicht, ob dieses Verhalten richtig ist. Sie stellen nur sicher, dass es sich nicht unbemerkt ändert.
Das Sicherheitsnetz muss anfangs nicht das ganze System abdecken. Es reicht, die Stelle abzusichern, die Sie als Nächstes umbauen. So wächst die Testabdeckung genau dort, wo gearbeitet wird.
Schritt 4: Kleine Schritte, häufige Auslieferung
Der größte Fehler ist der große Wurf. Drei Monate umbauen und dann alles auf einmal ausliefern: Wenn danach etwas klemmt, wird die Fehlersuche zäh. Besser sind viele kleine Änderungen, die einzeln live gehen. Jede Änderung bleibt überschaubar. Jeder Fehler lässt sich schnell eingrenzen. Und Sie können jederzeit pausieren, wenn das Tagesgeschäft ruft.
Für größere Umbauten hat sich das Strangler-Fig-Pattern bewährt. Dabei wächst der neue Code am alten entlang, bis der alte verzichtbar ist. Das System bleibt dabei durchgehend in Betrieb.
Schritt 5: Fortschritt messen und berichten
Refactoring konkurriert im Budget immer mit neuen Funktionen. Deshalb braucht es Zahlen. Geeignete Kennzahlen sind zum Beispiel die Dauer einer typischen Änderung oder die Fehlerrate nach Releases. Auch die Einarbeitungszeit neuer Entwickler ist ein guter Indikator.
Ein Beispiel: Eine typische Anpassung dauerte früher fünf Tage. Heute sind es zwei. Solche Zahlen überzeugen jede Geschäftsführung. Wer Ergebnisse zeigen kann, bekommt auch das nächste Budget bewilligt.
Wichtig ist, die Messung vor dem ersten Umbau zu starten. Sonst fehlt später der Vergleichswert. Ein einfaches Ticketsystem reicht dafür völlig aus.
Wann Refactoring allein nicht reicht
Es gibt Systeme, bei denen Refactoring an Grenzen stößt. Etwa wenn die Basistechnologie keine Updates mehr bekommt. Oder wenn sich kein Entwickler mehr findet, der die Sprache beherrscht. Dann führt der Weg über eine schrittweise Ablösung oder eine Neuentwicklung. Auch das lässt sich planvoll und ohne Hauruck angehen. Wie das größere Gesamtbild aussieht, zeigt unser Leitfaden Technische Schulden abbauen, Schritt für Schritt.
Fazit: System schlägt Aktionismus
Refactoring Legacy Code funktioniert, wenn es geplant abläuft. Bestandsaufnahme, Hotspots, Sicherheitsnetz, kleine Schritte, messbare Ergebnisse. In dieser Reihenfolge. Was sich über Jahre aufgebaut hat, verschwindet nicht in einem Sprint. Aber es lässt sich Stück für Stück abtragen, ohne das Tagesgeschäft zu gefährden.
Falls Sie nicht wissen, wo Sie anfangen sollen: Genau dafür gibt es die Bestandsaufnahme. Wir machen sie regelmäßig für Systeme, deren letzte Betreuer lange weg sind. Sprechen Sie uns an. Das Erstgespräch ist kostenlos.
