KI-gestütztes Codeverständnis und Refactoring

KI-gestütztes Codeverständnis und Refactoring

0:00 Das zehnte Modul wendet sich dem Bestand zu. Bisher ging es überwiegend um neue Änderungen — jetzt geht es um Code, den Sie vorfinden und nicht geschrieben haben. Zwei Themen gehören dabei zusammen: verstehen und umbauen. Und es gibt eine Frage, die über beides entscheidet: Woran würde ich merken, dass ich etwas kaputt gemacht habe?

0:20 Wer darauf keine Antwort hat, betreibt kein Refactoring, sondern ein Glücksspiel. Das ist keine Zuspitzung, sondern die Definition des Begriffs.

KI-gestütztes Codeverständnis und Refactoring

0:30 Willkommen zum dritten Tag. Er dreht sich um den Bestand, um Sicherheit und um die Zusammenarbeit im Team — also um alles, was über die einzelne Änderung hinausgeht. Und dieses Modul hat eine Besonderheit: Es endet an einer Stelle, an der bewusst aufgehört wird. Was danach kommt, ist Gegenstand des Aufbauseminars, in dem dieselbe Anwendung als gewachsenes Bestandssystem wiederkehrt.

Fremden Code mit KI erkunden

0:53 Beginnen wir mit dem Erkunden. Das ist der risikoärmste und einer der wertvollsten Einsatzzwecke überhaupt — rein lesend, sofort nützlich, und genau die Arbeit, die Menschen am meisten Zeit kostet. Wirksam wird sie allerdings erst durch die richtige Reihenfolge der Fragen. Die falsche Reihenfolge liefert eine hübsche Übersicht, mit der niemand etwas anfangen kann.

1:14 Der entscheidende Hebel ist die Reihenfolge, in der Sie fragen. Und es gibt einen Grundsatz, der alles andere überstrahlt: Ein Vorgang, verfolgt von Anfang bis Ende, erklärt ein System besser als jede Gesamtübersicht. Beim Fahrtenbuch heißt das: Was passiert von der Buchung bis zur Zeile in der Abrechnung? Diesen Weg können Sie nachprüfen — Datei für Datei, Schritt für Schritt.

1:37 Eine Gesamtübersicht können Sie nicht nachprüfen. Sie klingt nur gut. Fünf Schritte, und die Reihenfolge ist der Inhalt. Zuerst die Einstiegspunkte: Wo beginnt die Ausführung, welche Wege führen von außen hinein? Dann der Datenfluss entlang eines konkreten fachlichen Vorgangs. Dann die Abhängigkeiten nach außen — Datenbank, Fremdsysteme, Dateien, Zeit.

1:59 Zeit wird dabei fast immer vergessen und ist eine der häufigsten Ursachen für schwer reproduzierbare Fehler. Und zuletzt die Stellen, an denen Zustand entsteht oder Nebenwirkungen auftreten. Der fünfte Punkt fasst zusammen: einen Vorgang ganz verfolgen, statt eine Übersicht zu verlangen. Der erste Punkt ist der verbreitetste: nach einer Architekturübersicht fragen und sie dann für geprüft halten. Sie ist nicht geprüft, sie ist erzählt.

2:26 Der zweite betrifft die Reihenfolge — wer mit den Abhängigkeiten beginnt, sieht die Technik und nicht die Fachlichkeit. Der dritte: Zustand und Nebenwirkungen fallen hinten runter, weil man vorher schon zufrieden war. Und der vierte ist ein Berechtigungsfehler, auf den wir in Modul elf zurückkommen: Erkunden mit Schreibrechten beauftragen, obwohl Lesen genügt.

Vermutungen gegen den Quellcode prüfen

2:47 Jetzt zum Umgang mit dem, was dabei herauskommt. Jede Erklärung eines Assistenten ist eine Hypothese — und Hypothesen werden nicht geglaubt, sondern geprüft. Das klingt selbstverständlich und wird trotzdem übergangen, weil die Erklärungen souverän klingen. Besonders eine Sorte Aussage verdient Misstrauen. Und sie ist ausgerechnet die Sorte Aussage, die im Alltag am meisten Gewicht bekommt.

