Legacy in der App-Entwicklung — was es ist, Risiken und Strategien

Was ist Legacy in der App-Entwicklung

Legacy — Code oder System, das weiterhin in Production läuft, aber nicht mehr den modernen Qualitätsstandards entspricht. Legacy kann in einer veralteten Sprache geschrieben sein (z.B. Objective-C statt Swift), nicht mehr unterstützte Bibliotheken oder Architekturmuster verwenden, die längst als Antipatterns gelten.

Das Hauptmerkmal von Legacy ist das Fehlen von Tests. Nach der Definition von Michael Feathers (2004) ist Legacy-Code Code ohne Tests. Wenn man das Verhalten nicht sicher ändern kann, ist das System unabhängig vom Alter im Legacy-Status. Neuer Code ohne Unit-Tests ist ab dem ersten Tag Legacy.

Legacy ist nicht unbedingt schlecht. Ein gut entworfenes System in Java 8 kann zuverlässiger und verständlicher sein als chaotischer Kotlin-Code mit Coroutinen. Das Alter des Codes ist kein Qualitätsindikator — entscheidend ist, wie leicht das System geändert und erweitert werden kann.

Warum Legacy-Code normal ist

Jedes erfolgreiche System wird mit der Zeit zu Legacy. Das ist ein natürlicher Prozess: Technologien entwickeln sich schneller, als Code umgeschrieben werden kann. Eine vor 5 Jahren in Swift 2 geschriebene App ist heute Legacy, obwohl sie zum Zeitpunkt der Erstellung modern war.

Der Geschäftswert von Legacy wird oft unterschätzt. Das System arbeitet zuverlässig, verarbeitet Transaktionen, speichert Daten — eine Neuschreibung birgt Risiken. Laut Standish Group (2024) scheitern 35% der Projekte mit vollständiger Neuschreibung. Wirtschaftlich ist es gerechtfertigt, Legacy nicht zu beseitigen, sondern zu lernen, damit zu arbeiten.

Die besten Strategien sind schrittweise Migration, Kapselung des alten Codes hinter neuen Schnittstellen und automatisierte Tests. Legacy wird erst dann zum Problem, wenn es nicht mehr zu vorhersehbaren Kosten änderbar ist.

Hauptmerkmale eines Legacy-Systems

Fehlende automatisierte Tests — der Hauptindikator. Wenn ein Entwickler nach Änderung einer einzigen Zeile keine Tests ausführen und bestätigen kann, dass nichts kaputt gegangen ist — haben Sie es mit Legacy zu tun. Ein zusätzliches Anzeichen: Der Deployment-Prozess dauert Stunden und erfordert manuelle Schritte.

Dokumentation stimmt nicht mit Code überein — ein weiteres Merkmal. Architekturdiagramme sind veraltet, Kommentare beschreiben ein Verhalten, das sich bereits geändert hat. Die Einarbeitungszeit für einen neuen Entwickler übersteigt einen Monat — ein Zeichen für hohe Komplexität und geringe Wartbarkeit.

Weitere Anzeichen: monolithische Architektur ohne klare Grenzen, manuelles Testen als primäre Überprüfungsmethode, lange CI-Pipeline (über 30 Minuten), Verwendung von Bibliotheken ohne aktuelle Versionen und Unfähigkeit, Abhängigkeiten zu aktualisieren ohne zusammenhängende Module zu beschädigen.

Das Phänomen des fragilen Codes — eine Änderung an einer Stelle zerstört drei andere. Das ist eine Folge von enger Kopplung, bei der Module zu viel voneinander wissen. Je höher die Kopplung, desto schneller geht das System in die Legacy-Kategorie über.

Risiken der Arbeit mit veraltetem Code

Geschwindigkeitsverlust — das Hauptrisiko. Das Hinzufügen einer einfachen Funktion erfordert Stunden zum Studieren des Codes und Tage zum Testen. Laut Stripe (2024) verbringen Entwickler 33% ihrer Zeit mit der Überwindung technischer Schulden, die direkt mit dem Vorhandensein von Legacy-Modulen im Projekt zusammenhängen.

Wissensabfluss — die Autoren des Originalcodes verlassen das Unternehmen und die Dokumentation ist unvollständig. Neue Entwickler haben Angst, unbekannte Module anzufassen, was zum Effekt des „gefrorenen Codes“ führt: Das Modul entwickelt sich nicht weiter, funktioniert aber weiter. Der Bus-Faktor solcher Systeme ist kritisch niedrig.

Sicherheit — veraltete Bibliotheken enthalten bekannte Schwachstellen. Die Verwendung von OpenSSL 1.0.2 oder veralteten Jackson-Versionen in Java-Projekten ist der direkte Weg zu Sicherheitsvorfällen, die dem Unternehmen Reputation und Kunden kosten können.

Team-Demotivation — Arbeit mit Legacy ohne Verbesserungsstrategie senkt die Zufriedenheit der Entwickler. Das Team hört auf, stolz auf das Produkt zu sein, die Personalfluktuation steigt, was die Systementwicklung weiter verlangsamt.

Legacy-Refactoring-Strategien

Characterization Tests — der erste Schritt vor jeder Änderung von Legacy-Code. Führen Sie den Code mit bekannten Eingabedaten aus und zeichnen Sie die erwartete Ausgabe auf. Diese Tests erfassen das aktuelle Verhalten als Spezifikation. Golden Master Testing ist eine Variante, bei der die Ausgabe mit einer Referenzdatei verglichen wird.

Seam-Analyse — Suche nach Punkten, an denen die Kopplung ohne Verhaltensänderung aufgebrochen werden kann. Michael Feathers identifiziert mehrere Arten von Seams: Preprocessor Seam, Object Seam, Link Seam. Object Seam ist der häufigste: Ersetzen eines realen Objekts durch einen Test-Stub über eine Schnittstelle.

Sprout Method und Sprout Class — Techniken zum Hinzufügen von neuem Code neben altem Code, nicht innerhalb davon. Statt eine vorhandene Methode zu ändern, erstellen Sie eine neue Methode mit der gewünschten Logik und rufen Sie sie von der alten aus auf. So wird das Risiko minimiert, funktionierenden Code zu beschädigen.

Beispiel: Logging zu Legacy hinzufügen

class LegacyPaymentProcessor {
    def process(payment) {
        // 200 Zeilen Legacy-Code, die nicht angerührt werden sollten
        logPayment(payment) // Sprout-Methode
    }
    def logPayment(payment) {
        // neuer Code neben Legacy hinzugefügt
    }
}

Migration auf modernen Technologie-Stack

Strangler-Fig-Muster — der empfohlene Ansatz für die Legacy-Migration. Ein neues Modul wird parallel erstellt, der Datenverkehr wird schrittweise vom alten auf das neue umgeleitet. Das alte Modul stirbt auf natürliche Weise, wenn es keine Anfragen mehr erhält. Das Muster minimiert Risiken und ermöglicht einen Rollback bei Problemen.

Branch by Abstraction — eine Technik, bei der eine Abstraktion über der alten und neuen Implementierung erstellt wird. Der Client-Code wechselt zur Abstraktion, und die alte Implementierung wird schrittweise ersetzt. Beispiel: Ersetzen der Netzwerkschicht von AFNetworking durch Alamofire über ein einheitliches NetworkService-Protokoll.

Schrittweise Migration — Aufteilung des Übergangs in kleine Schritte: altes Modul kapseln → Tests schreiben → neues Modul erstellen → parallel laufen lassen → altes Modul entfernen. Jeder Schritt endet mit einem stabilen Systemzustand, was eine Auslieferung zu jedem Zeitpunkt ermöglicht.