Legacy Code Refactoring: Eine Operation am offenen Herzen

Das Erbe der Vergangenheit – Wenn Code zur tickenden Zeitbombe wird

Kennen Sie diesen einen Code-Block, bei dem ein Kommentar steht: "Bitte nicht anfassen, sonst stürzt alles ab"? Genau darum kümmern wir uns.

Jeder Entwickler, der schon einmal ein historisch gewachsenes Projekt übernommen hat, kennt dieses Gefühl. Man öffnet das Repository, navigiert durch die Ordnerstruktur und plötzlich blickt man in den Abgrund. Zehntausende Zeilen Code, geschrieben von Entwicklern, die das Unternehmen vor Jahren verlassen haben. Keine Dokumentation, keine Unit-Tests, dafür aber unzählige Workarounds, die mit virtuellle Klebeband und viel Hoffnung zusammengehalten werden.

Willkommen in der Welt des Legacy Codes.

In unserem Fall sprechen wir von einem zehn Jahre alten Online-Shop. Vor einer Dekade war diese E-Commerce-Plattform der Stolz des Unternehmens. Sie generierte Millionenumsätze, lief stabil und war das digitale Aushängeschild. Doch zehn Jahre sind in der Softwareentwicklung eine geologische Epoche. Was damals "State of the Art" war, ist heute ein monolithisches Monstrum. Die Ladezeiten des Shops krochen mittlerweile bei schmerzhaften drei Sekunden herum. Jeder Klick auf "In den Warenkorb" fühlte sich an wie ein Glücksspiel.

Das eigentliche Problem war jedoch nicht nur die Performance, sondern die völlige Handlungsunfähigkeit des Entwicklerteams. Das Phänomen der "technischen Schulden" (Technical Debt) hatte seinen Zinseszins erreicht. Wenn das Marketing-Team ein einfaches, neues Feature forderte – etwa ein neues Rabattsystem –, brach im IT-Büro kalter Schweiß aus. Eine kleine Änderung in der Preisberechnung führte unweigerlich dazu, dass plötzlich die Bestandsanzeige im Warenkorb nicht mehr funktionierte. Der Code war so stark miteinander verwoben (der berüchtigte Spaghetti-Code), dass das Isolieren von Fehlern unmöglich wurde.

Die Angst vor dem "Delete"-Button war allgegenwärtig. Niemand traute sich mehr, alten, ungenutzten Code zu löschen, weil niemand mit Sicherheit sagen konnte, ob nicht doch noch ein versteckter Cronjob nachts um drei Uhr genau diese eine Funktion aufruft. Der Shop befand sich im digitalen Wachkoma.

Es war klar: Ein einfacher Patch reicht hier nicht mehr. Wir standen vor einer Operation am offenen Herzen. Der Shop musste weiterlaufen, Bestellungen mussten weiterhin verarbeitet werden, aber die gesamte Architektur unter der Haube musste ausgetauscht werden.

Wer sich an dieser Stelle fragt, wie man ein solches Mammutprojekt überhaupt strukturiert angeht, ohne den laufenden Betrieb zu gefährden, dem möchte ich direkt einen tiefen Einblick empfehlen. In der Serie Veraltete Web-Projekte schrittweise retten wird genau diese hochkomplexe Methodik detailliert und technisch fundiert durchleuchtet.

Wir wussten: Der Weg von drei Sekunden Ladezeit hin zu den anvisierten 300 Millisekunden würde schmerzhaft werden. Wir mussten den Code sezieren, verstehen und neu schreiben.

Software-Archäologie – Die Suche nach dem toten Code

Wenn man sich für ein Legacy Code Refactoring entscheidet, ist der allererste Impuls des Teams meistens falsch. Der natürliche Reflex eines jeden Entwicklers ist es, den alten, fehleranfälligen Code komplett abzureißen und auf einem grünen Feld völlig neu anzufangen (der berühmt-berüchtigte "Big Bang Rewrite"). Doch genau dieser Ansatz führt in 99 Prozent der Fälle in eine wirtschaftliche und technische Katastrophe. Man unterschätzt massiv, wie viel implizites Geschäftswissen in den alten, hässlichen Code-Zeilen steckt.