3:11 Verlangen Sie für jede tragende Aussage einen Beleg — Datei, Symbol, Zeile — und nehmen Sie Stichproben. Und dann gibt es eine Sorte Aussage, bei der besondere Wachsamkeit angebracht ist: Aussagen, die etwas ausschließen. Diese Funktion wird nirgends sonst verwendet — das ist eine Behauptung mit Folgen, und sie ist häufig falsch.

3:32 Der Grund ist grundsätzlich: Dynamische Aufrufe, Konfiguration und zur Laufzeit gebildete Namen lassen sich durch Lesen nicht finden. Von niemandem. Drei Belegarten, und sie kosten unterschiedlich viel. Der Quellcode mit Fundstelle ist prüfbar, aber blind für alles Dynamische — eine Stichprobe genügt. Ein Test ist der bequemste Beleg: Was ein Test festhält, ist überprüfbar wahr, und er liegt meist schon da.

3:57 Und die dritte Zeile ist die, die viele unterschätzen: die Ausführung selbst. Eine Protokollzeile an der fraglichen Stelle beantwortet in dreißig Sekunden, was eine halbe Stunde Lesen offenlässt. Das ist kein Notbehelf, das ist oft der schnellste Weg. Vier Punkte dazu. Eine halbe Stunde Lesen lässt offen, was eine Protokollzeile sofort beantwortet — das ist ein schlechtes Verhältnis.

4:21 Und der Beleg ist dann kein Argument mehr, über das sich diskutieren ließe, sondern eine Beobachtung. Bei ausschließenden Aussagen ist die Ausführung sogar der einzige belastbare Weg, weil Lesen die Frage prinzipiell nicht beantworten kann. Und der vierte Punkt ist die Warnung: Wer keinen Beleg verlangt, übernimmt die Hypothese als Tatsache, ohne es zu merken.

Code Smells als Hinweis, nicht als Auftrag

4:42 Jetzt zu einer Verlockung, der viele erliegen. Ein Assistent produziert auf Bitte mühelos eine Liste von Auffälligkeiten — lange Funktionen, tiefe Verschachtelung, Duplikate, sprechlose Namen. Diese Liste sieht nach Arbeitsvorrat aus. Sie abzuarbeiten ist trotzdem meist falsch, und der Grund hat mit Risiko zu tun. Denn nicht jede Auffälligkeit ist ein Problem, das gelöst werden will.

5:07 Ein Smell ist ein Hinweis, dass es sich lohnen könnte, genauer hinzusehen. Mehr nicht. So war der Begriff auch gemeint, als Kent Beck und Martin Fowler ihn eingeführt haben — ausdrücklich als Indikator, nicht als Diagnose. Ob sich das Aufräumen lohnt, entscheidet sich an ganz anderen Fragen. Und das Neue an der heutigen Lage ist: Früher kostete das Erstellen einer solchen Liste Mühe, das begrenzte sie. Heute kostet es einen Satz.

5:33 Der Filter muss deshalb ausdrücklich gesetzt werden. Drei Fragen, und wenn alle drei mit Nein beantwortet werden, lautet die Antwort: nicht anfassen. Wird dieser Code überhaupt geändert? Steht eine Änderung an, die er behindert? Ist er durch Tests abgesichert, sodass ein Umbau verantwortbar wäre? Der fünfte Punkt formuliert die Konsequenz: Eine lange, hässliche Funktion, die seit fünf Jahren unverändert läuft und niemanden stört, ist kein Problem.

6:01 Sie ist ein gelöstes Thema. Sie anzufassen bringt Risiko ohne Ertrag — der Änderungsdruck ist die entscheidende Größe, nicht die Zahl der Auffälligkeiten. Der erste Punkt ist die eben beschriebene Verlockung: die Smell-Liste als Arbeitsvorrat behandeln, weil sie so konkret aussieht. Der zweite ist die Arbeit ohne Änderungsdruck — reine Risikoerzeugung. Der dritte ist der gefährlichste: umbauen, wo keine Tests absichern.

