Legacy Code realistisch einordnen

Legacy Code realistisch einordnen

0:00 Willkommen zu einem Seminar, das mit einer unbequemen Wahrheit beginnt: Der allergrößte Teil der Software, die heute geschrieben wird, ist nicht neu. Sie wird geändert. Und die Werkzeuge, über die alle reden, wurden an grünen Wiesen vorgeführt — an Projekten, die bei null anfangen. Was passiert, wenn ein Coding-Agent auf ein zwanzig Jahre altes System trifft, das niemand mehr ganz versteht, ist eine andere Frage. Genau die stellen wir hier.

0:25 Drei Tage lang geht es darum, Bestandssysteme zu verstehen, abzusichern und in kontrollierten Schritten zu verändern — mit Agentenunterstützung, aber ohne die Kontrolle abzugeben. Anfangen müssen wir mit dem Begriff selbst.

Legacy Code realistisch einordnen

0:39 Der erste Tag baut das Fundament, und er tut das in der Reihenfolge, in der man auch praktisch vorgeht: erst einordnen, dann erkunden, dann Risiken bestimmen, dann absichern. Verändert wird an Tag eins noch nichts — und das ist Absicht. In diesem ersten Modul klären wir, was Legacy Code eigentlich ist, warum der Begriff in seiner üblichen Verwendung mehr verdeckt als erklärt, und welche Rolle Coding-Agenten in einem Bestand spielen können.

1:04 Am Ende steht eine Übung, in der Sie sechs Veränderungsvorhaben einordnen. Sie werden merken: Die Einordnung ist oft schwerer als die Umsetzung.

Was Legacy Code tatsächlich ausmacht

1:13 Fangen wir mit dem Wort an. „Legacy“ wird als Schimpfwort benutzt, ungefähr in der Bedeutung „Code, den ich nicht geschrieben habe“. Das ist unterhaltsam und für die Arbeit vollkommen wertlos. Wir brauchen eine Beschreibung, mit der man Entscheidungen treffen kann — also eine, die auf etwas Messbares zeigt. Wenn Sie verschiedene Bestandssysteme nebeneinanderlegen, finden Sie immer wieder dieselben Merkmale: Das Verhalten ist nur teilweise dokumentiert, Tests fehlen oder sind unzuverlässig, das Wissen ist mit Menschen aus dem Haus gegangen, und die Bibliotheken darunter pflegt niemand mehr.

1:48 Das klingt nach einer Mängelliste, und genau so wird es meistens gelesen. Entscheidend ist aber der letzte Punkt, den man leicht überliest: Jede Änderung kostet mehr Zeit und trägt mehr Risiko, als ihr fachlicher Umfang vermuten ließe. Ein Feature, das zwei Tage dauern sollte, dauert zwei Wochen. Das ist die eigentliche Definition — alles andere sind Symptome.

2:08 Warum diese Zuspitzung auf ein einziges Merkmal? Weil nur eines davon im Budget auftaucht. Undokumentiertes Verhalten kostet nichts, solange niemand hinsieht. Fehlende Tests kosten nichts, solange sich nichts ändert. Die Änderungskosten dagegen sieht jede Projektleitung, jedes Quartal, in jedem Schätzgespräch. Und deshalb ist ein zwanzig Jahre altes System, das stabil läuft und einmal im Jahr angefasst wird, kein Sanierungsfall, sondern ein Erfolg — es hat sich über zwei Jahrzehnte amortisiert.

2:39 Eine Ausnahme gibt es: Ungepflegte Abhängigkeiten sind kein Schönheitsthema, sondern ein Sicherheitsthema. Die kosten irgendwann, ob Sie das System anfassen oder nicht. Diese Fehler passieren nicht aus Unkenntnis, sondern aus Gewohnheit. Alter mit Sanierungsbedarf gleichzusetzen ist bequem, weil das Alter im Repository steht und die Änderungskosten nicht.

3:01 Den Begriff als Urteil zu verwenden, ist menschlich — nur führt es dazu, dass die Diskussion über Geschmack läuft statt über Geld. Am häufigsten sehe ich den dritten Punkt: Jemand öffnet eine Datei, findet sie hässlich und leitet daraus Handlungsbedarf ab. Wie oft diese Datei in den letzten zwei Jahren geändert wurde, hat niemand nachgesehen. Genau diese Zahl wäre die relevante gewesen.