Stattdessen beginnt die professionelle Modernisierung nicht mit dem Schreiben neuer Funktionen, sondern mit einer Tätigkeit, die wir intern gerne als "Software-Archäologie" bezeichnen.

Bei unserem zehn Jahre alten E-Commerce-Shop glich diese erste Phase einer Expedition in dunkle, vergessene Höhlen. Wir mussten herausfinden, was das System tatsächlich tut, im Gegensatz zu dem, was die veraltete Dokumentation behauptete. Es ist ein bekanntes Phänomen bei historisch gewachsenen Projekten: Der Code lügt nie, die Dokumentation fast immer.

Wir starteten mit einer knallharten Bestandsaufnahme. Bevor wir auch nur eine einzige Zeile Code veränderten, implementierten wir umfassendes Logging und Monitoring in das alte System. Wir wollten sehen, welche Endpunkte und Datenbankabfragen im Live-Betrieb wirklich aufgerufen werden. Die Ergebnisse waren ebenso faszinierend wie erschreckend.

Da gab es beispielsweise eine hochkomplexe, hunderte Zeilen umfassende Logik zur Anbindung eines Zahlungsanbieters, der bereits vor fünf Jahren insolvent gegangen war. Diese tote Schnittstelle wurde bei jedem einzelnen Checkout-Prozess vom Server geladen, initialisiert, auf Fehler geprüft und dann nutzlos übersprungen. Es war ein unsichtbarer Bremsklotz, der bei jeder Bestellung völlig sinnlos wertvolle Millisekunden der Ladezeit fraß.

Ebenso fanden wir tief vergrabene Rabatt-Regeln für Jubiläumsaktionen aus dem Jahr 2018, die noch immer bei jedem Seitenaufruf evaluiert wurden. Solche Altlasten sind die Hauptursache dafür, warum Systeme im Laufe der Zeit immer träger werden.

Durch diese archäologische Analyse – das bloße Beobachten der Datenströme – stellten wir fest, dass fast 40 Prozent der gesamten Code-Basis schlichtweg toter Code war. Code, der Ressourcen band, die Fehlersuche erschwerte und Entwickler bei der Einarbeitung verwirrte, aber für den Umsatz des Shops keinerlei Relevanz mehr hatte.

Bevor das eigentliche Legacy Code Refactoring in die Tiefe gehen konnte, bestand unsere erste chirurgische Maßnahme also schlicht im Löschen. Wir isolierten diese ungenutzten Bereiche und entfernten sie schrittweise. Das Entfernen von totem Code ist einer der befriedigendsten Momente in der Softwareentwicklung. Die Architektur wird sofort schlanker, das System atmet spürbar auf und die Testabdeckung (Test Coverage) steigt mathematisch an, ohne dass man einen einzigen neuen Test geschrieben hat, weil der Gesamtnenner des Codes kleiner wird.

Doch das Löschen offensichtlicher Altlasten war nur das Aufwärmprogramm. Nun standen wir vor dem verbleibenden, hochaktiven und extrem verworrenen Kern des Online-Shops. Die Preisberechnung, die Lagerbestandsführung und das Kunden-Login waren ein einziger, gigantischer Monolith.

Um diesen aufzubrechen, ohne den laufenden Verkauf zu stoppen, brauchten wir eine bewährte Strategie aus der Pflanzenwelt.

Das Würgefeigen-Muster – Wie man ein System im laufenden Betrieb austauscht

