Komplexe Refactorings planen

Komplexe Refactorings planen

0:00 Im letzten Modul war jeder Schritt so klein, dass er nicht scheitern konnte. Jetzt kommen die Umbauten, bei denen das nicht mehr funktioniert — wo Sie mit dem naheliegenden ersten Schritt beginnen und plötzlich nichts mehr baut. Die Erfahrung kennen die meisten von uns. Was viele nicht kennen, sind die Verfahren, mit denen man solche Umbauten trotzdem in sichere Schritte zerlegt.

0:21 Der gemeinsame Nenner ist eine ungewohnte Denkrichtung: Man arbeitet rückwärts, vom Ziel zu seinen Voraussetzungen — statt vorne anzufangen und sich durchzukämpfen.

Komplexe Refactorings planen

0:30 Wir beginnen mit dem Erkennungszeichen: Woran merke ich, dass die kleinen Schritte nicht mehr tragen? Dann kommt die Mikado-Methode als grundlegende Denkweise. Danach vier Muster, die jeweils eine typische Situation abdecken — einen tief eingebauten Bestandteil austauschen, einen Vertrag ändern, etwas Problematisches einschließen, Neues neben Altem wachsen lassen.

0:51 Und zum Schluss ein Kapitel, das trocken klingt und über Erfolg entscheidet: die Buchführung über den Umbau. In der Übung zerlegen Sie eine echte Strukturänderung am Fahrtenbuch.

Wenn kleine Schritte nicht ausreichen

1:02 Fangen wir mit der Situation an, um die es geht. Sie ist unangenehm, sie kommt regelmäßig vor, und der erste Reflex ist fast immer der falsche. Sie wollen etwas umbauen und fangen mit dem naheliegenden ersten Schritt an. Der setzt drei andere voraus, die Sie vorher nicht gesehen haben. Sie nehmen sich die vor — und die haben ihrerseits Voraussetzungen.

1:23 Nach zwei Stunden baut nichts mehr, und der Weg zurück zu einem lauffähigen Zustand ist länger als der Weg vorwärts scheint. Wichtig ist die Diagnose: Das liegt nicht an Ihrem Können und nicht am Ziel. Es liegt an der Annahme, man könne vorne anfangen. Bei verflochtenem Bestandscode ist die richtige Richtung fast immer die umgekehrte.

1:43 Diese vier Zeichen sollten bei Ihnen eine Alarmglocke auslösen, und zwar früh. Das erste ist das deutlichste: Nach jedem Reparaturversuch ist mehr kaputt als vorher. Das zweite ist das eigentliche Kriterium — der Rückweg wird länger, nicht kürzer. Das dritte beschreibt, was dabei mit dem Umfang passiert: Er wächst, während das Ziel gleich bleibt.

2:04 Und das vierte ist der handfeste Test, den Sie jederzeit machen können: Ließe sich der aktuelle Stand sinnvoll committen? Wenn nein, sind Sie in genau dieser Lage. Der erste Punkt ist die klassische Fehlinvestitionsfalle: weitermachen, weil schon so viel Arbeit hineingeflossen ist. Die investierte Zeit ist weg, egal wofür Sie sich entscheiden — sie sollte die Entscheidung deshalb nicht beeinflussen.

2:28 Der zweite ist die verlockendste Variante: Man erhöht den Umfang, um wieder lauffähig zu werden. Manchmal klappt das sogar, und dann haben Sie gelernt, dass es klappt. Der dritte ist vermeidbar: Wer zwischendurch nie baut, merkt gar nicht, wann er in diesen Zustand geraten ist.

Rückwärts denken: die Mikado-Methode

2:45 Jetzt die Methode, die diesen Knoten auflöst. Sie wirkt beim ersten Hören umständlich und ist es beim ersten Mal auch — und danach möchte man sie nicht mehr missen. Der Name kommt vom Mikado-Spiel: Man zieht das Stäbchen, das obenauf liegt, nicht das, das man haben will. Übertragen heißt das: Sie versuchen die gewünschte Änderung direkt.

3:06 Es bricht etwas. Und jetzt kommt der ungewohnte Teil — Sie reparieren nicht. Sie notieren, welche Voraussetzung offenbar fehlt, und machen die Änderung rückgängig. Dann nehmen Sie sich die notierte Voraussetzung vor. So entsteht ein Baum von Abhängigkeiten, dessen Blätter Änderungen sind, die Sie sofort und gefahrlos ausführen können.

