Zum Danebenlegen, wenn ein Bestandssystem vor Ihnen liegt und die Frage ist, wo man anfängt. Das Blatt sammelt die Raster — Bilanzen, Achsen, Fehlerbilder — aus der ersten Hälfte des Seminars. Es bringt die Methode nicht bei; wie man einen Ablauf verfolgt oder ein Testnetz aufspannt, steht in den Modulen.
Zweiter Teil: Umbauen und modernisieren.
Wert und Belastung
Zwei Bilanzen, die getrennt bleiben müssen — sonst entsteht aus zwei Halbwahrheiten eine Note, die nichts trägt.
| Achse | Woran man sie misst | Typischer Fehlschluss |
|---|---|---|
| Fachlicher Wert | Regeln, Sonderfälle, Datenbestand | „schlechter Code, also wertlos” |
| Technische Belastung | Änderungskosten, Testbarkeit | „läuft doch, also unbedenklich” |
Ein Teil der Sonderregeln ist überholt, ein großer Teil unentbehrlich — vorher weiß man nicht, welcher welcher ist.
Modul: Legacy Code realistisch einordnen
Refactoring, Reparatur, Feature-Änderung
Die Unterscheidung entscheidet, was mit den Tests passieren darf. Beim Refactoring ist jede Änderung an einem Test ein Warnsignal — sie bedeutet, dass Verhalten mitgewandert ist.
| Tätigkeit | Verhalten | Was mit den Tests passiert |
|---|---|---|
| Refactoring | bleibt unangetastet | alle bleiben unverändert grün |
| Reparatur | ändert sich absichtlich | ein Test ändert sich, begründet |
| Feature-Änderung | ändert sich absichtlich | Tests kommen hinzu oder ändern sich |
Für die Grundsatzfrage Migration oder Neubau gibt es drei Bedingungen. Fehlt jede davon, ist die schrittweise Ablösung die begründungsärmere Wahl.
| Bedingung für den Neubau | Warum sie den Ausschlag gibt |
|---|---|
| Plattform läuft aus | schrittweise Erneuerung hat kein Ziel mehr |
| System klein und verstanden | das Wissensrisiko ist beherrschbar |
| Fachlichkeit ändert sich grundlegend | das alte Verhalten ist ohnehin nicht zu erhalten |
Modul: Legacy Code realistisch einordnen
Wo Coding-Agenten tragen
| Bereich | Einschätzung |
|---|---|
| Lesen und Erschließen | stark: Datenflüsse, Verwendungsstellen, Zusammenhänge |
| Tests für vorhandenes Verhalten | stark, aber prüfpflichtig |
| Mechanische Änderung über viele Dateien | stark, wenn Zielmuster und Stapelgröße vorgegeben sind |
| Domänenwissen außerhalb des Repos | schwach: Sonderregel oder Fehler ist nicht ablesbar |
| Großer Umbau in einem Zug | gefährlich: Patch, den niemand mehr prüfen kann |
Die Gefahr entsteht nicht durch schlechte Vorschläge, sondern durch gute Vorschläge in nicht mehr prüfbarer Größe.
Modul: Legacy Code realistisch einordnen
Geschäftsregeln und Hotspots
Wo eine Regel wirklich steht — und was die jeweilige Fundstelle wert ist:
| Fundort | Aussagekraft |
|---|---|
| Code | meist Bedingung ohne Erklärung, aber verbindlich |
| Tests | ehrlichste Dokumentation, weil sie ausgeführt wird |
| Datenbank | Einschränkungen, Standardwerte, tatsächliche Verteilung |
| Dokumentation | letzte Quelle, kann unbemerkt veralten |
Die Versionshistorie beantwortet drei verschiedene Fragen:
| Auswertung | Was sie zeigt |
|---|---|
| Häufig geänderte Dateien | wo sich Investition in Qualität wirklich auszahlt |
| Gemeinsam geänderte Dateien | verborgene Kopplung, Hinweis auf falschen Schnitt |
| Häufung von Fehlerkorrekturen | wo das System die Entwickler regelmäßig überrascht |
Modul: KI-gestützte Code Archaeology
Unknowns Register
Drei Spalten, mehr braucht es nicht. Der Zweck: Eine ungeklärte Frage wird sonst stillschweigend zur Annahme, die Annahme zur Grundlage einer Änderung — und der Irrtum fällt erst in der Produktion auf.
| Offene Frage | Warum sie wichtig ist | Wie zu beantworten |
|---|---|---|
| Warum ab 60 km eine andere Berechnung? | trägt die Abrechnungssumme | Fachbereich fragen |
| Verlässt sich jemand auf das Exportformat? | bestimmt Rückwärtskompatibilität | Buchhaltung fragen |
| Wer nutzt den nächtlichen Abgleich? | bestimmt den Blast Radius | Betrieb, Protokolle |
Das Register wächst beim Erkunden und schrumpft beim Nachfragen — beides ist Fortschritt.
Modul: KI-gestützte Code Archaeology
Verträge und Änderungsflächen
Wer sich auf ein Format verlässt, steht nicht im eigenen Quellcode. Die Frage „wer verlässt sich darauf” gehört deshalb an den Anfang — gestellt an Menschen, nicht ans Repository.
| Grenze | Wer sich darauf verlässt |
|---|---|
| Schnittstellen und Datenformate | aufrufende Systeme, mobile Anwendungen |
| Datenbankschema | Auswertungen und Zugriffe außerhalb des Systems |
| Import- und Exportdateien | die Buchhaltung, seit Jahren dieselbe Spaltenfolge |
| Ereignisse und Nachrichten | Empfänger, die niemand mehr kennt |
| Fehlermeldungen | Nachbarsysteme, die den Text auswerten |
Bei Daten und Schema werden drei Aspekte regelmäßig unterschätzt:
| Aspekt | Was im Bestand passiert |
|---|---|
| Datenqualität | Fahrten ohne Zweck, Kilometerstand null, Buchung ohne Fahrt |
| Dauer | Sekunden auf dem Entwicklungsstand, Stunden mit Sperre in Produktion |
| Umkehrbarkeit | gelöschte Spalten und überschriebene Werte kommen nicht zurück |
Modul: Änderungsflächen und Risiken bestimmen
Blast Radius und Risikomatrix
Wirkung und Umkehrbarkeit ergeben vier Felder mit vier verschiedenen Verfahren. Ein einheitliches Verfahren für alle Änderungen macht Kleinigkeiten teuer und unterschätzt das Riskante.
| Wirkung | Umkehrbarkeit | Vorgehen |
|---|---|---|
| klein | leicht | zügig arbeiten, ausprobieren erlaubt |
| klein | schwer | Phasen, aber kleiner Freigabeaufwand |
| groß | leicht | Rückfallweg vorher erproben, dann liefern |
| groß | schwer | Phasen, Freigaben, erprobter Rückfallplan |
Für die Priorisierung genügen drei Achsen:
| Achse | Leitfrage |
|---|---|
| Kritikalität | Was passiert fachlich, wenn dieser Teil falsch arbeitet? |
| Unsicherheit | Wie viele Einträge stehen dazu im Unknowns Register? |
| Testbarkeit | Wie schnell würden wir merken, dass etwas kaputt ist? |
Kritikalität ist eine fachliche Größe, keine technische. Die Matrix rät nie vom Ändern ab — sie ordnet nur, was zuerst zu tun ist.
Modul: Änderungsflächen und Risiken bestimmen
Nichtdeterminismus im Test
Vier Quellen machen Bestandscode untestbar, und jede hat ihr Gegenmittel. Der nötige Umbau ist begründbar, weil ohne ihn gar nichts absicherbar wäre — aber er bleibt ein Umbau am ungesicherten Code.
| Quelle | Gegenmittel |
|---|---|
| Die Uhr | Zeit von außen hineinreichen statt im Code abfragen |
| Zufall und erzeugte Kennungen | Erzeugung austauschbar machen, Werte festlegen |
| Dateisystem | Pfade konfigurierbar, Rechte im Test kontrolliert |
| Fremde Systeme | Zugriff hinter eine ersetzbare Stelle legen |
Für Testdaten gibt es zwei gangbare Wege. Der zweite hat einen unterschätzten Vorteil: Beim Erzeugen muss man die Regeln des Datenbestands verstehen.
| Weg | Was zu beachten ist |
|---|---|
| Anonymisierung | bei Bewegungsdaten schwer: wenige Fahrten identifizieren eine Person |
| Erzeugte Daten | müssen die Eigenschaften des Bestands nachbilden, auch die schrägen |
Modul: Characterization Tests und Sicherheitsnetz
KI-generierte Tests prüfen
Vier Fehlerbilder, an denen generierte Tests im Bestand scheitern. Das dritte ist das teuerste: Ein Netz, das bei jedem Umbau reißt, wird nach kurzer Zeit ignoriert.
| Fehlerbild | Folge |
|---|---|
| Schreibt fest, was der Code tun sollte | rot von Anfang an — oder grün aus dem falschen Grund |
| Prüft Belanglosigkeiten | Netz sieht dicht aus und fängt nichts |
| Klammert sich an Interna | jeder Umbau bricht die Tests, man zieht ständig nach |
| Hält einen Fehler unmarkiert fest | richtig im Sinn der Methode, aber niemand weiß davon |
Die Gegenprobe ist eine absichtliche Veränderung im Produktivcode: Wird ein Test dabei nicht rot, prüft er nichts — unabhängig davon, wie gut er aussieht.
Modul: Characterization Tests und Sicherheitsnetz
Ziele und Invarianten
Ein Agent mit beobachtbarem Ziel arbeitet darauf zu. Einer mit „sauberer” begrenzt den Umfang nach eigener Einschätzung.
| Vage Formulierung | Beobachtbares Ziel |
|---|---|
| „Abrechnung sauberer machen” | Die Abrechnung ist ohne laufende Datenbank testbar |
| „Trennung verbessern” | Eine Formatänderung berührt die Steuerlogik nicht mehr |
| „Magische Zahlen entfernen” | Die 60-Kilometer-Regel steht an einer Stelle, mit Namen |
Jede Invariante braucht einen Nachweis. Was sich nicht an einen binden lässt, ist keine Invariante, sondern eine Hoffnung.
| Invariante | Nachweis |
|---|---|
| Die Exportdatei bleibt zeichengleich | Golden-Master-Prüfung |
| Privatnutzung: dieselben Beträge | die zwanzig festgehaltenen Fälle |
| Öffentliche Schnittstellen unverändert | Signaturvergleich im Bau |
| Monatslauf bleibt in seiner Laufzeit | Messung des Laufs vorher und nachher |
Modul: Refactoring-Ziele und Leitplanken
Grundrepertoire und Schrittgröße
Fünfzehn kleine Schritte hintereinander leisten mehr als ein großer Wurf — und jeder einzelne ist rücknehmbar.
| Schritt | Wirkung |
|---|---|
| Umbenennen | macht Verstandenes im Code sichtbar |
| Ausdruck in benannte Variable heben | erklärt eine Bedingung ohne Kommentar |
| Abschnitt in eigene Funktion herausziehen | schafft einen Testpunkt |
| Parameter einführen | löst eine versteckte Abhängigkeit auf |
| Verschachtelung durch Abbruchbedingung ersetzen | senkt die Tiefe, nicht das Verhalten |
Warum die Vereinzelung in den Auftrag gehört: Ein Agent sieht die Zusammenhänge und hat keinen Anlass, künstlich zu trennen — jeder zusätzliche Schritt kostet ihn nichts, der Preis fällt beim Prüfenden an.
| Schrittgröße | Ein Test bricht | Folge |
|---|---|---|
| Ein Refactoring | Ursache in Sekunden klar | weitermachen |
| Fünf vermischte Schritte | Suche dauert länger als der Umbau | endet oft im Verwerfen |
Verworfen werden dann auch die vier Schritte, die in Ordnung waren.
Modul: Kleine, verhaltenserhaltende Refactorings
Werkzeug oder Agent
| Zuständig | Aufgabe |
|---|---|
| Werkzeug | Umbenennen, Extrahieren, Signatur ändern — mechanisch und vollständig |
| Agent | beurteilen, welcher Name der richtige ist |
| Agent | wo die Grenze einer herauszulösenden Funktion sinnvoll liegt |
| Agent | ob zwei Duplikate dieselbe fachliche Regel sind |
Typische Fehler generativer Umbenennung: ein Vorkommen übersehen, eine gleichnamige Variable mitgefasst.
Modul: Kleine, verhaltenserhaltende Refactorings
Typische Fallen
- Alter mit Sanierungsbedarf gleichsetzen — die Belastung misst man an den Änderungskosten, nicht an der Codeoptik.
- Aufräumen, wo seit Jahren niemand etwas ändert — Änderungsdruck kommt aus der Historie, nicht aus dem Bauchgefühl.
- Eine plausible Erklärung für einen Beleg halten — und die Erkundung mit Schreibrechten beauftragen, obwohl Lesen genügt.
- „Tests vorhanden” notieren, ohne sie laufen gelassen zu haben.
- Ein Suchergebnis als vollständige Liste der Verwendungsstellen behandeln — Konfigurationsdateien und dynamische Mechanismen fehlen darin.
- Umkehrbarkeit annehmen, ohne den Rückweg je gegangen zu sein.
- Den Test das gewünschte statt das beobachtete Verhalten festhalten lassen — eine Rundung „geradeziehen”, weil sie unsauber aussieht.
- Produktionsdaten „nur kurz” in die Entwicklungsumgebung ziehen — und Namen ersetzen für Anonymisierung halten.
- Beim Umbau „schnell noch” einen Fehler mitkorrigieren oder einen Test anpassen, damit der Umbau grün wird.
- Benennen, bevor man die Regel verstanden hat — der Name zementiert dann den Irrtum.
- Mechanische Umbauten generativ ausführen lassen, weil es bequemer ist.
- Löschungen auf eine rein statische Suche stützen — ein jährlich genutzter Pfad ist nach zwei Wochen Beobachtung nicht tot.
Zum Seminar KI-gestütztes Refactoring und Legacy-Modernisierung