Nachdem wir im vorherigen Schritt den toten Code unseres zehn Jahre alten Online-Shops entfernt hatten, standen wir vor dem eigentlichen Endgegner: dem Kernsystem. Die Preisberechnung, die Benutzerverwaltung und der Checkout-Prozess waren so eng miteinander verstrickt, dass man sie nicht einfach abschalten konnte. Der Shop machte schließlich jeden Tag Umsatz. Ein klassischer "Big Bang" – also das alte System an einem Freitagabend komplett abzuschalten und am Montagmorgen ein völlig neues System hochzufahren – war dem Management viel zu riskant. Zu Recht, denn solche Mammut-Releases enden historisch gesehen oft in epischen Ausfällen.

Die Lösung für dieses Problem beim Legacy Code Refactoring lieferte eine Strategie, die der Software-Architekt Martin Fowler vor vielen Jahren nach einer Pflanze benannte: das Strangler Fig Pattern (zu Deutsch: Würgefeigen-Muster).

In der Natur wächst die Würgefeige von oben nach unten. Sie keimt in den Ästen eines alten, bestehenden Baumes, lässt ihre Wurzeln langsam zum Boden herab und umschließt den Wirtsbaum im Laufe der Zeit vollständig. Wenn der alte Baum irgendwann abstirbt und verrottet, bleibt die Würgefeige als eigenständiger, starker Baum in exakt derselben Form stehen.

Genau dieses Prinzip haben wir auf unsere Software-Architektur angewandt.

Wir bauten nicht den ganzen Shop auf einmal neu, sondern setzten eine Art "intelligenten Türsteher" vor das alte System – ein sogenanntes API-Gateway. Wenn ein Kunde nun den Shop aufrief, landete seine Anfrage zuerst bei diesem neuen Türsteher. Zu Beginn leitete dieses Gateway einfach 100 Prozent des Datenverkehrs an das alte, rostige Legacy-System weiter. Für den Nutzer sah alles aus wie immer.

Dann begannen wir mit der eigentlichen Magie des Refactorings. Wir suchten uns einen kleinen, gut isolierbaren Teilbereich des Shops aus. In unserem Fall war das die Produktsuche. Wir bauten einen blitzschnellen, modernen und völlig eigenständigen Microservice, der ausschließlich dafür zuständig war, Produkte zu suchen und anzuzeigen. Als dieser neue Service fertig und ausgiebig getestet war, gaben wir dem "Türsteher" (dem API-Gateway) einen neuen Befehl: "Wenn ein Kunde nach einem Produkt sucht, schicke ihn zum neuen System. Für alles andere (Warenkorb, Bezahlung) schickst du ihn weiterhin zum alten System."

Der Erfolg war sofort spürbar. Die Suchergebnisse, die früher quälende Sekunden zum Laden brauchten, ploppten nun in unter 100 Millisekunden auf den Bildschirmen der Nutzer auf. Und das Beste daran: Wenn der neue Such-Service einen Fehler gehabt hätte, hätten wir am Gateway einfach einen Schalter umlegen und den Traffic sofort wieder auf das alte System zurückleiten können. Das Risiko lag praktisch bei null.

Schritt für Schritt, Monat für Monat wiederholten wir diesen Prozess. Wir bauten einen neuen Service für den Warenkorb, dann einen neuen für die Benutzerkonten und schließlich einen für die Zahlungsabwicklung. Die digitale Würgefeige wuchs. Das alte System wurde immer weniger aufgerufen, es schrumpfte und verlor an Bedeutung, während die neue Architektur die Last übernahm.

Als nach vielen Monaten der letzte Datenverkehr vom alten Monolithen abgezogen war, kam der Moment, auf den jeder Entwickler beim Legacy Code Refactoring hinfiebert: Wir konnten den Server des alten, zehn Jahre alten Shops endgültig und für immer abschalten. Der Wirtsbaum war verschwunden, die neue Architektur stand von ganz allein.

Doch während dieses Prozesses stießen wir auf ein massives Hindernis, das tief in der Psychologie von Entwicklerteams verwurzelt ist.

Die Überwindung der Angst – Wie man ein Sicherheitsnetz aus Code webt