3:27 Fünf Schritte, und der vierte ist der, an dem alle hängenbleiben: die Änderung vollständig zurücknehmen. Sie verwerfen mehrfach Arbeit, um Wissen zu gewinnen — und das fühlt sich falsch an. Genau dieses Wissen ist aber der Ertrag: Sie kennen danach die Reihenfolge, in der der Umbau funktioniert, und die hätten Sie durch Nachdenken nicht gefunden.

3:46 Die Fußzeile beschreibt den Rest: Abgearbeitet wird von außen nach innen, Blatt für Blatt. Jedes Blatt lässt das System lauffähig, und irgendwann ist die Zieländerung von selbst möglich, weil alle Voraussetzungen stehen. Hier hat sich durch agentische Werkzeuge etwas spürbar verbessert. Die Methode war immer richtig und immer mühsam, weil die Versuche Zeit kosteten.

4:07 Genau die sind jetzt billig: Ein Agent probiert eine Änderung in Minuten und nimmt sie ebenso schnell wieder zurück — er hängt emotional nicht an seiner Arbeit, was ihm das Verwerfen leichter macht als uns. Was beim Menschen bleibt, ist die Buchführung über den Baum. Und der letzte Punkt ist die wichtige Umdeutung: Der Ertrag dieser Arbeit ist nicht der Code.

4:27 Es ist das Wissen über die Reihenfolge.

Branch by Abstraction

4:30 Jetzt das erste konkrete Muster. Es beantwortet die Frage, wie man einen tief eingebauten Bestandteil austauscht, ohne dass das System zwischenzeitlich stillsteht. Das Bild dazu ist eine Brückensanierung bei laufendem Verkehr: Man baut daneben, leitet um, und erst wenn die neue Spur trägt, wird die alte abgerissen. Beim Code heißt das: Sie ziehen eine Zwischenschicht über den alten Bestandteil und leiten alle Aufrufer über sie um. Dann bauen Sie dahinter das Neue auf. Dann schalten Sie um.

4:58 Für das Fahrtenbuch ist das der Weg für die veraltete Datumsbibliothek — die steckt an dreißig Stellen, und ein Austausch in einem Zug wäre nicht prüfbar. Der rote Faden: Jede Phase verändert genau eine Sache. Phase eins führt die Abstraktion ein, ohne dass sich Verhalten ändert — das ist ein kleiner, gut prüfbarer Schritt.

5:18 Phase zwei leitet um. Phase drei baut das Neue auf, ohne es zu aktivieren; das ist die Phase, in der viel Arbeit anfällt und trotzdem nichts passieren kann. Phase vier schaltet um, bereichsweise, mit Rückschaltmöglichkeit. Und Phase fünf räumt auf. Der entscheidende Vorteil steht in der Fußzeile: Jeder Schritt ist einzeln freigebbar, und genau das macht einen Umbau über Wochen tragfähig.

5:43 Der erste Punkt ist der häufigste: Man führt die Abstraktion ein und schreibt gleich die neue Umsetzung mit, weil man ja weiß, wohin es geht. Damit haben Sie zwei Dinge in einem Schritt und die Prüfbarkeit verloren. Der zweite ist der riskanteste: Umschalten ohne Rückschaltmöglichkeit. Der ganze Reiz dieses Musters ist die Umkehrbarkeit — wer sie weglässt, hat den Aufwand ohne den Nutzen.

6:05 Und der vierte ist der, den man nach getaner Arbeit gern vergisst: Wenn die Abstraktion nach dem Umbau keinen Zweck mehr hat, gehört sie weg.

Parallel Change für Verträge und Daten

6:14 Das nächste Muster gilt für alles, worauf sich andere verlassen. Es hat drei Phasen — und die dritte ist die, die in der Praxis am häufigsten unterbleibt. Sie kennen das Muster schon aus Modul drei, dort als phasenweise Schemaänderung. Hier ist es allgemein: hinzufügen, umstellen, entfernen. Für Schnittstellen, Formate, Schemata — alles, was Ihr System verlässt. Für das Exportformat der Buchhaltung ist es nicht ein möglicher Weg, sondern der einzige verantwortbare.

6:43 Die Alternative wäre, das Format zu ändern und die Buchhaltung zu informieren — und darauf zu hoffen, dass niemand sonst diese Datei liest. Die Erfahrung sagt: Es liest immer noch jemand. Die Logik der drei Phasen ist, dass in keiner von ihnen jemand zum Handeln gezwungen wird. Phase eins: Das Neue existiert, alle arbeiten unverändert weiter.