6:26 Das ist per Definition kein Refactoring, und darauf kommen wir gleich. Und der vierte ist ein Denkfehler, der auch bei anderen Metriken auftritt: Die Zahl der Befunde für ein Maß der Dringlichkeit halten. Sie misst nur, wie gründlich gesucht wurde.

Verhalten absichern, bevor es sich ändert

6:42 Damit zur Kernfrage jedes Umbaus, und sie ist erfreulich kurz: Woran würde ich merken, dass ich etwas kaputt gemacht habe? Gibt es darauf keine Antwort, sollten Sie nicht anfangen. Denn dann fehlt genau das, was Refactoring von einer Verhaltensänderung unterscheidet. Ohne diese Antwort fehlt die Grundlage für alles Weitere in diesem Kapitel.

7:02 Refactoring heißt, die innere Struktur zu ändern, ohne das äußere Verhalten zu ändern. Und ich möchte betonen: Das ist nicht eine Eigenschaft besonders guter Refactorings. Das ist die Definition. Wer sie ernst nimmt, merkt sofort, dass sie eine Behauptung enthält — nämlich die, dass sich das Verhalten nicht geändert hat.

7:22 Und Behauptungen brauchen Belege. Ohne Absicherung ist der Umbau kein Refactoring, sondern ein Glücksspiel mit unbekanntem Einsatz. Ein Umbau ohne Absicherung ist deshalb kein schlechtes Refactoring, sondern gar keins. Vier Punkte, und der zweite und dritte sind die eigentlich wichtigen. Ein Characterization Test hält fest, was das System heute tut — ohne zu behaupten, dass es richtig ist.

7:46 Und wenn Ihnen dabei etwas offensichtlich Falsches begegnet, halten Sie es trotzdem zunächst fest. Das ist kontraintuitiv, und der Grund steht im dritten Punkt: Vielleicht verlässt sich jemand darauf. Die Korrektur ist eine eigene Entscheidung mit eigenem Auftrag, und sie kommt nach dem Umbau, nicht mittendrin. Sonst ändern Sie zwei Dinge gleichzeitig und wissen hinterher nicht, welches den Fehler verursacht hat.

8:10 Der erste Punkt ist der, gegen den man sich am meisten wehren muss: beim Charakterisieren gleich mitkorrigieren, was falsch aussieht. Der zweite ist die subtile Variante davon — den Test das gewünschte statt das beobachtete Verhalten festhalten lassen. Dann ist er von Anfang an rot, und Sie haben nichts abgesichert. Der dritte ist der grundsätzliche: ohne Absicherung umbauen und es trotzdem Refactoring nennen.

8:34 Und der vierte fasst zusammen: Trennen Sie Umbau und Korrektur, immer.

Refactoring-Ziel, Invarianten und Scope

8:39 Jetzt zum Auftrag selbst. Und ich fange mit dem unbrauchbarsten an, den ein Agent bekommen kann: Mach das mal sauber. Der Grund, warum er nicht funktioniert, führt direkt zurück zu Modul vier — es fehlt ein Erfolgskriterium. Vier Angaben machen daraus einen tragfähigen Auftrag. Denn ein Auftrag ohne Erfolgskriterium lässt sich weder erfüllen noch verfehlen.

9:02 Mach das mal sauber enthält kein Erfolgskriterium. Und daraus folgt etwas Bemerkenswertes: Jedes Ergebnis erfüllt diesen Auftrag, und keines lässt sich abnehmen. Sie können hinterher weder sagen, dass es gelungen ist, noch dass es misslungen ist. Genau das ist der Zustand, in dem Diskussionen über Geschmack entstehen — und niemand kann sie entscheiden.

