Zum Inhalt springen
≈ 1 minNeuCode-QualitätArchitektur

Refactoring vs. Redesign vs. Rewriting vs. Modernisierung

Vier Begriffe für „bestehende Software verbessern“, die sich darin unterscheiden, wie tief man eingreift und ob sich das Verhalten ändern darf.

In 30 Sekunden

  1. 01

    Refactoring verbessert die innere Struktur in kleinen Schritten, das Verhalten bleibt exakt gleich.

  2. 02

    Redesign baut die Architektur oder das Design größerer Teile um, Rewriting baut alles neu.

  3. 03

    Modernisierung ist das Ziel, ein Altsystem zukunftsfähig zu machen, und nutzt dafür die anderen drei.

Wie tief greifst du ein?

01Refactoring
02Redesign
03Modernisierung
04Rewriting
← kleiner Eingrifftotaler Neubau →

01Refactoring

Struktur verbessern, ohne das Verhalten zu ändern – Methode extrahieren, umbenennen, Duplikate entfernen.

  • Verhalten: identisch
  • Umfang: Minuten bis Tage
  • Risiko: niedrig (mit Tests)

02Redesign

Architektur oder Design eines Teils neu schneiden – neues Datenmodell, Modul aufteilen, neue UI.

  • Verhalten: teils angepasst
  • Umfang: Wochen
  • Risiko: mittel

03Modernisierung

Altsystem auf aktuelle Plattform oder Technik bringen – Cloud, neues Framework, Container.

  • Verhalten: meist gleich
  • Umfang: Monate
  • Risiko: mittel bis hoch

04Rewriting

Von vorn neu implementieren, oft mit neuer Sprache oder neuem Stack.

  • Verhalten: neu (Ziel: gleich)
  • Umfang: Monate bis Jahre
  • Risiko: hoch
Modernisierung ist eher ein Ziel als eine Technik – erreicht wird sie per Refactoring, Redesign oder Rewrite.

Das Beispiel im Code

Vorher

def total(o):
    t = 0
    for i in o["items"]:
        t += i["price"] * i["qty"]
    if o["vip"]:
        t = t * 0.9
    return t

Nach dem Refactoring

VIP_DISCOUNT = 0.9

def order_total(order: Order) -> Decimal:
    subtotal = sum(i.price * i.qty for i in order.items)
    return subtotal * VIP_DISCOUNT if order.is_vip else subtotal

Gleiches Ergebnis, aber sprechende Namen, Typen und eine benannte Konstante. Genau das ist Refactoring – und es ist nur sicher, wenn Tests das Verhalten absichern.

Modernisieren ohne Big Bang: Strangler Fig

/rechnungen/kunden · /aufträgeClientsFassadeProxy / API GatewayAltsystemschrumpftNeues Systemwächst
Funktion für Funktion wird umgeleitet, bis das Altsystem nichts mehr zu tun hat und abgeschaltet wird – wie eine Würgefeige, die ihren Wirtsbaum ersetzt.

Merksatz

„So klein wie möglich, so groß wie nötig – erst refactoren, neu schreiben nur mit sehr gutem Grund.“

Selbsttest

Erst selbst überlegen, dann aufklappen.

01Du benennst Methoden um und extrahierst eine Klasse – Tests bleiben grün. Was hast du gemacht?

Refactoring. Die Struktur hat sich verbessert, das beobachtbare Verhalten nicht.

02Warum gilt ein kompletter Rewrite als riskant?

Das alte System enthält jahrelang gesammeltes Wissen und Bugfixes. Beim Neuschreiben gehen diese verloren, während das alte System parallel weiter gepflegt werden muss.

03Wie modernisiert man schrittweise statt mit Big Bang?

Mit dem Strangler-Fig-Pattern – eine Fassade leitet Funktion für Funktion auf das neue System um, bis das alte abgeschaltet werden kann.

Weiter in Grundlagen

Software-Engineering Best Practices