Legacy ist eine Beziehung, kein Zustand

3:24 Jetzt kommt der Gedanke, der dieses ganze Seminar trägt. Wenn Sie ihn mitnehmen und sonst nichts, war der Tag schon nützlich. Er verschiebt die Frage von „wie schlecht ist dieser Code“ zu einer ganz anderen — und die lässt sich beantworten. Stellen Sie sich zwei Häuser vor. Beide sind gleich alt, gleich verwinkelt, gleich schlecht gedämmt. In dem einen wohnt seit dreißig Jahren dasselbe Ehepaar, sehr zufrieden.

3:49 In dem anderen soll ein Aufzug eingebaut werden. Nur eines der beiden Häuser hat ein Problem — und man sieht es dem Gebäude nicht an. Mit Code ist es genauso. Derselbe Abschnitt ist harmlos, solange ihn niemand anfasst, und wird zum Hindernis in dem Moment, in dem eine fachliche Änderung durch ihn hindurch muss. Die Eigenschaft „Legacy“ steckt nicht im Code. Sie steckt in der Beziehung zwischen dem Code und Ihrem Vorhaben.

4:14 Aus dieser Sichtweise folgt zweierlei, und beides ist unbequem. Erstens: Die flächendeckende Sanierung ist widerlegt. Sie verteilt Aufwand gleichmäßig, während der Nutzen sich auf wenige Stellen konzentriert — Sie zahlen überall und profitieren an drei Stellen. Zweitens, und das ist die gute Nachricht: Sie brauchen kein Priorisierungsverfahren mehr zu erfinden. Es ergibt sich.

4:38 Wo Änderungsdruck herrscht und der Code sich wehrt, lohnt die Investition. Überall sonst nicht. Und daraus folgt etwas, das man aussprechen muss: „Wir lassen das so“ ist eine vollwertige, professionelle Entscheidung. Kein Aufschieben, sondern eine Wahl. Der erste Punkt ist der teuerste: Aufräumen, wo seit Jahren niemand etwas ändert.

4:59 Das fühlt sich nach Fortschritt an, produziert aber nur Risiko — jede Änderung kann etwas kaputt machen, auch eine gut gemeinte. Der zweite ist subtiler: Wer vierzig Befunde in einem Modul zählt und daraus Dringlichkeit ableitet, verwechselt Menge mit Bedeutung. Und der dritte begegnet mir in fast jedem Projekt: Änderungsdruck wird aus dem Bauchgefühl abgeleitet, obwohl die Versionshistorie ihn schwarz auf weiß enthält.

5:23 Wir schauen im nächsten Modul genau da hinein.

Wert und Belastung auseinanderhalten

5:27 Bevor wir über Verfahren reden, noch ein Gedanke zur Bewertung. Bestandssysteme werden meistens nach ihrer technischen Verfassung beurteilt. Dabei geht ihre wertvollste Eigenschaft unter — eine, die sich nicht im Code zeigt, sondern in dem, was der Code über die Jahre gelernt hat. In jedem gewachsenen System stecken Regeln, die niemand aufgeschrieben hat, weil sie in dem Moment selbstverständlich schienen.

5:51 Ein Rabatt, der nur für einen bestimmten Kundentyp gilt. Eine Rundung, die sich einmal jemand von der Buchhaltung hat bestätigen lassen. Jeder dieser Sonderfälle ist irgendwann von einem Menschen eingebaut worden, weil die Wirklichkeit ihn erzwungen hat. Das ist Geschäftswissen in ausführbarer Form, und es existiert nirgendwo sonst vollständig — nicht im Wiki, nicht im Kopf der Fachabteilung, nicht in irgendeinem Konzept.

6:14 Der Code ist an dieser Stelle die einzige verlässliche Quelle. Das Prinzip hinter dieser Aufteilung ist einfach: Zwei völlig verschiedene Größen werden regelmäßig zu einer einzigen Note zusammengezogen, und dabei geht die Entscheidung verloren. Fachlicher Wert und technische Belastung sind unabhängig voneinander. Ein Modul kann fachlich unentbehrlich und technisch furchtbar sein — dann brauchen Sie einen Plan.