9:23 Vier Angaben lösen das auf, und die vierte davon fehlt in der Praxis fast immer. Sehen wir sie uns im Einzelnen an, jeweils mit einem Beispiel aus dem Fahrtenbuch. Sehen Sie sich die Beispiele in der rechten Spalte an, sie machen den Unterschied greifbar. Das Ziel als beobachtbare Verbesserung: Die Abrechnung soll ohne Datenbank testbar sein.

9:44 Das kann man nachher prüfen. Die Invarianten: Die Beträge je Zweck ändern sich nicht — und ausdrücklich mit der Angabe, woran das gemessen wird. Der Scope: nur das Abrechnungsmodul, die Buchung nicht. Und das Abbruchkriterium: mehr als zehn Dateien betroffen, dann abbrechen und neu planen. Diese vierte Zeile fehlt fast immer und ist bei Umbauten die wichtigste, denn ein Refactoring, das größer wird als gedacht, ist der Normalfall.

10:11 Der erste Punkt ist die Formulierungsfalle: das Ziel als Eigenschaft angeben — wartbarer, sauberer — statt als beobachtbare Verbesserung. Der zweite ist die halbe Invariante: Man benennt, was gleich bleiben soll, aber nicht, woran man das misst. Der dritte ist der offene Scope, über dessen Folgen man sich dann wundert. Und der vierte ist der schwerwiegendste: ohne Abbruchkriterium starten.

10:34 Dann arbeiten Sie sich in einen halbfertigen Umbau hinein, aus dem es keinen billigen Ausweg gibt.

Inkrementell mit kleinen Diffs

10:40 Jetzt zur Durchführung, und hier gilt ein Satz, den ich für den nützlichsten dieses Moduls halte: Umbauten misslingen fast nie an der Idee und fast immer an der Schrittgröße. Die Idee ist meistens richtig. Was schiefgeht, ist die Portionierung — und das lässt sich beheben. Und sie lässt sich beheben, ohne dass jemand besser programmieren muss.

11:00 Die Regel ist unspektakulär: ein Refactoring pro Schritt, nach jedem Schritt Tests und Diff, nach jedem gelungenen Schritt ein Commit. Das klingt nach Pedanterie und ist der einzige Weg, der zuverlässig trägt. Der Grund liegt in der Fehlersuche, und den sehen wir uns gleich in Zahlen an. Kurz gesagt: Die Kosten der Fehlersuche wachsen nicht linear mit der Schrittgröße, sondern deutlich schneller. Deshalb zahlt sich das Zerlegen so stark aus.

11:27 Zwei Zeilen, und der Unterschied ist dramatisch. Bricht nach einem einzelnen Refactoring ein Test, ist die Ursache in Sekunden gefunden — Sie haben ja nur eine Sache geändert. Bricht ein Test nach einem Umbau über vierzig Dateien, beginnt eine Suche, die leicht länger dauert als der ganze Umbau. Und die häufig damit endet, dass alles verworfen wird, weil niemand mehr weiß, welcher der vierzig Schritte schuld war.

11:50 Der Hinweis unten ist der praktisch wichtigste: Bei agentischer Arbeit muss die Schrittgröße ausdrücklich vorgegeben werden. Der Grund ist derselbe wie in Modul fünf und hat nichts mit Nachlässigkeit zu tun. Ein Agent sieht den Zusammenhang und hat keinen Grund, ihn in Etappen zu zerlegen — aus seiner Sicht ist die große Lösung die elegantere.

12:10 Jeder zusätzliche Schritt kostet ihn nichts, während der Preis beim Prüfenden anfällt. Ein Anreiz, der so verteilt ist, korrigiert sich nicht von selbst. Deshalb gehört die Schrittgröße in den Auftrag und nicht in die Hoffnung. Und der Commit nach jedem gelungenen Schritt gehört dazu, sonst ist der Rückweg wieder lang.

Wann ein Refactoring zu groß wird

