Refactoring

Programme bestehen aus Text, den Menschen geschrieben haben: aus Anweisungen, die dem Computer sagen, was er tun soll. Dieser Text wächst über Jahre, oft von vielen verschiedenen Leuten geschrieben. Irgendwann ist er unübersichtlich: dieselbe Berechnung steht an fünf Stellen, Namen passen nicht mehr zum Inhalt, ein Abschnitt ist tausend Zeilen lang. Refactoring heißt, diesen Text umzubauen und zu ordnen, ohne das Verhalten des Programms zu verändern. Ein Nutzer merkt hinterher keinen Unterschied. Für die Entwickler ist der Unterschied groß, weil sie sich wieder zurechtfinden.

Warum Software langsam unbenutzbar wird

In der Softwareentwicklung spricht man von technischen Schulden. Damit ist gemeint: Wer schnell und schlampig arbeitet, borgt sich Zeit von der Zukunft. Jede neue Funktion dauert dann etwas länger, weil man erst verstehen muss, was schon da ist. Am Anfang sind das Minuten, nach Jahren Wochen.

Refactoring ist die Rückzahlung dieser Schulden. Es bringt am Tag selbst keinen sichtbaren Nutzen, kein neues Feature, keinen neuen Kunden. Deshalb wird es oft aufgeschoben. Der Preis dafür zeigt sich später: Teams, die eine völlig verbaute Software erben, brauchen für kleine Änderungen absurd lange. Manche Unternehmen schreiben ihre Software irgendwann komplett neu, was meist teurer wird als geplant.

Wichtig ist die Abgrenzung: Refactoring ist keine Fehlerbehebung und keine Erweiterung. Wer beim Aufräumen gleichzeitig einen Fehler behebt, weiß hinterher nicht, welche Änderung das Problem verursacht hat, falls etwas kaputtgeht. Gute Entwickler trennen diese Schritte bewusst.

Umbauen, ohne das Haus einzureißen

Der Vergleich mit einem Haus trägt hier gut. Man verlegt Leitungen neu, reißt eine Zwischenwand heraus, sortiert den Keller. Die Adresse bleibt gleich, die Bewohner können weiter darin leben. Genau so arbeitet Refactoring in vielen kleinen Schritten statt in einem großen Sprung.

Typische Handgriffe sind einfach zu beschreiben. Ein langer Abschnitt wird in mehrere kleine mit sprechenden Namen zerlegt. Fünfmal kopierter Code wird zu einer Stelle zusammengefasst, die alle fünf aufrufen. Eine Variable, die « tmp2 » heißt, bekommt den Namen « restguthaben ». Nichts davon ist spektakulär, aber die Summe entscheidet, ob ein Programm nach zehn Jahren noch wartbar ist.

Damit das sicher bleibt, braucht man automatische Tests. Das sind kleine Zusatzprogramme, die prüfen, ob die Software noch die erwarteten Ergebnisse liefert. Nach jedem Umbauschritt lässt man sie laufen. Schlagen sie an, nimmt man die letzte Änderung zurück. Ohne solche Tests ist Refactoring ein Blindflug, und dann wird aus Aufräumen schnell ein neuer Fehler.

Refactoring in Entwicklerteams und in KI-Werkzeugen

Wer in einem Softwareteam arbeitet, hört das Wort täglich. Es steht in Aufgabenlisten, in Begründungen für Verzögerungen und in Diskussionen darüber, wie viel Zeit ein Team für Aufräumarbeiten bekommt. Viele Teams reservieren einen festen Anteil, etwa zehn bis zwanzig Prozent ihrer Arbeitszeit. Entwicklungsumgebungen, also die Programme, in denen Code geschrieben wird, haben eingebaute Refactoring-Funktionen. Ein Klick benennt eine Variable im ganzen Projekt um.

In den letzten Jahren ist Refactoring auch ein Verkaufsargument für KI-Werkzeuge geworden. Programmierassistenten wie GitHub Copilot oder Cursor schlagen vor, wie man unübersichtliche Abschnitte zerlegt, und setzen es auf Wunsch selbst um. Bei kleinen, klar begrenzten Änderungen funktioniert das oft gut.

Ein verbreiteter Irrtum ist allerdings, dass KI das Problem damit erledigt. Ein Sprachmodell sieht nur einen Ausschnitt des Projekts und kennt selten die Gründe, warum eine Stelle merkwürdig aussieht. Manchmal steckt dahinter eine bewusste Entscheidung oder ein Sonderfall aus der Praxis. Wer Vorschläge ungeprüft übernimmt, produziert sauber aussehenden Code mit neuen Fehlern. Die Tests bleiben also auch mit KI die eigentliche Absicherung.