6:38 Es kann technisch sauber und fachlich überflüssig sein — dann schalten Sie es ab. Wer beides vermengt, landet bei „schlechter Code, also weg damit“ und wirft das Wissen mit hinaus. Es kommt dann über Jahre einzeln zurück, jedes Mal ausgelöst durch einen Produktionsfehler. Der Neubau wird selten als das verkauft, was er wirklich ist. Er wird als Befreiung erzählt: endlich sauber anfangen.

7:01 Was dabei untergeht, ist der Wissensverlust — und der ist nicht theoretisch, sondern messbar in Fehlern nach dem Umstieg. Der zweite Punkt betrifft die Sonderfälle: Wer sie für Schlamperei hält, ohne ihre Herkunft geprüft zu haben, löscht möglicherweise die Regel, wegen der ein Großkunde bei Ihnen bleibt. Und der vierte Punkt ist der methodische Kern: Sobald Sie Wert und Belastung in einer Zahl zusammenziehen, können Sie die Entscheidung nicht mehr begründen.

Typische Brownfield-Situationen

7:27 Jetzt wird es konkret. Bestandsprobleme sind erstaunlich uniform — über Branchen, Sprachen und Jahrzehnte hinweg. Wer die Muster kennt, weiß nach einer Woche, wo er steht, statt sie jedes Mal neu zu entdecken. Und wir lernen das System kennen, das uns drei Tage begleiten wird. Das ist einer der wenigen Trostpunkte an der Bestandsarbeit: Sie werden fast nie etwas völlig Neues sehen. Die Kombination ist jedes Mal anders, die Zutaten sind immer dieselben.

7:55 Das hat einen praktischen Wert, den man nutzen sollte — Sie können mit einer Erwartung in ein unbekanntes System gehen und gezielt nachsehen, statt sich überraschen zu lassen. Und Sie können die typischen Fragen vorbereiten, statt sie im Laufe von Wochen einzeln zu entdecken. Genau darauf bauen wir in Modul zwei die Erkundung auf.

8:14 Diese vier Punkte begegnen mir in fast jedem Projekt. Der interessanteste ist der dritte, und zwar der zweite Halbsatz: Tests, die sporadisch fehlschlagen, sind schlimmer als gar keine Tests. Bei fehlenden Tests weiß jeder, dass es kein Netz gibt, und verhält sich entsprechend vorsichtig. Bei unzuverlässigen Tests glaubt niemand mehr einem roten Ergebnis — man startet den Lauf einfach noch einmal.

8:37 In dem Moment, in dem das zur Gewohnheit wird, ist das Netz weg, aber alle glauben noch, es sei da. Das ist die gefährlichere Situation von beiden. Lernen Sie unser Beispielsystem kennen — es begleitet uns durch alle drei Tage. Ein Fahrtenbuch für einen Fuhrpark: Fahrten werden erfasst, monatlich abgerechnet, die Abrechnung geht als Datei an die Buchhaltung.

8:59 Interessant ist die Kombination, die Sie hier sehen. Es ist nicht so, dass irgendwo im System schlechter Code liegt — er liegt genau dort, wo jedes Jahr Änderungen anfallen, er ist nicht durch Tests abgesichert, und es gibt niemanden mehr, der ihn erklären kann. Das ist die Ecke, in der es wehtut. Und es ist die Ecke, an der sich Investition tatsächlich rechnet.

Refactoring, Reparatur und Feature-Änderung trennen

9:20 Kommen wir zu einer Unterscheidung, die im Alltag ständig verwischt wird — meist in bester Absicht. Sie klingt nach Begriffsklauberei und ist in Wahrheit das, woran Ihre gesamte Prüfung hängt. Wenn Sie diese drei Dinge vermischen, können Sie hinterher nicht mehr sagen, ob etwas kaputt ist. Die drei Tätigkeiten unterscheiden sich in genau einem Punkt: was mit dem beobachtbaren Verhalten passiert.

