Clean Code #9: Refactoring — Kontinuierliche Verbesserung

Refactoring ist keine einmalige Aktion — es ist eine Haltung. Code wird nicht einmal geschrieben und dann für immer belassen. Er wird kontinuierlich verbessert, Stück für Stück, bei jeder Berührung.

Was ist Refactoring?

Refactoring bedeutet: Die interne Struktur des Codes verbessern, ohne sein äußeres Verhalten zu ändern. Nach dem Refactoring tut der Code exakt dasselbe — nur besser organisiert, lesbarer, wartbarer.

Das ist der entscheidende Punkt: Refactoring ändert nicht was der Code tut, sondern wie er es tut.

Die Boy-Scout-Regel

"Hinterlasse den Code immer sauberer, als du ihn vorgefunden hast."

Jedes Mal, wenn Sie eine Datei öffnen, um einen Bug zu fixen oder ein Feature einzubauen — verbessern Sie eine Kleinigkeit. Benennen Sie eine Variable besser. Extrahieren Sie eine Methode. Entfernen Sie einen toten Code-Block. Diese kleinen Verbesserungen akkumulieren sich über die Zeit zu dramatischen Qualitätssteigerungen.

Code Smells erkennen

Martin Fowler definiert "Code Smells" als Hinweise, dass Refactoring nötig sein könnte:

• •Long Method: Methode mit mehr als 20 Zeilen → Extrahieren
• •Large Class: Klasse mit zu vielen Verantwortlichkeiten → Aufteilen
• •Feature Envy: Methode nutzt mehr Daten einer anderen Klasse als der eigenen → Verschieben
• •Data Clumps: Gleiche Parametergruppe taucht mehrfach auf → Parameter-Objekt
• •Primitive Obsession: Überall strings statt eigener Typen → Value Objects
• •Switch Statements: Gleiche switch/if-Kette an mehreren Stellen → Polymorphismus
• •Shotgun Surgery: Eine Änderung betrifft viele Klassen → Konsolidieren

Sichere Refactoring-Schritte

Extract Method

Der häufigste und sicherste Refactoring-Schritt:

// Vorher
void ProcessOrder(Order order) {
    // validate
    if (order.Items.Count == 0) throw new EmptyOrderException();
    if (order.Customer == null) throw new NoCustomerException();
    
    // calculate
    var total = order.Items.Sum(i => i.Price * i.Qty);
    var tax = total * 0.19m;
    // ... 50 weitere Zeilen
}

// Nachher
void ProcessOrder(Order order) {
    ValidateOrder(order);
    var totals = CalculateTotals(order);
    PersistOrder(order, totals);
    NotifyCustomer(order);
}

Rename

Der am meisten unterschätzte Schritt. Ein besserer Name kann das Verständnis einer ganzen Codebasis verbessern.

Extract Class

Wenn eine Klasse zu viel tut: Identifizieren Sie eine zusammengehörige Gruppe von Feldern und Methoden und extrahieren Sie sie in eine eigene Klasse.

Wann refactoren?

• •Vor dem Hinzufügen eines Features: Räumen Sie auf, damit das neue Feature sauber reinpasst
• •Beim Bug-Fixing: Wenn der Bug durch schlechte Struktur entstanden ist
• •Bei Code Reviews: Wenn der Reviewer Verbesserungen sieht
• •Nicht: Als eigenes Projekt "alles aufräumen" — das scheitert fast immer

Die Voraussetzung: Tests

Refactoring ohne Tests ist wie Trapez ohne Netz. Sie brauchen automatisierte Tests, die bestätigen, dass sich das Verhalten nicht geändert hat. Ohne Tests ist jedes Refactoring ein Glücksspiel.

Wenn keine Tests existieren: Schreiben Sie zuerst Tests für den bestehenden Code (Characterization Tests), dann refactoren Sie.

Technische Schulden managen

Technische Schulden entstehen, wenn kurzfristige Lösungen langfristige Probleme schaffen. Wie finanzielle Schulden haben sie Zinsen: Je länger man wartet, desto teurer wird die Rückzahlung.

Die Lösung ist nicht, alle Schulden auf einmal abzuzahlen. Es ist, bei jeder Änderung ein Stück zu tilgen — die Boy-Scout-Regel, konsequent angewandt.

Fazit

Refactoring ist das, was guten Code von großartigem Code unterscheidet. Es erfordert Disziplin, Tests und die Überzeugung, dass Code ein lebendiges Artefakt ist, das Pflege braucht. Nicht einmal im Jahr beim "großen Aufräumen", sondern jeden Tag, bei jedem Commit, Stück für Stück.

Das war der letzte Artikel der Serie. Alle neun Clean-Code-Indikatoren zusammen bilden das Fundament professioneller Softwareentwicklung. Setzen Sie sie um — nicht alle auf einmal, sondern einen nach dem anderen.