Zum Danebenlegen, wenn der Umbau größer ist als ein paar Schritte — wenn eine Bibliothek abgelöst, ein Vertrag geändert oder ein Monolith aufgeteilt werden soll. Das Blatt sammelt die Muster und Entscheidungsraster aus der zweiten Hälfte des Seminars; es ersetzt nicht die Übung, sie anzuwenden.
Erster Teil: Verstehen und absichern.
Parallel Change
Drei Phasen für Verträge und Daten. Unterbleibt die dritte, sammeln sich halb abgelöste Wege an — deshalb vom ersten Tag an einplanen.
| Phase | Was passiert |
|---|---|
| Hinzufügen | Neues neben Altem, alle bisherigen Nutzer arbeiten unverändert weiter |
| Umstellen | Nutzer nacheinander, in eigenem Tempo, notfalls über Monate |
| Entfernen | erst wenn nachweislich niemand mehr zugreift |
„Vermutlich nutzt es niemand mehr” trägt die Löschung nicht. Der Nachweis ist eine Beobachtung: Protokollierung am alten Weg, mit festgelegtem Endtermin.
Modul: Komplexe Refactorings planen
Sprout und Wrap
Zwei Wege, Neues neben Altem entstehen zu lassen, ohne im Bestand zu wühlen.
| Muster | Vorgehen | Eingriff in den Bestand |
|---|---|---|
| Sprout | neuer Teil als eigene, getestete Einheit daneben | eine Aufrufzeile |
| Wrap | alte Methode umbenennen, neue mit altem Namen darüber | Umbenennung, kein Eingriff im Rumpf |
Das ist mehr als ein Trick: Neuer Code, der in altem entsteht, übernimmt dessen Eigenschaften. Getrennt geschrieben, kann er von Anfang an getestet sein — und die Aufrufstelle ist der einzige Punkt, den der Review prüfen muss.
Modul: Komplexe Refactorings planen
Diff-Review bei Umbauten
Fünf Befunde, entlang derer man den Diff liest — statt nach Gefühl.
| Befund | Warum er entsteht |
|---|---|
| Vereinfachte Bedingung ohne Randfall | Aufräumen, das Verhalten mitnimmt |
| Entfernte Fehlerbehandlung | ein Fangblock sah überflüssig aus, weil unkommentiert |
| Geänderte Sichtbarkeit | erweitert eine Schnittstelle stillschweigend |
| Neue Abstraktion oder Abhängigkeit | war nicht beauftragt, wirkt aber sinnvoll |
| Formatierung nicht betroffener Dateien | bläht den Diff und versteckt die echten Änderungen |
Der letzte Befund ist selten schädlich für das Programm und immer schädlich für die Prüfbarkeit.
Was über die Testsuite hinaus zu prüfen ist:
| Bereich | Prüfung |
|---|---|
| Schnittstellen | Antwortformate zeichengenau vergleichen, nicht fachlich bewerten |
| Dateiformate | Reihenfolge, Trennzeichen und Zeilenende einschließen |
| Datenmigrationen | Zählungen und Stichproben vor und nach dem Lauf |
Modul: Verifikation und Review von Refactoring-Patches
Drei Stufen der Prüfung
| Stufe | Wirkung |
|---|---|
| Selbstprüfung im selben Kontext | bestätigt die eigenen Annahmen |
| Frischer Kontext, nur Diff und Auftrag | findet, was die Entstehung verdeckt hat |
| Gezielte Frage statt allgemeiner | deutlich brauchbarere Befunde |
„Prüfe diesen Diff auf unbeabsichtigte Verhaltensänderungen an Randfällen” schlägt „prüfe die Qualität” um Längen. Unverzichtbar bleibt der Mensch dort, wo das Repository nichts weiß: Dass eine Sonderbehandlung für den Standort Süd gilt, steht in keinem Quelltext.
Modul: Verifikation und Review von Refactoring-Patches
Sechs Handlungsmöglichkeiten
Die letzte wird am seltensten geprüft und ist die günstigste von allen.
| Möglichkeit | Was sie bedeutet |
|---|---|
| Stabilisieren | nichts umbauen: Tests, Beobachtbarkeit, reproduzierbarer Bau |
| Kapseln | Bestand einschließen, nur über eine saubere Grenze ansprechen |
| Refaktorieren | innere Struktur dort verbessern, wo Änderungsdruck herrscht |
| Migrieren | Technologie oder Plattform austauschen, Fachlichkeit erhalten |
| Ersetzen | abgegrenzten Teil neu bauen, den alten stilllegen |
| Stilllegen | feststellen, dass ein Teil nicht mehr gebraucht wird, und abschalten |
Vorher gehört das Motiv benannt — ein Vorhaben ohne Motiv hat keinen Punkt, an dem es fertig ist.
| Motiv | Woran es sich zeigt |
|---|---|
| Änderungsfähigkeit | Anforderungen sind nicht mehr in vertretbarer Zeit umsetzbar |
| Risiko | keine Sicherheitsaktualisierungen, niemand beherrscht die Technologie |
| Kosten | Betrieb oder Wartung sind unverhältnismäßig teuer |
| Personal | es findet sich niemand mehr, der daran arbeiten will |
Modul: Modernisierungsstrategien auswählen
Beobachtbarkeit zuerst
Sie ändert das Verhalten nicht — deshalb ist sie der einzige Schritt, den man vor der Absicherung machen kann. Und sie liefert nebenbei drei Dinge, die man später ohnehin braucht:
| Nebeneffekt | Wofür er gebraucht wird |
|---|---|
| Aufrufzahlen je Codepfad | die Frage nach totem Code |
| Vorher-Messung | jeder spätere Vergleich alter und neuer Fassung |
| Fehlerhäufigkeiten | die Kritikalitätsachse der Risikomatrix |
Modul: Modernisierungsstrategien auswählen
Migrationen aufteilen
Die Aufteilung lohnt doppelt: Der mechanische Teil ist sicherer, und die Prüfaufmerksamkeit bleibt für die Urteilsfälle.
| Anteil | Verfahren |
|---|---|
| Großer, gleichförmiger Teil | Codemods auf dem Syntaxbaum, deterministisch und wiederholbar |
| Alternativ dazu | Altes als veraltet markieren und den Übersetzerfehlern folgen |
| Kleiner, sperriger Rest | Agent: ungewöhnliche Verwendung, Zusatzlogik, mitzudenkende Kommentare |
Zum Fortschritt gehören zwei Listen. Ohne die zweite bleibt am Ende ein Rest, von dem niemand weiß, ob er vergessen oder Absicht war.
| Liste | Zweck |
|---|---|
| Verbleibende Fundstellen | der messbare Stand, automatisch ermittelt |
| Bewusst nicht migrierte Fälle | mit Begründung, damit der Rest nicht rätselhaft bleibt |
Modul: KI-gestützte Migrationen und großflächige Änderungen
Umkehrbarkeit und Wiederholbarkeit
| Eigenschaft | Praktische Folge |
|---|---|
| Umkehrbarkeit | bei Datenänderungen aufwendiger als ein Rücksprung im Code |
| Umkehrbarkeit | der Rückweg will vorher durchdacht und erprobt sein |
| Wiederholbarkeit | ein abgebrochener oder unvollständiger Lauf wird einfach wiederholt |
| Wiederholbarkeit | bei generativer Umstellung nicht selbstverständlich |
Zwei Läufe desselben Auftrags liefern nicht zwangsläufig dasselbe — ein Argument für den mechanischen Weg. Was generativ entstand, wird einmal geprüft und dann festgeschrieben: Der Commit ist die Referenz, nicht der Auftrag, der ihn erzeugt hat.
Modul: KI-gestützte Migrationen und großflächige Änderungen
Rechtestufen für Agenten
Diese Stufung kostet fast nichts und nimmt der überwiegenden Mehrheit der Aufgaben das Risiko vollständig.
| Stufe | Regel |
|---|---|
| Lesen | die gesamte Erkundung, ohne Ausnahme |
| Schreiben | erst nach Planfreigabe, begrenzt auf ein isoliertes Arbeitsverzeichnis |
| Ausführen | später und mit klaren Grenzen |
| Netzwerk | genau hinsehen — hier können Daten das Haus verlassen |
| Fremde Systeme | grundsätzlich nicht, sondern hinter menschlicher Freigabe |
Vorab gehört festgelegt, was ein Werkzeug überhaupt sehen darf — schriftlich, denn ohne Schriftform entscheidet im Zweifel jeder für sich, meist zugunsten der Bequemlichkeit.
| Datenart | Typische Frage |
|---|---|
| Quellcode | darf er den Rechner verlassen? |
| Produktionsprotokolle | enthalten sie personenbezogene Inhalte? |
| Fehlerberichte | mit Kundendaten oder ohne? |
| Tickets und Kundendokumentation | wer hat sie geschrieben, was steht drin? |
| Bewegungsdaten benannter Personen | eindeutig nein |
Modul: Sicherheit und Governance in Brownfield-Projekten
Kritische Bereiche und Freigaben
| Bereich | Regel |
|---|---|
| Anmeldung und Sitzungsverwaltung | keine selbstständige Änderung |
| Verschlüsselung und Rechteprüfung | Planfreigabe plus Review durch eine zweite Person |
| Alles mit Geldbezug | dasselbe, zusätzlich Vergleichstest gegen die Altfassung |
| Personenbezogene Daten | Datenklassifikation vor jedem Zugriff |
Wer eine bestehende Prüfung entfernen will, muss ihren Ursprung kennen — und den kennt oft niemand. In einem gewachsenen System hat fast jede Prüfung einen Grund; eine Begründung, die nur den Code betrachtet, kann ihn nicht kennen.
| Freigabepflichtig | Der Nachweis beantwortet |
|---|---|
| Datenmigrationen | Wer hat es veranlasst? |
| Änderungen an Verträgen und Formaten | Mit welchem Auftrag? |
| Neue Abhängigkeiten | Unter welchen Rechten? |
| Infrastruktur und jede Auslieferung | Wer hat freigegeben, was wurde geprüft? |
Verantwortlich ist immer die Person, die freigegeben hat. Ein Agent kann nicht haften.
Modul: Sicherheit und Governance in Brownfield-Projekten
Schulden entscheidbar formulieren
Der hässlichste Code ist selten der teuerste. Teuer ist der Code, den man am häufigsten anfasst — und Häufigkeit steht in der Historie, nicht im Quelltext.
| Formulierung | Was sie auslöst |
|---|---|
| „Die Abrechnung ist unwartbar” | Zustimmung, dann nichts |
| „Jede Änderung dauert vier Tage statt einen” | eine Abwägung mit einem Ergebnis |
| „Zweimal Produktionsfehler in sechs Monaten” | eine Priorisierung mit Beleg |
Was ein Backlog-Eintrag mitbringen muss, damit er für sich abschließbar ist:
| Feld | Inhalt |
|---|---|
| Anlass | welche Änderung hat den Bedarf ausgelöst? |
| Ziel | beobachtbar formuliert |
| Voraussetzungen | was muss vorher stehen — Tests, Beobachtbarkeit? |
| Risiko | grob geschätzt, mit Umkehrbarkeit |
Modul: Modernisierung als Teamprozess
Regeln verankern und Wissen sichern
Die dritte Verankerung ist die wirksamste und wird am häufigsten vergessen — ohne sie endet die Migration nie.
| Verankerung | Wirkung |
|---|---|
| Refactoring-Leitplanken als Repository-Anweisung | gelten auch ohne Erwähnung im Auftrag |
| Zielmuster als benannte Referenzstellen im Code | präziser als jede Beschreibung |
| Ausführbare Regel gegen das jeweils Alte | verhindert Nachwachsen während der Migration |
Vier Speicher, die das Wissen über das Vorhaben hinaus tragen. Der Chatverlauf gehört ausdrücklich nicht dazu — er ist Arbeitsmaterial.
| Speicher | Warum er trägt |
|---|---|
| Systemprofile | gepflegt statt einmalig erstellt |
| Entscheidungsnotizen | begründen Weg und verworfene Alternativen |
| Characterization Tests | veralten nicht unbemerkt, weil sie ausgeführt werden |
| Unknowns Register | die offenen Einträge sind die Landkarte fürs nächste Vorhaben |
Modul: Modernisierung als Teamprozess
Fünf Größen für den Fortschritt
| Größe | Was sie beantwortet |
|---|---|
| Verbleibende Fundstellen | Stand einer Migration, eindeutig |
| Änderungsdurchlaufzeit im Bereich | hat die Arbeit gewirkt? |
| Fehler- und Rückrollrate | war sie sicher? |
| Teststabilität | trägt das Sicherheitsnetz? |
| Entwicklung der Hotspots | beruhigt sich die Struktur? |
Keine dieser Zahlen taugt als Vorgabe von außen — als Vorgabe werden sie erreicht statt erfüllt.
Modul: Modernisierung als Teamprozess
Typische Fallen
- Durchhalten, weil schon so viel Arbeit hineingeflossen ist — und den Umfang erhöhen, um wieder lauffähig zu werden.
- Die Abstraktion einführen und gleichzeitig die neue Umsetzung schreiben.
- Logik in die Schutzschicht wandern lassen, bis sie selbst zum Bestand wird.
- „Tests werden nicht angepasst” nicht in den Auftrag schreiben — und die Anpassung im Review übersehen, weil sie plausibel begründet ist.
- Den Review mit dem Code beginnen statt mit den Testdateien.
- Den Migrationslauf nur auf dem kleinen Entwicklungsbestand messen — und den Rückweg planen, aber nie ausprobieren.
- Die Trennung als Ziel setzen statt als mögliches Mittel — und Grenzen nach Technik ziehen statt nach Fachlichkeit.
- Mehrere Hauptversionen in einem Sprung nehmen und die Warnungen der Zwischenversionen verlieren.
- Die Fundstellenzahl als Aufwandsschätzung verwenden.
- Den größten Stapel zuerst nehmen, um schnell voranzukommen — und nach dem Stapel nicht committen.
- Aus Bequemlichkeit mit Vollrechten starten und später einschränken wollen.
- Freigaben erteilen, ohne den Diff gelesen zu haben.
- Regeln in einem Wiki ablegen, das kein Agent liest — oder Checks so streng bauen, dass sie umgangen statt befolgt werden.
- Aus der Hotspot-Liste ein Abarbeitungsprogramm machen.
Zum Seminar KI-gestütztes Refactoring und Legacy-Modernisierung