9:43 Beim Refactoring bleibt es unangetastet — das ist nicht ein Qualitätsmerkmal guter Refactorings, sondern ihre Definition. Bei einer Reparatur ändert es sich absichtlich, weil es vorher falsch war. Bei einer Feature-Änderung ändert es sich absichtlich, weil neue Anforderungen gelten. Im Alltag rutscht das zusammen: Man baut um und korrigiert schnell noch eine Kleinigkeit mit. Verständlich — und es kostet Sie das wichtigste Prüfkriterium, das Sie haben.

10:11 Hier steht der eigentliche Grund für die Unterscheidung, und er ist rein praktisch. Die Art der Änderung bestimmt, was mit Ihren Tests passieren darf. Beim Refactoring gilt: alle Tests bleiben unverändert grün. Unverändert ist das entscheidende Wort — wenn Sie eine Erwartung anpassen mussten, damit es wieder grün wird, hat sich Verhalten geändert, und dann war es kein Refactoring.

10:33 Bei Reparatur und Feature dagegen muss sich ein Test ändern, sichtbar und begründet. Deshalb ist die Vermischung so teuer: Danach steht ein geänderter Test im Diff, und niemand kann noch entscheiden, ob das Absicht war. Punkt eins und zwei sind zwei Seiten derselben Sache und die häufigsten Fehler überhaupt. „Ich habe da beim Umbauen einen Fehler gesehen und gleich behoben“ — das ist gut gemeint und macht den Patch unprüfbar.

10:57 Punkt zwei ist die gefährlichere Variante, weil sie sich richtig anfühlt: Der Test ist rot, man schaut hinein, die neue Erwartung wirkt plausibel, man passt sie an. Damit haben Sie gerade das Sicherheitsnetz an die Änderung angepasst statt umgekehrt. Achten Sie besonders darauf, wenn ein Agent den Patch gebaut hat — der tut genau das sehr bereitwillig, weil er die Testsuite grün bekommen will.

Migration und Neubau gegeneinander abwägen

11:20 Jetzt zur folgenreichsten Entscheidung im ganzen Themenfeld. Sie wird meist früh getroffen, oft emotional, und sie legt anschließend Jahre fest. Reden wir darüber, was tatsächlich für und gegen den Neubau spricht. Ich will das nicht als Glaubensfrage behandeln, deshalb ganz nüchtern: Für den Neubau spricht ein Gefühl — endlich sauber anfangen, ohne die Altlasten.

11:41 Dieses Gefühl ist echt und in Entwicklungsteams weit verbreitet, und es ist ein schlechter Ratgeber, weil es die Kosten systematisch unterschätzt. Gegen den Neubau spricht fast alles andere, und wir gehen es gleich einzeln durch. Es gibt Situationen, in denen er trotzdem die richtige Wahl ist — die schauen wir uns auch an.

11:59 Nur sind sie deutlich seltener als die Begeisterung für sie. Vier Punkte, und jeder für sich reicht, um ein Vorhaben zu kippen. Der Umfang wird erst im Bauen sichtbar, weil man das alte System nicht kennt — Sie entdecken die Sonderfälle einzeln, über Monate. Sie pflegen zwei Systeme parallel, und das alte bekommt weiter Änderungen, die Sie nachziehen müssen.

12:21 Sie liefern bis zum Ende keinen Nutzen, das Vorhaben ist also nicht abbrechbar — neunzig Prozent fertig ist wertlos. Und Sie verlieren das Wissen, über das wir eben gesprochen haben. Die schrittweise Ablösung hat keinen dieser vier Nachteile. Das ist der ganze Punkt. Damit das nicht als Dogma stehen bleibt: Es gibt drei Konstellationen, in denen der Neubau die richtige Entscheidung ist — und sie haben eine gemeinsame Logik.

12:46 In allen dreien fällt einer der Nachteile weg. Wenn die Plattform ausläuft, hat schrittweise Erneuerung kein Ziel mehr, auf das sie zusteuern könnte. Wenn das System klein und gut verstanden ist, entfällt das Wissensrisiko. Und wenn sich die Fachlichkeit ohnehin grundlegend ändert, ist das alte Verhalten gar nicht erhaltenswert.

13:05 Prüfen Sie also nicht, ob Sie Lust auf einen Neubau haben, sondern ob einer dieser drei Punkte zutrifft.

Wo Coding-Agenten im Bestand helfen — und wo nicht