7:06 Phase zwei: Nutzer stellen um, jeder in seinem Tempo — das darf Monate dauern und ist trotzdem kein Problem, weil beide Wege funktionieren. Phase drei: entfernen, wenn nachweislich niemand mehr zugreift. Die Fußzeile benennt die typische Krankheit: Phase drei unterbleibt, weil sie keinen sichtbaren Nutzen bringt. Danach sammeln sich halb abgelöste Wege an — und jeder kostet bei jeder künftigen Änderung mit.

7:32 Warum reicht ein Vorsatz nicht? Weil „vermutlich nutzt es niemand mehr“ genau die Aussage ist, vor der wir in Modul zwei gewarnt haben — eine ausschließende Behauptung, gewonnen durch Nachdenken. Der Nachweis ist eine Beobachtung: eine Protokollierung am alten Weg, die zeigt, ob dort noch Zugriffe ankommen. Das ist derselbe Mechanismus wie beim toten Code aus Modul sechs.

7:54 Und Punkt drei ist die organisatorische Ergänzung: Ohne festgelegten Endtermin bleibt jede Übergangslösung dauerhaft. Nicht aus Nachlässigkeit — nur ist nie der richtige Zeitpunkt.

Kapseln: Adapter, Fassade und Schutzschicht

8:05 Das nächste Muster ist eine wichtige Erinnerung: Nicht jeder problematische Teil muss geändert werden. Manchmal ist die bessere Antwort, ihn einzuschließen und in Ruhe zu lassen. Sie ziehen eine Schicht dazwischen, die nach innen mit dem Bestand spricht — in seinen alten, merkwürdigen Begriffen — und nach außen die Begriffe verwendet, die Sie haben wollen.

8:26 Das Bild dazu ist ein Dolmetscher: Sie müssen die andere Sprache nicht lernen, und die andere Seite muss sich nicht ändern. Besonders wertvoll ist das an Stellen, an denen fremde Begriffe in Ihr System eindringen würden — eine Fremdschnittstelle mit einem Datenmodell, das nicht zu Ihrem passt. Der erste Vorteil ist der, der zählt: Der Bestand bleibt unangetastet, also risikofrei. Sie haben nichts kaputt machen können, weil Sie nichts geändert haben.

8:51 Der zweite: Neuer Code arbeitet sofort mit sauberen Begriffen, statt sich den alten anzupassen. Der dritte ist strategisch — die Grenze, die Sie ziehen, ist der natürliche Ort für eine spätere Ablösung. Sie schaffen also nebenbei die Naht, an der irgendwann getrennt wird. Und damit ist die Kapselung auch die Antwort auf die Frage, was man mit einem Teil macht, der schlecht, aber stabil ist: einschließen und in Ruhe lassen.

9:16 Der erste Punkt ist der handwerkliche: Eine zu dünne Schicht lässt die alten Begriffe durchschlagen — dann haben Sie eine zusätzliche Ebene und trotzdem das alte Modell. Der zweite ist die schleichende Variante: Logik wandert nach und nach in die Schutzschicht, bis sie selbst zum Bestand geworden ist. Und der dritte ist der ehrlichste: Wenn eine Ablösung ohnehin ansteht, ist die Kapselung kein Muster, sondern Aufschub — mit dem Nachteil, dass Sie hinterher zwei Dinge abzulösen haben.

Neues neben Altem: Sprout und Wrap

9:43 Jetzt zwei kleine Muster für eine sehr alltägliche Situation: Sie sollen eine neue Funktion in eine Methode einbauen, die Sie nicht verstehen und die nicht getestet ist. Die übliche Reaktion ist, sich in die Methode hineinzuarbeiten und die neue Logik irgendwo dazwischen unterzubringen. Damit passiert etwas Unangenehmes: Der neue Code nimmt die Eigenschaften des alten an. Er wird genauso untestbar, weil er in derselben untestbaren Umgebung steckt.

10:10 Die beiden Muster hier vermeiden das, indem sie den Bestand ergänzen statt umzubauen. Sie schreiben sauber daneben und verbinden mit einer einzigen Zeile. Das ist kein eleganter Zustand — es ist ein ehrlicher. Der Unterschied liegt darin, wo Sie ansetzen. Beim ersten Muster schreiben Sie die neue Einheit daneben und rufen sie aus der alten Methode an einer Stelle auf — der Bestand wächst um eine Zeile.

10:34 Beim zweiten benennen Sie die alte Methode um und legen eine neue mit dem alten Namen darüber, die das Zusätzliche erledigt und dann die alte aufruft. Der Rumpf der alten Methode bleibt völlig unberührt. Beide haben dieselbe Eigenschaft: Der Eingriff in unverstandenen Code ist minimal und im Diff auf einen Blick zu erfassen.