12:28 Zum letzten fachlichen Kapitel, und hier hört dieses Seminar bewusst auf. Es gibt Umbauten, die sich auf dem direkten Weg nicht in kleine, jeweils lauffähige Schritte zerlegen lassen. Das Erkennungszeichen dafür ist einfach — und wichtig ist vor allem, was Sie dann tun. Denn die richtige Reaktion darauf ist unintuitiv und muss geübt werden.

12:49 Das Erkennungszeichen: Man beginnt, nichts baut mehr, und der Weg zurück zu einem lauffähigen Zustand ist lang. Wenn Sie sich in diesem Zustand wiederfinden, ist das keine Frage von Durchhaltevermögen. Es ist ein Hinweis darauf, dass die Reihenfolge falsch gewählt war. Der Reflex, jetzt erst recht weiterzumachen, führt tiefer hinein — und mit jeder Stunde wird der Rückzug teurer, weil mehr Arbeit darin steckt.

13:13 Sie kennen diesen Mechanismus aus Modul neun. Fünf Schritte. Nicht weitermachen. Zurückgehen auf den letzten lauffähigen Stand. Die Reihenfolge ändern, nicht den Umfang erhöhen — das ist der entscheidende Punkt, denn der Reflex geht in die andere Richtung. Und dann die Technik der Schritte vier und fünf: die Zieländerung rückwärts in ihre Voraussetzungen zerlegen, bis eine übrig bleibt, die sich sofort und gefahrlos erledigen lässt.

13:39 Das ist der Kern des Aufbauseminars und wird dort ausgeführt. Für die Grundlagen genügt es, den Punkt zu erkennen und den Rückzug anzutreten. Der erste Punkt ist die Sunk-Cost-Falle in ihrer akuten Form: weitermachen, weil schon so viel Arbeit hineingeflossen ist. Der zweite ist die typische Fehlreaktion — den Umfang erhöhen, um wieder lauffähig zu werden. Das funktioniert manchmal und endet meist schlechter.

14:04 Der dritte ist ein handwerklicher: den Zustand gar nicht bemerken, weil zwischendurch nie gebaut wurde. Bauen Sie oft. Und der vierte ist eine Haltungsfrage: Der Rückzug ist kein Scheitern, er ist eine Reihenfolgekorrektur.

Übung: Absichern und schrittweise refaktorieren

14:18 Zum Abschluss die Übung, in der Sie beides zusammenbringen — absichern und umbauen. Sie nehmen sich die Berechnung der Privatnutzung im Fahrtenbuch vor: eine lange Funktion ohne Tests, mit mehreren nackten Zahlenwerten und einer Regel, die nirgends dokumentiert ist. Also genau der Fall, für den dieses Modul gedacht ist. Der schwerste Teil dieser Übung ist nicht der Umbau, sondern der zweite Schritt.

14:41 Sie sollen ausdrücklich festhalten, welche Ergebnisse Ihnen fachlich falsch vorkommen — und sie trotzdem nicht ändern. Das kostet Überwindung, und genau deshalb üben wir es. Danach formulieren Sie einen Auftrag mit allen vier Angaben, führen ihn in Schritten aus und prüfen nach jedem Schritt. Ein Hinweis zur Einordnung: Die Sechzig-Kilometer-Regel ist eine didaktische Erfindung dieses Seminars und keine steuerliche Aussage.

15:06 Anderthalb Stunden, fünf Schritte. Charakterisieren, Auffälligkeiten notieren ohne zu ändern, Auftrag formulieren, in Schritten ausführen, prüfen. Und dann die Schlussfrage, die ich für die interessanteste halte: An welcher Stelle hätten Sie das Abbruchkriterium beinahe gebraucht? Meine Erwartung ist, dass die meisten Gruppen einen solchen Punkt finden werden — und dass er früher kommt, als sie denken. Genau dort setzt das Aufbauseminar an.

15:31 Und halten Sie fest, woran Sie den Punkt erkannt hätten — diese Beobachtung ist übertragbar, die Aufgabe selbst nicht.