Refactoring-Ziele und Leitplanken

Refactoring-Ziele und Leitplanken

0:00 Guten Morgen zum zweiten Tag. Gestern haben wir verstanden und abgesichert — ab heute verändern wir. Und wir fangen nicht mit Code an, sondern mit dem Auftrag. Das hat einen sehr praktischen Grund: Der häufigste Auftrag für einen Umbau lautet „mach das mal sauber“, und mit dem kann niemand kontrolliert arbeiten — weder ein Mensch noch ein Agent.

0:21 Er enthält kein Erfolgskriterium: Jedes Ergebnis erfüllt ihn, und keines lässt sich abnehmen. In diesem Modul bauen wir aus so einem Satz einen Auftrag, der trägt. Er hat sechs Bestandteile, und einer davon fehlt fast immer.

Refactoring-Ziele und Leitplanken

0:35 Der zweite Tag hat einen klaren Bogen: Auftrag, Handwerk, Planung, Prüfung. Wir fangen mit dem Auftrag an, weil alles Weitere daran hängt. Die Reihenfolge in diesem Modul folgt der Reihenfolge, in der Sie einen Auftrag auch schreiben würden: Warum überhaupt, was ist das Ziel, was darf sich nicht ändern, was ist tabu, wann ist Schluss und wann brechen wir ab.

0:55 Danach kommen zwei Kapitel über den Ablauf — Phasentrennung und Repository-Anweisungen. Und am Ende schreiben Sie selbst einen Auftrag und lassen ihn von einer anderen Gruppe zerpflücken.

Refactoring braucht einen Anlass

1:06 Bevor wir über den Inhalt eines Auftrags reden, die Vorfrage: Soll überhaupt umgebaut werden? Die Antwort ist häufiger nein, als man erwartet — und sie ist unter agentischen Werkzeugen schwieriger geworden. Es gibt genau zwei tragfähige Anlässe. Der erste ist Änderungsdruck: Hier soll etwas gebaut werden, und der jetzige Zustand steht im Weg.

1:27 Das ist die Fortsetzung des Gedankens aus Modul eins — Legacy ist eine Beziehung, und der Anlass entsteht aus dem Vorhaben. Der zweite ist ein benannter Qualitätszweck, zum Beispiel Testbarkeit herzustellen, bevor eine riskante Änderung ansteht. Fehlt beides, fehlt der Auftrag. Das fällt schwer, wenn man gerade eine Liste von Auffälligkeiten vor sich hat — und es bleibt trotzdem richtig.

1:52 Hier ist etwas passiert, das die alte Abwägung verschiebt. Früher war Aufräumen teuer: Es kostete Entwicklerzeit, und diese Zeit fehlte woanders. Das war eine natürliche Bremse. Heute kostet das Aufräumen technisch fast nichts mehr — der Agent macht es in zehn Minuten. Und daraus schließen viele, dass man es dann auch ruhig machen kann.

2:12 Der Trugschluss steckt im zweiten Punkt: Der Aufwand ist nicht verschwunden, er hat sich verlagert. Er liegt jetzt vollständig beim Menschen, der den Patch prüfen und verantworten muss. Und diese Prüfkapazität ist knapp geblieben. Der erste Punkt schließt an Modul eins an: Eine Liste von Auffälligkeiten ist kein Anlass. Sie ist Material.

2:33 Der zweite ist die neue Variante, die ich seit etwa zwei Jahren regelmäßig höre — „kostet den Agenten ja nichts“. Die Antwort darauf steht auf der vorigen Folie. Der vierte ist der menschlichste: Aus schlechtem Gewissen umzubauen. Das kommt vor, wenn jemand den Code selbst geschrieben hat und heute anders schreiben würde.

2:53 Verständlich — nur ist das kein Anlass, sondern ein Gefühl.

Zielzustand als beobachtbare Verbesserung

2:57 Angenommen, der Anlass steht. Dann brauchen wir ein Ziel. Und hier entscheidet sich, ob der Auftrag trägt — an der Frage, ob man das Eintreten des Ziels feststellen kann. „Sauberer“ ist kein Ziel, weil es keinen Zustand beschreibt, an dem man ankommt. Sie können immer noch sauberer werden. Ein brauchbares Ziel ist beobachtbar: Man kann nachsehen, ob es eingetreten ist. Das hat zwei Wirkungen, und die zweite ist die wichtigere.

3:25 Es ist abnehmbar — Sie oder ein Agent können am Ende nachprüfen, ob das Ziel erreicht wurde. Und es ist begrenzend: Ein präzises Ziel sagt implizit auch, was nicht dazugehört. Damit erledigt sich ein guter Teil der Umfangsdiskussion von selbst. Achten Sie auf den Unterschied zwischen den beiden Spalten — er ist nicht sprachlicher Natur.

