Refactoring - Code verbessern, ohne Verhalten zu ändern
Refactoring ist die gezielte Verbesserung der internen Struktur von Code, ohne sein äußeres Verhalten zu ändern. Ziel ist besser lesbarer, wartbarer und erweiterbarer Code - ohne dass sich für den Nutzer etwas ändert. Automatisierte Tests bilden das Sicherheitsnetz, das absichert, dass das Verhalten gleich bleibt. Refactoring grenzt sich klar von einem Rewrite ab: Es baut in kleinen, sicheren Schritten um, statt neu zu beginnen.
Refactoring ist die gezielte Verbesserung der internen Struktur von Software, ohne ihr äußeres, für den Nutzer sichtbares Verhalten zu verändern. Der Begriff wurde durch Martin Fowler und sein gleichnamiges Buch geprägt. Die zentrale Definition lautet sinngemäß: Refactoring ist eine Änderung am inneren Aufbau von Code, die ihn leichter verständlich und billiger änderbar macht, ohne sein beobachtbares Verhalten zu ändern.
Was Refactoring ist - und was nicht
Der entscheidende Punkt ist die Trennung zweier Dinge, die oft vermischt werden: das Verändern von Verhalten (neue Funktionen, Bugfixes) und das Verbessern der Struktur. Beim Refactoring wird ausschließlich die Struktur verbessert - der Code tut hinterher exakt dasselbe wie vorher, nur ist er sauberer aufgebaut. Wer während eines Refactorings zusätzlich neue Funktionen einbaut, betreibt kein Refactoring mehr, sondern vermischt zwei Aufgaben und erhöht das Risiko.
Warum man refactored
- Lesbarkeit: Code wird häufiger gelesen als geschrieben. Klar strukturierter Code spart bei jeder späteren Änderung Zeit.
- Wartbarkeit: Gut strukturierter Code lässt sich sicherer und schneller anpassen.
- Abbau technischer Schuld: Refactoring ist das wichtigste Werkzeug, um angesammelte technische Schuld abzubauen.
- Vorbereitung für Änderungen: Oft refactored man gezielt eine Stelle, bevor man dort eine neue Funktion einbaut - erst aufräumen, dann erweitern.
Tests als Sicherheitsnetz
Refactoring ist nur dann sicher, wenn man beweisen kann, dass sich das Verhalten nicht geändert hat. Genau dafür sind automatisierte Tests da. Sie bilden das Sicherheitsnetz: Vor dem Umbau laufen die Tests grün, nach jedem kleinen Umbauschritt werden sie erneut ausgeführt. Bleiben sie grün, ist das Verhalten unverändert. Ohne diese Absicherung wird Refactoring zum Blindflug - deshalb ist der Aufbau einer guten Testabdeckung fast immer der erste Schritt, bevor man einen veralteten Bereich umbaut.
Charakteristisch ist außerdem die Arbeit in vielen kleinen, jederzeit lauffähigen Schritten statt in einem großen Umbau. Nach jedem Schritt ist das System wieder voll funktionsfähig.
Abgrenzung zum Rewrite
Refactoring wird oft mit einem kompletten Neuschreiben (Rewrite) verwechselt, ist aber das Gegenteil. Beim Rewrite wirft man den bestehenden Code weg und beginnt neu - das ist riskant, teuer und verliert leicht das über Jahre eingeflossene Fachwissen. Refactoring dagegen bewahrt den bestehenden Code und verbessert ihn in kleinen, sicheren Schritten. In der Praxis ist schrittweises Refactoring - oft in Kombination mit dem Strangler-Pattern - fast immer der risikoärmere Weg als ein Rewrite und ein Kernbestandteil jeder Legacy-Modernisierung.
Refactoring bei Elasticbrains
Bei Elasticbrains betreiben wir Refactoring diszipliniert und abgesichert: erst Tests als Netz, dann Umbau in kleinen Schritten, ohne das Verhalten zu ändern. So verbessern wir bestehenden Code, statt ihn riskant neu zu schreiben. Refactoring ist fester Bestandteil unserer Legacy-Modernisierung und unserer Wartung und Weiterentwicklung.
Weitere Glossarbegriffe
Strangler-Pattern - Altsysteme schrittweise ablösen
Das Strangler-Pattern (Strangler Fig Pattern) ist ein Vorgehen, um ein Altsystem schrittweise durch ein neues zu ersetzen, während es weiterläuft. Neue Komponenten übernehmen nach und nach einzelne Funktionen; das Altsystem "verdorrt", bis es abgeschaltet werden kann. Der große Vorteil gegenüber einem Big-Bang-Neubau: geringes Risiko, kontinuierlicher Nutzen und jederzeit ein lauffähiges System. Der Begriff geht auf Martin Fowler zurück.
Legacy-Modernisierung - Altsysteme zukunftsfähig machen
Legacy-Modernisierung bezeichnet den planvollen Umbau bestehender, in die Jahre gekommener Software, damit sie wartbar, sicher und erweiterbar bleibt. Statt eines riskanten Komplettneubaus (Big Bang) werden veraltete Technik, Wartungsstau und fehlende Schnittstellen schrittweise abgebaut - oft mit dem Strangler-Pattern. Ziel ist ein System, das weiterhin den Geschäftsbetrieb trägt, aber neue Anforderungen wie Integrationen oder KI-Funktionen aufnehmen kann.
Technische Schuld - was sie kostet und wie man sie abbaut
Technische Schuld (Technical Debt) beschreibt die zukünftigen Mehrkosten, die entstehen, wenn eine schnelle, unsaubere Lösung heute gewählt wird statt einer sauberen. Wie bei einem Kredit fallen "Zinsen" an: Jede weitere Änderung wird langsamer und riskanter. Ursachen sind Zeitdruck, fehlende Tests oder veraltete Technik. Abbauen lässt sich technische Schuld durch gezieltes Refactoring, Tests und kontinuierliche Pflege - nicht durch einen einmaligen Kraftakt.