Beginnen Sie die Modernisierung einer Legacy-Anwendung damit, schriftlich festzuhalten, warum sie sich ändern muss, und bewerten Sie dann Code und Produktion gemeinsam. Stabilisieren Sie das System und legen Sie Tests um das Verhalten, auf das das Geschäft angewiesen ist, bevor Sie seine Struktur ändern. Mit diesem Sicherheitsnetz ersetzen Sie das System Stück für Stück, migrieren die Daten mit Bedacht und heben sich eine komplette Neuentwicklung für den seltenen Fall auf, in dem wenig erhaltenswert ist.
Benennen Sie den geschäftlichen Grund, bevor Sie den Code anfassen
Modernisierung ist teuer, also beginnen Sie mit dem Grund. Häufige Gründe sind eine Laufzeitumgebung oder ein Framework am Supportende, Änderungen, die Wochen dauern, weil jedes Release etwas kaputtmacht, ein System, das nur eine Person versteht, oder eine Plattform, die nicht tragen kann, was das Geschäft als Nächstes braucht. Jeder Grund führt zu einem anderen ersten Schritt.
Halten Sie den Grund schriftlich fest, mit einer Messgröße, die Sie später prüfen können, etwa wie oft Sie releasen, wie viele Vorfälle Sie haben oder wie lange eine typische Änderung braucht, bis sie bei den Nutzern ankommt. Ohne sie wird die Modernisierung zu einem endlosen Technikprojekt, das sich bei der nächsten Budgetrunde schwer verteidigen lässt.
Bewerten Sie Code und Produktion, bevor Sie etwas entscheiden
Eine Bewertung zeigt Ihnen, was Sie tatsächlich haben. Halten Sie sie kurz und lassen Sie sie mit einem schriftlichen Bericht und einem empfohlenen ersten Schritt enden. Lesen Sie den Code, aber lesen Sie auch die Produktion: Logs, Vorfälle, langsame Abfragen und die Art, wie Releases ablaufen. Die schlimmsten Probleme liegen oft rund um den Code statt in ihm.
- Versionen von Laufzeitumgebung, Framework und Bibliotheken, und welche davon keine Sicherheitsupdates mehr erhalten
- Welche Teile sich am häufigsten ändern und welche am häufigsten ausfallen, laut Versionshistorie und Vorfallprotokoll
- Testabdeckung auf den Pfaden, auf die das Geschäft angewiesen ist
- Wie die Anwendung gebaut, konfiguriert und deployt wird, und wer das kann
- Das Datenmodell, sein Umfang und welche anderen Systeme dieselbe Datenbank lesen oder beschreiben
- Die Menschen, die das System kennen, und was nur sie wissen
Stabilisieren Sie zuerst die Produktion, damit die Arbeit eine feste Basis hat
Fällt das System jede Woche aus, wird die Modernisierung jede Woche unterbrochen. Beheben Sie zuerst, was Vorfälle verursacht: Richten Sie Monitoring und Alarme auf kritischen Pfaden ein, automatisieren Sie Build und Deployment, damit Releases reproduzierbar sind, und holen Sie Secrets und Konfiguration aus dem Code.
Diese Schritte zahlen sich sofort aus und machen jeden späteren Schritt sicherer. Sie zeigen auch früh, ob das Team das System ändern kann, ohne es kaputtzumachen, und das sollten Sie wissen, bevor Sie sich auf einen größeren Plan festlegen.
Legen Sie ein Sicherheitsnetz aus Tests um das Verhalten, auf das Sie sich verlassen
Legacy-Code hat meist wenige Tests, und sein dokumentiertes Verhalten stimmt selten mit dem tatsächlichen überein. Schreiben Sie vor Strukturänderungen Charakterisierungstests: Tests, die festhalten, was das System heute tut, einschließlich seiner merkwürdigen Grenzfälle, sodass jede Verhaltensänderung als fehlschlagender Test sichtbar wird.
Beginnen Sie an den Rändern, mit Tests, die die Anwendung über ihre API oder Benutzeroberfläche aufrufen und die Ergebnisse prüfen, denn diese überstehen interne Änderungen. Spielen Sie bei Berechnungen und Berichten echte Eingaben durch den alten und den neuen Code und vergleichen Sie die Ausgaben. Ergänzen Sie feinere Tests für jeden Teil, sobald Sie ihn refaktorieren. Unser Artikel über das Upgrade einer kritischen Java-8-Anwendung zeigt dasselbe Sicherheitsnetz bei einem Upgrade der Laufzeitumgebung.
Ersetzen Sie das System Stück für Stück, statt es neu zu schreiben
Eine komplette Neuentwicklung sieht auf dem Papier sauber aus, aber das alte System läuft weiter und verändert sich, während das neue aufholt, und jedes undokumentierte Verhalten muss unterwegs neu entdeckt werden. Deshalb dauern Neuentwicklungen so oft länger als geplant, während das Geschäft wartet.
Die übliche Alternative ist das Strangler-Fig-Muster. Stellen Sie eine Routing-Schicht, etwa einen Reverse Proxy oder ein API-Gateway, vor die Legacy-Anwendung. Bauen Sie jeweils eine Funktion im neuen Code und leiten Sie den Traffic für diese Funktion dorthin, sobald sie sich bewährt hat. Das alte System schrumpft, bis es abgeschaltet werden kann, und das Geschäft profitiert bei jedem Schritt.
Eine Neuentwicklung kann trotzdem die richtige Wahl sein: wenn die Codebasis klein und ihr Verhalten gut verstanden ist oder wenn die Plattform, auf der sie läuft, nicht lange genug am Leben gehalten werden kann, um sie schrittweise zu ersetzen. Entscheiden Sie mit schriftlichen Kriterien, nicht aus Frust.
Behandeln Sie die Daten als eigene Migration
Code lässt sich in Scheiben ersetzen; Daten sind schwerer aufzuteilen. Solange Legacy- und neuer Code eine Datenbank teilen, muss jede Schemaänderung abgestimmt werden. Legen Sie früh fest, welches System für welche Art von Daten die maßgebliche Quelle ist, und vermeiden Sie, dass zwei Systeme denselben Datensatz schreiben, ohne dass geregelt ist, welcher Schreibvorgang gewinnt.
Wenn eine Funktion umzieht, verschieben oder synchronisieren Sie ihre Daten mit Bedacht: mit Migrationsskripten, die an einer Kopie der Produktion getestet wurden, oder mit fortlaufender Synchronisation, solange beide Systeme laufen. Planen Sie, wie Sie beide abgleichen, zum Beispiel mit täglichen Zählungen und Prüfsummen, und behalten Sie die Möglichkeit zurückzuschalten, bis die Zahlen übereinstimmen.
Ordnen Sie die Arbeit nach Risiko und Nutzen und zeigen Sie früh Fortschritte
Ordnen Sie die Arbeit so, dass jeder Schritt entweder ein Risiko senkt oder etwas liefert, das das Geschäft sehen kann. Eine übliche Reihenfolge: stabilisieren und automatisieren, Tests ergänzen, die Laufzeitumgebung aktualisieren und dann die Funktionen herauslösen, die sich am häufigsten ändern. Stabile, selten angefasste Teile können warten, manchmal unbegrenzt.
Halten Sie den Plan kurz und überprüfen Sie ihn nach jedem Schritt, denn was Sie lernen, wird die Reihenfolge ändern. Unsere Entwickler haben so an kritischen Systemen gearbeitet. Über Sopra Steria haben sie die Migration einer kritischen Anwendung für das Day-Trading von Gas von Java 8 auf 16 geleitet, und als Teil des Teams im Cloud-Programm von Crédit Agricole haben wir jede Anwendung, die wir migriert haben, bewertet, um über Upgrade oder Neubau zu entscheiden. Wenn Sie eine Bewertung Ihres eigenen Systems oder ein Team für die Umsetzung des Plans möchten: SDK Enterprises übernimmt beides unter einem Vertrag.
Das Wichtigste in Kürze
- Halten Sie den geschäftlichen Grund für die Modernisierung schriftlich fest, mit einer Messgröße, die Sie später prüfen können.
- Bewerten Sie Code und Produktion gemeinsam, bevor Sie zwischen Upgrade, schrittweiser Ablösung und Neuentwicklung wählen.
- Stabilisieren Sie die Produktion und legen Sie Charakterisierungstests um kritisches Verhalten, bevor Sie die Struktur ändern.
- Ersetzen Sie das System Stück für Stück hinter einer Routing-Schicht, es sei denn, eine Neuentwicklung ist klar kleiner und sicherer.
- Planen Sie Datenhoheit, Synchronisation und Abgleich als eigene Migration.
FAQ
Sollten wir unsere Legacy-Anwendung komplett neu schreiben?
Meist nicht. Eine Neuentwicklung konkurriert mit einem System, das sich ständig weiter ändert, und muss Verhalten neu entdecken, das niemand dokumentiert hat. Ersetzen Sie es schrittweise, es sei denn, die Codebasis ist klein und gut verstanden oder an eine Plattform gebunden, die sich nicht weiter betreiben lässt.
Wie lange dauert die Modernisierung einer Legacy-Anwendung?
Das hängt von der Größe des Systems ab, von seiner Testabdeckung, davon, wie verflochten seine Daten sind, und davon, wie viel sich ändern muss. Eine kurze Bewertung liefert Ihnen einen realistischen Plan und einen ersten Schritt, der klein genug ist, um ihn abzuschließen und zu messen, statt eines einzigen Termins für das gesamte Vorhaben.
Können wir während der Modernisierung weiter Features ausliefern?
Ja, und das sollten Sie auch. Bei der schrittweisen Ablösung kann das Team Features im neuen Code liefern, während das Legacy-System weiterläuft. Vereinbaren Sie, wie viel der Teamzeit in die Modernisierung fließt, damit die Feature-Arbeit sie nicht unbemerkt aufzehrt.