3:46 Die linke Spalte beschreibt eine Eigenschaft, die rechte einen Zustand, den man herstellen und prüfen kann. „Die Abrechnung ist ohne laufende Datenbank testbar“ können Sie ausprobieren: Sie starten den Test ohne Datenbank und sehen, was passiert. Bei „sauberer machen“ gibt es nichts auszuprobieren. Und die Fußzeile beschreibt die praktische Konsequenz für die agentische Arbeit: Ein Agent mit beobachtbarem Ziel arbeitet darauf zu und hört auf, wenn er es erreicht hat.

4:13 Einer mit „sauberer“ hört auf, wenn er meint, genug getan zu haben. Der erste Punkt ist der Klassiker: „Der Code soll wartbarer werden“ ist eine Eigenschaft, kein Zustand. Der zweite ist eine Falle für Gründliche — man packt drei Ziele in einen Auftrag, und am Ende ist eines erreicht, eines halb und eines gar nicht. Ein Ziel pro Auftrag.

4:34 Der dritte klingt trivial und ist es nicht: Prüfen Sie, ob überhaupt jemand feststellen könnte, dass das Ziel eingetreten ist. Wenn Ihnen dazu nichts einfällt, ist es kein Ziel — und Sie merken das jetzt statt in drei Wochen.

Invarianten benennen

4:48 Das Ziel sagt, was sich ändern soll. Jetzt kommt das Gegenstück: Was darf sich auf keinen Fall ändern? Und hier gibt es eine formal richtige Antwort, die in der Praxis vollkommen nutzlos ist. Die formale Antwort lautet: das gesamte beobachtbare Verhalten. Damit ist die Sache definitorisch erledigt und praktisch gar nicht — denn diese Aussage ist nicht prüfbar.

5:10 Sie können nicht „das gesamte beobachtbare Verhalten“ nachweisen. Nützlich wird die Antwort erst, wenn Sie sie konkretisieren und an Nachweise binden. Nicht „das Verhalten bleibt gleich“, sondern: diese Datei bleibt zeichengleich, nachgewiesen durch jenen Test. Damit wird aus einem Prinzip eine Prüfliste — und die kann am Ende jemand abhaken.

5:32 Das Prinzip dieser Tabelle steckt in der zweiten Spalte: Jede Invariante zeigt auf etwas, das man ausführen oder messen kann. Die erste bezieht sich auf den Golden Master aus Modul vier, die zweite auf die gezielten Regeltests. Die dritte zeigt auf einen Vergleich im Bau. Und die vierte ist die, an die kaum jemand denkt: die Laufzeit.

5:51 Laufzeit fühlt sich nicht wie Verhalten an, ist aber für einen Monatslauf durchaus eines — wenn er statt zwanzig Minuten plötzlich vier Stunden braucht, ist etwas kaputt. Die Fußzeile ist die Regel dahinter: Was Sie nicht an einen Nachweis binden können, ist keine Invariante, sondern eine Hoffnung. Der erste Punkt ist der häufigste: Invarianten werden benannt, aber nicht gebunden. Das liest sich gut und hilft im Review nicht.

6:17 Der zweite ist die unangenehme Variante davon — man beruft sich auf Tests, die es für diese Stelle gar nicht gibt. Deshalb kam Modul vier vor diesem Modul. Der vierte beschreibt die typische Reihenfolge im Alltag: Erst wird umgebaut, dann sucht man die Nachweise. Da ist es zu spät, denn Sie haben nichts mehr, womit Sie den Zustand vorher belegen könnten.

Scope, Nicht-Ziele und Patchgröße

6:38 Jetzt zu den Begrenzungen. Und hier gilt ein einfaches Prinzip: Was mechanisch formuliert ist, lässt sich überprüfen. Was als Haltung formuliert ist, nicht. Der Scope legt fest, welche Dateien und Verzeichnisse angefasst werden dürfen — und welche ausdrücklich nicht. Dazu gehört eine Zahl: Wie viele Dateien darf ein Schritt berühren?

7:00 Und dazu gehören die fachlichen Nicht-Ziele: keine Verhaltensänderung, keine Fehlerkorrektur nebenbei, keine Formatierung nicht betroffener Dateien. Das klingt kleinlich, und genau darin liegt der Wert: Diese Vorgaben können Sie prüfen, ohne zu diskutieren. Sie stehen im Diff oder sie stehen nicht darin. Gehen wir die fünf durch, wobei zwei besondere Aufmerksamkeit verdienen. Schritt zwei ist die Zahl — und ohne Zahl ist die Begrenzung Verhandlungssache.