13:11 Damit sind wir beim Thema, wegen dem Sie vermutlich hier sind. Coding-Agenten in der Neuentwicklung kennen die meisten inzwischen. Im Bestand verhalten sie sich anders — ihre Stärken liegen woanders, und ihre Gefahren auch. Der wichtigste Unterschied lässt sich in einem Satz sagen: In der Neuentwicklung ist das Schreiben der Engpass, im Bestand das Lesen.

13:32 Und genau da liegt die Stärke dieser Werkzeuge. Ein Agent erschließt ein fremdes Modul in Minuten, verfolgt Datenflüsse durch fünf Schichten, findet Verwendungsstellen und stellt Zusammenhänge her, für die ein Mensch Tage bräuchte. Das ist keine Kleinigkeit — das Verstehen fremden Codes ist der teuerste Posten in jedem Wartungsprojekt.

13:51 Dass ausgerechnet dieser Posten billig geworden ist, verändert die Rechnung für Modernisierungsvorhaben erheblich. Achten Sie auf die Bewegung von oben nach unten: Sie verläuft von „gut lesbar“ zu „gut prüfbar“. Oben, beim Lesen und beim Erzeugen von Tests, können Sie das Ergebnis nachvollziehen. Weiter unten wird es schwieriger.

14:10 Domänenwissen ist die klare Grenze: Ob eine merkwürdige Regel ein Fehler ist oder eine bewusste Sonderbehandlung für einen Großkunden, steht nirgends im Repository — kein Modell kann das wissen, und es wird trotzdem eine Antwort geben. Die letzte Zeile ist die eigentliche Gefahr, und sie ist heimtückisch: Der Patch ist nicht schlecht. Er ist gut und zu groß, um ihn noch zu prüfen.

14:34 Der erste Punkt ist der Kern der nächsten drei Tage: Eine plausible Erklärung ist keine belegte. Ein Agent liefert beides im selben ruhigen Tonfall, und Sie hören den Unterschied nicht. Der dritte Punkt kostet fast nichts und wird ständig übergangen: Die gesamte Erkundungsphase braucht nur Leserechte. Warum sollte ein Werkzeug schreiben dürfen, das gerade nur liest?

14:55 Und der letzte ist der, den man sich merken sollte: Wenn Sie die Schrittgröße nicht vorgeben, wählt der Agent die große Lösung. Nicht aus Übermut — er sieht den Zusammenhang und hat keinen Grund, ihn künstlich zu zerlegen.

Übung: Veränderungsvorhaben klassifizieren

15:08 Zum Abschluss des ersten Moduls wenden wir das an. Sie bekommen sechs Vorhaben rund um das Fahrtenbuch, wie sie so oder ähnlich in jedem Ticketsystem stehen. Und Sie werden merken, dass die Einordnung mehr Arbeit macht als erwartet. Die Vorhaben sind bewusst so formuliert, wie sie im Alltag ankommen — knapp, verkürzt, mit einer impliziten Lösung darin.

15:29 „Die Exportdatei soll ein zusätzliches Feld enthalten“ klingt nach einem kleinen Feature und ist in Wirklichkeit eine Vertragsänderung mit einem Nachbarsystem. „Die Abrechnung ist zu langsam“ nennt ein Symptom, kein Ziel. Ihre Aufgabe ist es, hinter die Formulierung zu kommen: Welche Art von Änderung ist das wirklich, was ist das eigentliche Ziel, wie groß ist das Risiko?

15:51 Und dann die Frage, die uns drei Tage begleitet: Welcher Anteil davon geht sinnvoll an einen Agenten? Gehen Sie der Reihe nach vor, aber lassen Sie sich von Schritt fünf nicht irritieren — der ist der eigentliche Kern. Bei mindestens zwei der sechs Vorhaben werden Sie feststellen, dass Sie mit den vorliegenden Informationen gar nicht entscheiden können.

16:11 Das ist kein Mangel der Aufgabe, sondern die realistische Situation: Genau so kommen Anforderungen an. Der professionelle Umgang damit ist nicht, eine Annahme zu treffen und loszulaufen, sondern die fehlende Information zu benennen und die richtige Frage zu stellen. Halten Sie deshalb fest, welche Frage Sie zuerst stellen würden — und an wen.