Zum Inhalt springen
Menü

Refactoring - Code verbessern, ohne Verhalten zu ändern

Kurz gesagt

Refactoring ist das gezielte Umbauen der inneren Struktur von Code, ohne sein nach außen sichtbares Verhalten zu ändern. Ziel ist Code, der sich leichter lesen und ändern lässt und weniger technische Schuld trägt, also weniger aufgeschobene Aufräumarbeit. Automatisierte Tests sichern dabei ab, dass nach dem Umbau alles funktioniert wie vorher.

Fragen zu diesem Thema in Ihrem Projekt?

Erstgespräch buchen

Kategorie SoftwareentwicklungLesezeit etwa 2 Minuten5 Abschnitte

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.

Verwandte Themen

Weitere Glossarbegriffe

Zurück zum Glossar

Was wollen Sie bauen?

30 Minuten, kostenlos, per Video. Wir sprechen über Ihr Vorhaben und geben Ihnen Feedback, wie wir es lösen würden.