Wenn wir über das Legacy Code Refactoring sprechen, fokussieren wir uns oft extrem auf die reine Technik: auf Microservices, APIs, neue Datenbankstrukturen und das elegante Strangler Fig Pattern. Doch die Realität in den Büros sieht anders aus. Das größte Hindernis bei der Modernisierung unseres zehn Jahre alten Online-Shops war kein technisches Limit, sondern ein zutiefst menschliches Gefühl: nackte Angst.

In historisch gewachsenen, undokumentierten Systemen entwickelt jedes Teammitglied über die Jahre einen ungesunden Überlebensinstinkt. Das ungeschriebene Gesetz lautet: "Never touch a running system." Jeder Entwickler wusste, dass eine scheinbar harmlose Änderung an der Mehrwertsteuer-Berechnung im Backend unweigerlich dazu führen konnte, dass im Frontend plötzlich die Produktbilder verschwanden. Der Code glich einem Kartenhaus im Wind. In einer solchen Umgebung wird der "Delete"-Button, der eigentlich das wichtigste Werkzeug eines Programmierers zur Code-Pflege ist, zum absoluten Tabu.

Man kann aber das Triebwerk eines fliegenden Flugzeugs nicht austauschen, wenn die Mechaniker vor Panik zittern. Um von den katastrophalen drei Sekunden Ladezeit auf unsere anvisierten 300 Millisekunden zu kommen, brauchten wir mutige, tiefgreifende Schnitte. Wir mussten also einen Weg finden, dem Team die Angst vor dem eigenen Code zu nehmen. Die Lösung dafür lautet: Automatisierte Tests.

Doch hier beißt sich die Katze oft in den Schwanz. Wie schreibt man Unit-Tests für einen monolithischen Spaghetti-Code, der niemals dafür entworfen wurde, getestet zu werden? Die Funktionen waren hunderte Zeilen lang, voller Abhängigkeiten zur Datenbank und gespickt mit globalen Variablen.

Die Rettung brachte eine spezielle Methodik, die als Charakterisierungstests (Characterization Tests) bekannt ist. Bei dieser Art von Tests geht es interessanterweise überhaupt nicht darum, zu prüfen, ob der Code das Richtige tut. Es geht ausschließlich darum, das aktuelle Verhalten des Systems wie in Bernstein einzufrieren – inklusive all seiner historischen Fehler und Eigenheiten.

Wir nahmen uns den alten Checkout-Prozess vor und schrieben Skripte, die tausende Male fiktive Warenkörbe in das System pumpten. Wir speicherten exakt ab, welche Summe, welche Rabatte und welche Datenbankeinträge am Ende herauskamen. Wir bauten ein gigantisches, engmaschiges Sicherheitsnetz um den Monolithen.

Sobald dieses Netz gespannt war, passierte etwas Magisches mit der Kultur im Entwicklerteam. Die psychologische Last fiel plötzlich von den Schultern der Programmierer ab. Wenn nun ein Entwickler eine alte, kryptische Zeile Code löschte und die Charakterisierungstests danach "Grün" anzeigten, wusste er mit hundertprozentiger Gewissheit: Ich habe nichts kaputt gemacht. Zeigten die Tests "Rot", hatte er eine Abhängigkeit übersehen, drückte einfach Strg+Z (Rückgängig) und das Problem war gelöst, noch bevor ein Kunde es jemals zu Gesicht bekam.

Dieses Sicherheitsnetz transformierte die Arbeitsweise radikal. Die Entwickler hörten auf, um den alten Code herumzuarbeiten. Sie begannen, ihn aggressiv umzustrukturieren. Das Vertrauen in die eigene Handlungsfähigkeit kehrte zurück, und die Continuous Integration (CI) Pipeline wurde zum besten Freund des Teams. Ohne dieses Fundament an automatisierten Tests wäre jeder Versuch eines tiefgreifenden Legacy Code Refactorings pures russisches Roulette gewesen.