7:28 „Kleine Schritte“ bedeutet für Sie fünf Dateien und für einen Agenten vielleicht fünfzig. Schreiben Sie hin, welche Zahl gilt. Schritt drei ist die stille Voreinstellung, an die man selten denkt: Im Regelfall kommt keine neue Abhängigkeit hinzu. Ein Agent fügt gern eine Bibliothek hinzu, wenn sie das Problem elegant löst — und Sie haben dann eine Lieferkettenentscheidung getroffen, ohne es zu merken.

7:51 Ich will bei diesem scheinbar nebensächlichen Punkt einen Moment bleiben, weil er das ganze Sicherheitskonzept dieses Seminars trägt. Alles, was wir hier machen — kleine Schritte, Diff-first, Review — ruht auf einer einzigen Voraussetzung: dass ein Mensch den Diff tatsächlich liest. Eine Änderung, die zusätzlich hundert Zeilen umformatiert, ist nicht mehr sinnvoll lesbar.

8:13 Was dann passiert, ist vorhersehbar: Der Prüfende scrollt, findet nichts Auffälliges und nickt ab. Die Formatierung hat nichts kaputt gemacht — sie hat nur Ihre Prüfung ausgeschaltet.

Definition of Done und Abbruchkriterien

8:24 Zwei Festlegungen fehlen in fast jedem Auftrag, den ich sehe. Die erste ist bekannt und wird oft schlampig formuliert. Die zweite ist die wichtigere — und sie kommt praktisch nie vor. Fertig heißt: Das beobachtbare Ziel ist erreicht, alle Invarianten sind nachgewiesen, die automatischen Prüfungen laufen durch, und der Diff wurde gelesen.

8:45 Vier Punkte, alle prüfbar. Was ausdrücklich nicht gemeint ist: fertig, wenn nichts mehr zu verbessern wäre. Dieser Zustand tritt nie ein. Bei jedem Umbau finden Sie am Ende drei weitere Stellen, die man auch noch angehen könnte — und wenn das Ihr Kriterium ist, hört der Umbau nie auf, sondern nur die Geduld der Beteiligten.

9:05 Jetzt zum wichtigeren Teil. Warum vorher festlegen, wann abgebrochen wird? Weil Sie diese Entscheidung in der Situation nicht mehr treffen können. Wenn Sie drei Tage in einem Umbau stecken, wirkt Aufhören wie Scheitern und Weitermachen wie Professionalität — dabei ist es meistens umgekehrt. Deshalb vereinbaren Sie es vorher, wenn Sie noch nüchtern sind.

9:25 Die vier Kriterien haben eine gemeinsame Logik: Sie beschreiben alle den Moment, in dem sich herausstellt, dass die Planung nicht mehr passt. In dem Moment ist der Rücksprung auf den letzten guten Stand die richtige Handlung — und keine Niederlage. Der erste Punkt beschreibt die Situation, die daraus entsteht: der halbfertige Umbau, den man weder abschließen noch verwerfen mag.

9:47 Der zweite ist die Ursache — die Diskussion über den Rücksprung wird genau dann geführt, wenn sie am schwersten fällt. Der vierte ist praktisch der wichtigste: Die Definition of Done für erfüllt erklären, ohne den Diff gelesen zu haben. Das passiert erstaunlich oft, wenn die Tests grün sind. Grüne Tests sind eine notwendige Bedingung, keine hinreichende — was sie nicht abdecken, sehen sie nicht.

Analyse, Planung, Änderung und Review trennen

10:11 Kommen wir vom Inhalt des Auftrags zum Ablauf. Vier Tätigkeiten, die man bequem in einem Durchgang erledigen kann — und die getrennt gehören, mit einem Menschen dazwischen. Es ist verlockend, einem Agenten die ganze Aufgabe zu geben und das Ergebnis anzusehen. Er erkundet, plant, ändert und prüft in einem Zug, und Sie bekommen einen fertigen Patch.

10:32 Das ist bequem und der häufigste Grund für unprüfbare Ergebnisse — denn ein Fehler in der Analyse wird durch alle folgenden Phasen weitergetragen und ist am Ende im Patch nicht mehr erkennbar. Getrennt heißt: erkunden und prüfen, planen und freigeben, ändern, prüfen. Zwischen den Phasen steht jeweils ein Mensch. Die Halte sind unterschiedlich teuer, und das ist der Grund, warum der Ablauf funktioniert. Erkundung und Änderung machen Sie nicht selbst — das macht der Agent, und das dauert.

11:01 Freigabe und Review kosten Sie Minuten. Der Aufwand ist also deutlich geringer, als der Ablauf aussieht. Wichtig ist Schritt fünf: Wenn im Review etwas nicht stimmt, gehen Sie zurück zur Planung, nicht direkt zur nächsten Änderung. Sonst reparieren Sie ein Symptom, während der Denkfehler weiterläuft — und der nächste Patch hat ihn wieder.

