Mit Google fortfahren
Refactoring: Code sicher verbessern
Beim Refactoring ordnest du bestehenden, funktionierenden Code neu, ohne sein beobachtbares Verhalten zu verändern. Der Code soll danach leichter zu verstehen, zu testen, zu warten und zu erweitern sein.
Auf dieser Seite lernst du, Refactoring von Funktionsänderungen abzugrenzen, Code-Smells zu erkennen und eine Umstrukturierung mit kleinen Schritten und Tests abzusichern.
Hake ab, was du schon kannst — und komm am Ende hierher zurück!
Was zählt als Refactoring?
Refactoring
Refactoring ist die manuelle oder automatisierte Verbesserung der internen Struktur vorhandener Software. Für die Nutzenden bleibt das beobachtbare Verhalten gleich.
Beobachtbares Verhalten umfasst zum Beispiel Ausgaben, Rückgabewerte und Reaktionen auf Eingaben. Wenn du eine neue Funktion ergänzt, ein fachliches Ergebnis änderst oder einen Fehler im sichtbaren Verhalten behebst, ist diese Änderung selbst kein Refactoring.
Typische Refactorings sind:
- eine Variable oder Methode aussagekräftig umbenennen;
- eine lange Methode in kleinere Methoden zerlegen;
- duplizierten Code zusammenführen;
- zusammengehörige Daten und Operationen in eine passende Klasse verschieben;
- ungenutzten Code entfernen;
- Verantwortlichkeiten zwischen Klassen neu verteilen.
Refactoring verändert, wie der Code aufgebaut ist – nicht, was das Programm nach außen tut.
Woran erkennst du Refactoring-Bedarf?
Ein Code-Smell ist ein auffälliges Merkmal, das auf ein tiefer liegendes Strukturproblem hinweisen kann. Es beweist noch nicht, dass der Code falsch ist.
Code-Smell
Ein Code-Smell ist ein Warnzeichen für schwer verständlichen, schlecht gegliederten oder unnötig aufwendig änderbaren Code.
Häufige Warnzeichen sind:
- unklare Namen wie
x,data2oderdoIt; - lange Methoden mit mehreren Aufgaben;
- verschachtelte Bedingungen und Schleifen;
- Copy-and-Paste-Duplikate;
- lange Parameterlisten;
- Klassen mit unklaren oder zu vielen Verantwortlichkeiten;
- ungenutzter Code;
- veraltete Kommentare, die nicht mehr zum Code passen.
Auch Messwerte wie hohe Verschachtelungstiefe, geringe Testabdeckung oder sehr große Dateien können auf problematische Stellen hinweisen. Sie sind jedoch nur Hinweise: Erst die Analyse des konkreten Codes zeigt, ob und wie du ihn verbessern solltest.
Wie sieht ein vollständiges Refactoring aus?
Eine Variable mit wechselnder Bedeutung erschwert das Lesen. Im folgenden Beispiel steht x zuerst für den Umfang und danach für die Fläche eines Rechtecks.
Vorher:
double x = 2 * (breite + hoehe);System.out.println("Umfang: " + x);x = breite * hoehe;System.out.println("Fläche: " + x);
Schritt 1: Bedeutungen erkennen. Die Variable speichert zwei verschiedene Größen.
Schritt 2: Sprechende Variablen einführen.
double umfang = 2 * (breite + hoehe);System.out.println("Umfang: " + umfang);double flaeche = breite * hoehe;System.out.println("Fläche: " + flaeche);
Schritt 3: Verhalten vergleichen. Für breite = 4 und hoehe = 3 geben beide Fassungen Umfang: 14 und Fläche: 12 aus.
Das Verhalten bleibt gleich, aber die Namen zeigen nun unmittelbar, welche Bedeutung die Werte haben.
Man könnte die Variablen auch entfernen und beide Ausdrücke direkt ausgeben. Das wäre kürzer, aber nicht unbedingt verständlicher: Die Bedeutungen wären weniger deutlich benannt und die Zwischenwerte im Debugger schlechter zu beobachten. Refactoring bedeutet deshalb nicht automatisch „möglichst wenig Code“.
Bei einer größeren Weiterentwicklung könnten die Berechnungen in Methoden wie umfang() und flaeche() einer Klasse Rechteck verschoben werden. Dann liegt zusammengehörige Rechtecklogik an einem Ort.
Wie gehst du sicher vor?
Refactoring kann trotz guter Absicht neue Fehler verursachen. Deshalb arbeitest du in kleinen, überprüfbaren Schritten:
- Ausgangszustand prüfen: Stelle sicher, dass der vorhandene Code funktioniert und die Tests erfolgreich sind.
- Schutz bewerten: Prüfe, ob Tests gerade den betroffenen Bereich und sein wichtiges Verhalten abdecken.
- Ziel festlegen: Benenne das konkrete Strukturproblem, etwa einen unklaren Namen oder duplizierten Code.
- Kleine Änderung durchführen: Nimm nur eine überschaubare Umstrukturierung vor.
- Tests erneut ausführen: Bei einem Fehlschlag untersuchst du zuerst die letzte Änderung.
- Schritte wiederholen: Zerlege ein großes Refactoring in mehrere kleine Transformationen.
- Gesamtergebnis prüfen: Führe abschließend die relevanten Tests erneut aus und kontrolliere die Änderung im Zusammenhang.
Automatisierte IDE-Funktionen können beispielsweise Verwendungen eines Symbols finden und sicher umbenennen. Trotzdem musst du Vorbedingungen, Ergebnis und Tests prüfen. Auch automatisierte oder KI-erzeugte Vorschläge sind nicht ungeprüft verlässlich.
Tests vergleichen nur die Fälle, die sie tatsächlich ausführen. Eine erfolgreiche Testsuite senkt deshalb das Regressionsrisiko, beweist aber nicht für alle möglichen Eingaben, dass das Verhalten vollständig erhalten blieb.
Welche Technik passt zu welchem Problem?
| Beobachtung | Passendes Refactoring | Beabsichtigte Wirkung |
|---|---|---|
| Ein Name verrät seine Bedeutung nicht | Umbenennen | Absicht sichtbar machen |
| Eine Methode erledigt mehrere Aufgaben | Methode extrahieren | Aufgaben trennen und benennen |
| Mehrere Stellen enthalten gleiche Logik | Gemeinsame Logik extrahieren | Duplikation verringern |
| Gemeinsamer Code liegt in mehreren Unterklassen | Pull-up | Gemeinsamkeit in einer Oberklasse bündeln |
| Spezielle Logik liegt in einer allgemeinen Oberklasse | Push-down | Logik der passenden Unterklasse zuordnen |
| Eine sehr kurze Methode verdeckt mehr, als sie erklärt | Methode inline setzen | unnötige Umleitung entfernen |
| Code wird nicht mehr verwendet | Toten Code entfernen | Ablenkung und Pflegeaufwand verringern |
Die Tabelle ist eine Entscheidungshilfe, kein Automatismus. Du musst zuerst verstehen, welche Aufgabe der Code erfüllt und welche Abhängigkeiten betroffen sind.
Vertiefung: Große Änderungen schrittweise umsetzen
Bei einem umfangreichen Refactoring kann Branch by Abstraction helfen. Eine Abstraktionsschicht erlaubt vorübergehend zwei Implementierungen. Teile des Systems werden schrittweise auf die neue Struktur umgestellt, während die übrigen Teile weiter funktionieren.
Refactoring hat außerdem Grenzen. Wenn ein System grundlegende Sicherheits-, Skalierungs- oder Technologieprobleme besitzt, kann eine umfassendere Softwaremodernisierung nötig sein. Gezielte Leistungsoptimierung ist ebenfalls ein anderes Ziel, weil sie beobachtbare Laufzeiteigenschaften verändern soll.
Karteikasten
Überlege zuerst selbst und drehe die Karte anschließend zum Prüfen um.
Alles auf einen Blick
- Refactoring
- Ziel: verständliche und wartbare Struktur
- Grenze: beobachtbares Verhalten bleibt gleich
- Hinweise: Code-Smells und auffällige Metriken
- Techniken: umbenennen, extrahieren, verschieben, Duplikate entfernen
- Absicherung: Tests, kleine Schritte und Ergebnisprüfung
- Risiko: Tests und Werkzeuge geben keine vollständige Garantie
Abschluss-Check
Refactoring ist gelungen, wenn der Code nachvollziehbarer strukturiert ist, sein beobachtbares Verhalten erhalten blieb und du diese Erhaltung mit passenden Prüfungen begründet beurteilen kannst.