Doch mit dem wiedergewonnenen Mut und dem gekapselten System stießen wir auf die nächste, gigantische Baustelle: Die Datenbank. Ein Bereich, der oft noch viel starrer und gefährlicher ist als der Quellcode selbst.

Die Operation an den Organen – Wenn die Datenbank zum Flaschenhals wird

Wir hatten durch unser API-Gateway und das Strangler Fig Pattern einen Weg gefunden, den alten Quellcode Schritt für Schritt in Rente zu schicken. Wir hatten durch automatisierte Charakterisierungstests ein Sicherheitsnetz gewebt, das dem Team die Angst vor Fehlern nahm. Alles schien auf einem fantastischen Weg zu sein. Doch beim Legacy Code Refactoring gibt es eine unausgesprochene Wahrheit: Der Code ist nur die Haut. Die Datenbank ist das eigentliche Organ.

Unser zehn Jahre alter Online-Shop nutzte eine einzige, gigantische relationale Datenbank. Im Laufe eines Jahrzehnts war diese Datenbank zu einem unentwirrbaren Wollknäuel mutiert. Die Tabelle für Benutzer war direkt verknüpft mit den Bestellungen, diese wiederum mit den Produkten, die mit dem Lagerbestand und schließlich mit den Newsletter_Abonnenten verbunden waren. Wollte man einen einfachen Microservice für den neuen Warenkorb bauen, stellte man schnell fest, dass dieser Service die halbe historische Datenbank mit sich ziehen musste, um überhaupt zu funktionieren.

Eine monolithische Datenbank in verteilte, schnelle Microservices aufzubrechen, ist der wahre Stresstest jeder Modernisierung. Ein falsches Skript, ein fehlerhafter DROP TABLE Befehl, und zehntausende Kundendaten sind im digitalen Nirwana verschwunden.

Wenn Sie an diesem Punkt stehen und sich fragen, wie man diese gigantische Aufgabe strategisch über das gesamte Unternehmen hinweg plant, ohne den Faden zu verlieren, möchte ich Ihnen eine unserer wichtigsten Ressourcen ans Herz legen. Werfen Sie unbedingt einen Blick in unseren umfassenden Pillar-Artikel: Veraltete Webseiten modernisieren – Der komplette Leitfaden. Dort finden Sie die exakte strategische Roadmap, die über die reine Code-Ebene hinausgeht und das große Ganze beleuchtet.

Um unsere Datenbank-Krise zu lösen, griffen wir auf ein Muster zurück, das in der Fachwelt als Dual Writes (Doppeltes Schreiben) bekannt ist.

Wir konnten die alte Datenbank nicht einfach kopieren und abschalten, da in jeder Sekunde neue Live-Bestellungen hereinkamen. Also brachten wir unserem Code einen genialen Trick bei. Jedes Mal, wenn sich ein Kunde registrierte oder eine Bestellung aufgab, schrieb das alte System diese Daten wie gewohnt in die alte, langsame Datenbank. Gleichzeitig – quasi als unsichtbarer Schatten – schrieb das System dieselben Daten aber auch in unsere völlig neu strukturierte, blitzschnelle Datenbank der neuen Architektur.

Über Wochen hinweg liefen beide Organe parallel. Wir schrieben Skripte, die nachts die Altbestände stückweise in das neue System pumpten, während das "Dual Write" Muster dafür sorgte, dass keine neuen Transaktionen verloren gingen. Das Team überwachte die Metriken akribisch. Wir verglichen die Datensätze beider Systeme, suchten nach Inkonsistenzen und besserten nach.

Es war eine nervenaufreibende Phase. Die Performance des Shops wurde in dieser Zeit sogar kurzfristig etwas schlechter, da das System jeden Datensatz doppelt verarbeiten musste. Doch wir wussten, wofür wir diesen Preis zahlten.

Der Tag der Wahrheit rückte näher. Die neue Datenbank war vollständig synchronisiert, die neuen Microservices waren bereit. Wir mussten nur noch den Schalter umlegen und das Skalpell ansetzen, um die alte Verbindung für immer zu kappen.