11:21 Warum ist die Phasentrennung im Bestand wichtiger als in der Neuentwicklung? Das ist ein hübsch geschlossenes Argument. Bei Neuentwicklung liegt eine Analyse meistens richtig, weil das System so funktioniert, wie ein erfahrener Leser erwarten würde. Bei einem Bestandssystem ist genau das nicht der Fall — es verhält sich anders als erwartet, sonst wäre es kein Legacy. Die Analyse liegt also häufiger daneben.

11:45 Und ein Denkfehler in der Analyse, der ungeprüft in die Änderung läuft, steht am Ende in vierzig Dateien.

Repository-Anweisungen für Umbauten

11:52 Zum Abschluss die Frage, wo die Leitplanken eigentlich stehen sollten. Nicht in jedem einzelnen Auftrag — dort werden sie irgendwann vergessen. Sondern dort, wo sie ohne Zutun gelten. Manche Regeln gelten für jeden Umbau in diesem Projekt. Die immer wieder neu aufzuschreiben, ist mühsam und geht schief, weil irgendwann eine fehlt.

12:12 Besser sind hinterlegte Anweisungen: global das, was überall gilt, lokal das, was nur für einen Bereich gilt. Der Vorteil ist doppelt, und der zweite Teil wird oft übersehen: Solche Regeln steuern nicht nur den Agenten, sie erinnern auch die Menschen. Wer neu ins Team kommt, liest sie und weiß, woran er ist — ohne dass ihm das jemand erzählen muss.

12:33 Drei Beispiele aus unserem System, und sie sind bewusst konkret. „Sauberer Code“ ist keine Regel — „Geldbeträge laufen über einen festen Typ, keine Fließkommazahlen“ ist eine. Man kann sie befolgen oder verletzen, und man sieht im Diff, was der Fall ist. Die zweite schützt den Vertrag mit der Buchhaltung aus Modul drei.

12:53 Die dritte macht die namenlosen Konstanten aus Modul zwei zur Regel. Und die Fußzeile ist der eigentliche Ratschlag: Wo möglich, gießen Sie die Regel in einen ausführbaren Check. Was der Bau erzwingt, muss niemand im Review nachhalten — und es gilt auch dann, wenn der Auftrag es vergessen hat. Der erste Punkt ist die typische Übertreibung: Alles global hinterlegen.

13:15 Dann werden die Regeln so allgemein, dass sie nichts mehr aussagen — „schreibe lesbaren Code“ hilft niemandem. Der dritte ist der gefährlichste: sich auf die Anweisungen verlassen und den Diff nicht mehr lesen. Anweisungen erhöhen die Wahrscheinlichkeit, sie garantieren nichts. Und der vierte wird fast nie gemacht: Regeln zurückbauen, wenn ihr Grund entfallen ist.

13:37 Ein Regelwerk, das nur wächst, wird irgendwann ignoriert — dazu kommen wir in Modul zwölf noch einmal.

Übung: Aus „mach das mal sauber“ einen Auftrag machen

13:43 Jetzt schreiben Sie selbst. Und der interessante Teil kommt am Schluss: Eine andere Gruppe liest Ihren Auftrag mit genau einer Frage — und die ist erstaunlich unangenehm. Der Ausgangssatz ist echt: „Die Abrechnung im Fahrtenbuch ist ein Albtraum, mach die mal sauber.“ So kommen Aufträge an. Ihre Aufgabe ist es, daraus etwas zu machen, mit dem ein Agent kontrolliert arbeiten kann — und das heißt vor allem, Entscheidungen zu treffen, die im Ausgangssatz offen bleiben.

14:11 Welches Ziel eigentlich? Was darf sich nicht ändern? Wie weit reicht der Bereich? Sie werden merken, dass das Formulieren länger dauert als erwartet, und dass Sie dabei Fragen entdecken, die Sie sonst erst mitten im Umbau gestellt hätten. Nehmen Sie sich für Schritt zwei ausreichend Zeit — die Nachweise sind der Teil, an dem sich zeigt, ob Ihr Auftrag trägt. Und dann kommt Schritt fünf, der eigentliche Prüfstein.

14:36 Die andere Gruppe stellt eine einzige Frage: Welche Freiheit lässt dieser Auftrag noch, die Sie nicht gewähren wollten? Das ist genau die Frage, die ein Agent implizit auch beantwortet — nur beantwortet er sie stillschweigend und durch Handeln. Jede Lücke, die die andere Gruppe findet, hätte er im Ernstfall genauso gefunden. Nur mit deutlich weniger Gelegenheit zur Rückfrage.