Refactoring - Code verbessern, ohne Verhalten zu ändern
Refactoring verbessert gezielt die interne Struktur von Code, ohne sein äußeres Verhalten zu ändern - für lesbaren, wartbaren Code, abgesichert durch Tests.
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
Technische Schuld - was sie kostet und wie man sie abbaut
Technische Schuld beschreibt die Mehrkosten einer schnellen, unsauberen Lösung: Wie ein Kredit fallen Zinsen an. Abbau durch gezieltes Refactoring und Tests.
Legacy-Modernisierung - Altsysteme zukunftsfähig machen
Legacy-Modernisierung ist der planvolle Umbau alter Software, damit sie wartbar, sicher und erweiterbar bleibt - schrittweise statt Big Bang, oft per Strangler.
API (Application Programming Interface)
Eine Schnittstelle, die definiert, wie verschiedene Softwarekomponenten miteinander kommunizieren.