Der Tag X – Wenn aus drei Sekunden plötzlich 300 Millisekunden werden

Nach vielen Monaten der akribischen Vorbereitung, der Software-Archäologie, dem Aufbau des API-Gateways nach dem Strangler Fig Pattern und der nervenaufreibenden parallelen Datenbank-Migration (Dual Writes) war er endlich da. Der "Tag X". Der Tag, an dem wir dem alten, monolithischen System endgültig den Stecker ziehen würden.

In der Theorie beim Legacy Code Refactoring ist dieser Moment völlig unspektakulär. Man ändert eine kleine Routing-Regel im Load Balancer, sodass 100 Prozent des Datenverkehrs nicht mehr auf das alte System, sondern auf die neuen Microservices geleitet werden. In der Praxis jedoch glich die Stimmung im Büro der Kommandozentrale der NASA kurz vor einer Mondlandung. Jeder starrte gebannt auf die riesigen Monitore mit den Live-Metriken.

Der Lead-Entwickler drückte die Enter-Taste. Das Routing wurde aktualisiert.

Was dann auf den Dashboards passierte, war einer dieser seltenen, absolut magischen Momente in der IT. Wir sahen, wie die CPU-Auslastung der alten, zehn Jahre alten Server-Instanz, die jahrelang unter ständiger Überlastung geächzt hatte, innerhalb von Sekundenbruchteilen auf null abfiel. Die rote Linie der Datenbank-Warteschlange verschwand einfach. Der Monolith war tot.

Gleichzeitig erwachte die neue Architektur zum Leben. Und die Zahlen, die nun auf dem Bildschirm erschienen, übertrafen unsere kühnsten Erwartungen.

Vor dem Refactoring lag die durchschnittliche Ladezeit des Online-Shops (die sogenannte Time to First Byte) bei quälenden drei Sekunden. Für E-Commerce-Verhältnisse ist das eine absolute Katastrophe – bei drei Sekunden Wartezeit springen laut Google-Studien bereits über 50 Prozent der potenziellen Käufer ab. Jetzt, mit der entkoppelten Datenbank und der schlanken Microservice-Architektur, stürzte dieser Wert ab. Die Graphen auf dem Monitor rutschten nach unten und pendelten sich bei konstanten, stabilen 300 Millisekunden ein. Die Seitenaufrufe fühlten sich nicht mehr wie das Laden einer Webseite an, sondern so schnell und reibungslos wie eine native App auf dem Smartphone.

Im Büro brach Jubel aus. Die Last, die jahrelang auf dem Team gelegen hatte – die ständige Angst vor dem nächsten Serverausfall, die Furcht vor jeder noch so kleinen Code-Änderung –, fiel in diesem einen Moment ab. Das Team hatte die Operation am offenen Herzen nicht nur überlebt, der Patient lief jetzt auch noch einen Marathon.

Die Auswirkungen dieses erfolgreichen Legacy Code Refactorings reichten jedoch weit über das IT-Büro hinaus. In der darauffolgenden Woche meldete sich das Marketing-Team. Durch die drastisch verbesserte Performance und die blitzschnellen Ladezeiten war die Conversion-Rate (die Rate der Seitenbesucher, die tatsächlich etwas kaufen) um knapp 18 Prozent in die Höhe geschossen. Gleichzeitig registrierte der Kundenservice einen massiven Rückgang an Beschwerden über abgebrochene Bezahlvorgänge im Checkout.

Doch der vielleicht größte Triumph war die wiedergewonnene Agilität. Als das Marketing kurz darauf ein völlig neues, zeitlich begrenztes Rabattsystem für den Black Friday anfragte – eine Anforderung, die im alten System wochenlange Arbeit und massive Risiken bedeutet hätte –, konnte das Entwicklerteam dieses Feature innerhalb von nur drei Tagen isoliert entwickeln, testen und live schalten.

Die technischen Schulden waren abbezahlt. Das System gehörte wieder uns.