Glossar
Legacy-Code
Auch: Altsystem · Bestandscode
Code ohne Tests, der Geld verdient. Die Definition von Michael Feathers ist deshalb brauchbar, weil sie das eigentliche Problem benennt: fehlende Absicherung, nicht das Alter.
Alter allein macht kein Legacy. Ein zwanzig Jahre altes System mit Tests, Dokumentation und Leuten, die es verstehen, ist ein solides System. Ein zwei Jahre alter Dienst ohne Tests, dessen Entwickler das Unternehmen verlassen haben, ist Legacy. Der Unterschied ist die Frage, ob man ihn gefahrlos ändern kann.
Daraus folgt die wichtigste Konsequenz: Legacy ist kein Zustand des Codes, sondern des Wissens. Was ein System tut, steht im Code. Warum es das tut, stand in Köpfen, und die sind gegangen. Deshalb ist der erste Schritt nie ein Umbau, sondern zu verstehen, was das System heute wirklich tut, samt der Eigenarten, die niemand geplant hat.
Diese Eigenarten sind der Kern des Problems. In jedem gewachsenen System gibt es Verhalten, das aus einem Fehler entstanden ist, auf das sich aber inzwischen jemand verlässt: ein Rundungsfehler, den die Buchhaltung eingepreist hat, ein Sonderfall für einen einzelnen Großkunden, eine Reihenfolge, die zufällig funktioniert. Ein Neubau nach Spezifikation bildet genau das nicht nach.
Der praktikable Einstieg heißt: absichern, bevor verändert wird. Characterization Tests halten das heutige Verhalten fest, unabhängig davon, ob es richtig ist. Erst wenn dieses Netz steht, ist eine Änderung eine Änderung und keine Wette.
Organisatorisch ist der Bus-Faktor die wichtigste Kennzahl: Wie viele Personen können einen Bereich anfassen. Bei eins ist jeder Urlaub ein Risiko und jede Kündigung ein Vorfall. Wissen zu verteilen ist billiger als jede Modernisierung und wird trotzdem selten geplant.
Und schließlich lohnt der ehrliche Blick darauf, was gar nicht angefasst werden muss. Ein stabiler Bereich, den niemand ändert, kostet nichts, auch wenn er hässlich ist. Modernisiert wird dort, wo gearbeitet wird.
Woran Sie es erkennen
- Es gibt keine oder kaum automatisierte Tests.
- Die Menschen, die den Code geschrieben haben, sind nicht mehr im Unternehmen.
- Niemand kann sagen, warum eine bestimmte Sonderbehandlung existiert.
- Änderungen führen zu Störungen an Stellen, die nichts damit zu tun haben.
Nicht zu verwechseln mit
- Technische Schulden
- Der aufgeschobene Aufwand. Legacy beschreibt den Zustand fehlender Absicherung. Ein Legacy-System kann wenig Schulden tragen, wenn es stabil ist und selten geändert wird.
- Brownfield
- Die Ausgangslage „es gibt schon etwas". Sagt nichts über Testbarkeit oder Wissensstand. Jedes Legacy-Projekt ist Brownfield, nicht jedes Brownfield ist Legacy.
- Monolith
- Eine Architekturform. Ein gut geschnittener Monolith mit Tests ist kein Legacy, und verteilte Dienste ohne Tests sind es sehr wohl.
Wann es trägt
- An dem System soll fachlich weitergearbeitet werden.
- Änderungen führen regelmäßig zu Störungen an unerwarteter Stelle.
- Nur noch einzelne Personen können bestimmte Bereiche anfassen.
Wann nicht
- Bei einem stabilen System, das keine Änderungen mehr bekommt und in absehbarer Zeit abgelöst wird.
- Als Vorbereitung eines Neubaus, der ohnehin beschlossen ist: dann ist das Verstehen wichtiger als das Absichern.
Wie man rangeht
- Verstehen, bevor geplant wirdCode, Infrastruktur und Störungshistorie lesen. Die Störungshistorie verrät mehr über die wahren Schwachstellen als jede Dokumentation.
- Wissen aufschreiben, solange es noch jemanden gibtWer das System kennt, wird gehen. Was heute in einem Gespräch geklärt wird, kostet nach dem Weggang Wochen der Rekonstruktion.
- Absichern mit Characterization TestsDas heutige Verhalten festhalten, auch wo es falsch aussieht. Ob es richtig ist, wird später entschieden, jetzt geht es um das Netz.
- Grenzen ziehenEinen Anti-Corruption-Layer setzen, damit neuer Code nicht die Eigenheiten des alten übernimmt. Ohne diese Grenze wandert Legacy in das Neue.
- Schrittweise ablösenStrangler Fig statt Neubau. Jeder Schritt geht einzeln in Produktion und lässt sich einzeln zurückdrehen.
- Alten Pfad wirklich abschaltenDas Abschalten gehört in dieselbe Aufgabe wie das Umschalten. Sonst betreibt man zwei Systeme statt einem, und die Modernisierung hat die Lage verschlechtert.
Häufig gefragt
Ab wann ist ein System Legacy?
Sobald es sich nicht mehr gefahrlos ändern lässt, weil Absicherung und Wissen fehlen. Das Alter ist nebensächlich. Ein zwei Jahre alter Dienst ohne Tests, dessen Entwickler weg sind, erfüllt die Definition; ein zwanzig Jahre altes System mit Tests und Kennern nicht.
Sollte man Legacy-Code neu schreiben?
Fast nie in einem Zug. Der Neubau muss Verhalten nachbilden, das niemand vollständig kennt, während das alte System weiterläuft und sich verändert. Die schrittweise Ablösung liefert ab dem ersten Monat Teile in Produktion und lässt sich an jeder Stelle anhalten.
Wie fängt man an, wenn niemand das System kennt?
Mit Lesen und Beobachten: Code, Infrastruktur, Störungshistorie, tatsächlicher Verkehr. Danach Characterization Tests für die Bereiche, die angefasst werden sollen. Dieses Vorgehen ist unspektakulär und verkürzt jedes folgende Vorhaben erheblich.
Was tun mit Verhalten, das offensichtlich falsch ist?
Erst festhalten, dann fragen, dann ändern. Wer einen Rundungsfehler stillschweigend korrigiert, kann eine Abrechnung verändern, auf die sich jemand seit Jahren verlässt. Die Korrektur ist eine fachliche Entscheidung, keine technische.