10:52 Der erste Punkt ist die eigentliche Begründung, und er wird oft unterschätzt: Neuer Code, der in altem entsteht, übernimmt dessen Eigenschaften. Nicht weil jemand nachlässig wäre, sondern weil er sich in die vorhandene Struktur einfügen muss. Getrennt geschrieben, kann er von Anfang an getestet sein. Der dritte Punkt ist der praktische Gewinn für den Review: Es gibt genau eine Stelle im Bestand, die geprüft werden muss — die Aufrufzeile.

11:17 Und über die Zeit wächst so ein sauberer Bereich neben dem Alten, mit einer sichtbaren Grenze dazwischen.

Fortschritt, Sackgassen und Rückkehr dokumentieren

11:23 Zum Abschluss ein Kapitel, das nach Bürokratie klingt und über den Erfolg komplexer Umbauten mitentscheidet. Es geht darum, was bei einer Unterbrechung verlorengeht — und das ist nicht der Code. Ein komplexer Umbau zieht sich über Tage, und er wird unterbrochen — durch einen Produktionsfehler, ein Wochenende, einen Urlaub.

11:42 Der Code ist dabei sicher, der steht in der Versionsverwaltung. Was verlorengeht, ist der Stand des Denkens: welcher Zweig des Abhängigkeitsbaums erledigt ist, welche Versuche gescheitert sind und warum, welche Annahme sich als falsch erwiesen hat. Ohne Notiz beginnen Sie nach der Unterbrechung wieder von vorn — und laufen zuverlässig in dieselben Sackgassen.

12:04 Die gescheiterten Versuche sind das Wertvollste an dieser Notiz, weil sie am teuersten erkauft sind. Jeder von ihnen hat Sie eine halbe Stunde gekostet, und ohne Notiz ist dieses Wissen nach dem Wochenende weg. Punkt drei ist der inhaltlich wichtigste: Halten Sie die widerlegten Annahmen fest, ausdrücklich als widerlegt markiert. Sonst kommen sie zurück — sie waren ja plausibel.

12:26 Und der vierte Punkt ist der agentenspezifische: Ein Agent erinnert zwischen zwei Sitzungen gar nichts. Für ihn ist die Notiz nicht Gedächtnisstütze, sondern die einzige Verbindung zur vorherigen Arbeit. Fünf Punkte, und keiner davon braucht mehr als ein paar Zeilen. Der Baum mit erledigten und offenen Zweigen ist der Kern.

12:45 Die gescheiterten Versuche mit dem beobachteten Bruch — nicht mit einer Interpretation, sondern mit dem, was tatsächlich passiert ist. Die widerlegten Annahmen. Der nächste geplante Schritt samt Rückweg. Und offene Fragen wandern ins Unknowns Register. Die Fußzeile nennt den unmittelbaren praktischen Nutzen: Dieser festgehaltene Baum bringt einen Agenten in Minuten wieder auf Stand — statt einer erneuten Erkundung, die Sie noch einmal bezahlen.

Übung: Eine Strukturänderung als Abhängigkeitsbaum

13:12 Jetzt wenden Sie die Mikado-Methode an, an einer Änderung, die sich direkt nicht durchführen lässt. Und Sie werden mehrfach zurücknehmen — das ist die Übung, nicht ein Zeichen von Misserfolg. Das Ziel kennen Sie schon aus Modul fünf: Die Steuerlogik der Abrechnung soll ohne laufende Datenbank testbar werden. Direkt geht das nicht — die Berechnung holt sich unterwegs Daten nach, schreibt Zwischenstände und stößt den Mailversand an. Genau deshalb ist es ein gutes Übungsobjekt.

13:41 Wichtig ist die Haltung beim ersten Bruch: nicht reparieren. Notieren, was fehlt, und zurücknehmen. Wer repariert, verliert den Baum — und damit das Einzige, was diese Übung produzieren soll. Arbeiten Sie den Zyklus konsequent durch, bis Ihre Blätter wirklich sofort ausführbar sind. Dann kommt Schritt vier, der oft unterschätzt wird: eine Reihenfolge finden, die nach jedem Schritt Lauffähigkeit erhält.

14:05 Es gibt meist mehrere gültige, und sie unterscheiden sich im Risiko. Führen Sie zum Schluss zwei Blätter tatsächlich aus, damit die Methode nicht nur Theorie bleibt. Und halten Sie fest, wie oft Sie zurücknehmen mussten — diese Zahl ist ein brauchbares Maß für die Verflechtung Ihres Bestands. Im nächsten Modul geht es darum, wie man das Ergebnis solcher Umbauten prüft.