Verifikation und Review von Refactoring-Patches

Verifikation und Review von Refactoring-Patches

0:00 Der Patch liegt vor. Jetzt kommt der Teil, der über alles entscheidet — und der in der Praxis am ehesten abgekürzt wird, weil die Tests ja grün sind. Der Review einer Umstrukturierung folgt einer anderen Logik als der einer Funktionsänderung. Bei einer neuen Funktion prüfen Sie, ob sie tut, was sie soll. Bei einem Refactoring prüfen Sie, ob nichts passiert ist. Das ist die schwierigere Aufgabe, weil Sie den Zustand vorher kennen müssen.

0:26 In diesem Modul lernen Sie die Kriterien und Verfahren, mit denen das trotzdem gelingt.

Verifikation und Review von Refactoring-Patches

0:31 Wir beginnen mit dem stärksten Einzelindikator, den es gibt, und der steht schon fest, bevor Sie eine Zeile Code gelesen haben. Dann kommen die Verfahren: vergleichendes Testen, Prüfung der Verträge, Blick auf das Laufzeitverhalten. Dann das Diff-Lesen entlang einer festen Liste typischer Befunde. Danach die Frage, wer eigentlich prüfen sollte — der Agent selbst, ein zweiter Kontext, ein Mensch.

0:55 Und zum Schluss die selten gestellte Frage: Hat der Umbau eigentlich gebracht, was er sollte? Die Tagesübung zerlegt einen großen Patch.

Was bei einem Refactoring anders zu prüfen ist

1:04 Fangen wir mit dem Kriterium an, das alles andere überstrahlt. Es ist scharf, es ist einfach zu prüfen — und es wird regelmäßig übergangen, weil die Begründung für seine Verletzung immer plausibel klingt. Bei einem Refactoring darf sich das beobachtbare Verhalten nicht geändert haben — das ist die Definition aus Modul eins.

1:24 Und daraus folgt unmittelbar ein Prüfkriterium, für das Sie den Code nicht einmal ansehen müssen: Die Tests müssen unverändert grün sein. Unverändert ist das entscheidende Wort. Jede Änderung an einer Testerwartung im selben Patch ist ein Alarmzeichen. Nicht automatisch ein Fehler — aber etwas, das erklärt werden muss, bevor irgendetwas anderes geprüft wird.

1:46 Warum ist das ein Alarmzeichen? Weil es genau zwei Erklärungen gibt, und beide sind Befunde. Entweder hat sich das Verhalten geändert — dann war es kein Refactoring, und Sie prüfen nach anderen Kriterien. Oder der Test hing an Interna, war also kein Sicherheitsnetz, sondern eine Strukturbeschreibung. Das ist das dritte Fehlerbild aus Modul vier.

2:06 Beides muss man wissen, und keines darf stillschweigend durchgehen. Der vierte Punkt ist der praktische Grund für die Wachsamkeit: Ein Agent passt Erwartungen sehr bereitwillig an. Er will die Suite grün bekommen, und eine angepasste Zahl ist der kürzeste Weg dorthin. Der erste Punkt ist die Vorbeugung: Schreiben Sie „Tests werden nicht angepasst“ in den Auftrag. Das kostet eine Zeile und verhindert die halbe Diskussion.

2:32 Der zweite beschreibt, warum es trotzdem passiert — die Anpassung ist plausibel begründet, und im Review liest man eine gute Begründung und nickt. Und der vierte ist der praktischste Ratschlag dieses Moduls: Beginnen Sie den Review mit den Testdateien, nicht mit dem Code. Das dauert dreißig Sekunden und beantwortet sofort die wichtigste Frage.

Vergleichendes Testen alter und neuer Fassung

2:52 Kommen wir zu einem Verfahren, das erstaunlich wenig bekannt ist und für Bestandsarbeit hervorragend passt. Es hat eine ungewöhnliche Eigenschaft: Sie müssen nicht verstehen, was der Code tut. Die Idee: Sie erzeugen eine große Menge von Eingaben, lassen die alte und die neue Fassung darüber laufen und vergleichen die Ergebnisse paarweise.

3:12 Für die Privatnutzungsberechnung des Fahrtenbuchs ist das ideal — die Eingaben sind wenige Zahlen und ein Zweck, die Menge lässt sich systematisch erzeugen, und jede Abweichung springt sofort ins Auge. Der Reiz liegt in dem, was Sie dafür nicht brauchen: Sie müssen die Regeln nicht kennen. Sie stellen Gleichheit fest, nicht Richtigkeit.

3:30 Und bei einem Refactoring ist Gleichheit genau das, was Sie nachweisen wollen. Fünf Schritte, und der erste entscheidet über die Aussagekraft: Decken Sie den Eingaberaum systematisch ab, einschließlich der Randwerte. Beim Fahrtenbuch also ausdrücklich um die Sechzig-Kilometer-Grenze herum — 59, 60, 61 —, denn dort sitzt die Regel.

3:51 Schritt zwei ist ein hübscher Kunstgriff: Die alte Fassung bleibt unter neuem Namen erhalten, damit beide gleichzeitig laufen können. Und Schritt fünf ist die Disziplin: Jede Abweichung wird einzeln beurteilt. Es gibt gelegentlich zulässige Abweichungen — nur müssen Sie sie erklären können, statt sie zu akzeptieren. Damit das nicht als Allheilmittel stehen bleibt: Sobald Zustand im Spiel ist, greift der paarweise Vergleich nicht mehr — das Ergebnis hängt dann von der Vorgeschichte ab, und die müssten Sie mit vergleichen.

4:22 Seiteneffekte lassen sich so ebenfalls nicht gegenüberstellen. Für reine Berechnungen dagegen ist es der belastbarste Nachweis, den Sie mit vertretbarem Aufwand bekommen. Und jetzt der schöne Zusammenhang, der im vierten Punkt steckt: Reine Berechnungen sind ausgerechnet der Teil, den Sie in Modul sechs herausgelöst haben.

4:40 Der lohnendste Umbau erzeugt also gleich das, was sich am besten prüfen lässt.

Verträge, Kompatibilität und Datenmigrationen prüfen

4:45 Jetzt zu der Fehlerkategorie, die im eigenen Haus niemand bemerkt — und die dafür beim Nachbarn ankommt. Ihre Testsuite deckt sie systematisch nicht ab. Der Grund ist strukturell: Ihre Tests prüfen Ihr System, und die Verträge zeigen nach außen. Ein umbenanntes Feld in einer Antwort ist fachlich exakt dasselbe — Ihre Tests bleiben grün, weil sie den fachlichen Gehalt prüfen.

5:07 Für den Aufrufer ist es ein Ausfall, weil er nach dem alten Namen sucht. Diese Lücke schließen Sie nur mit eigenen Prüfungen, und die müssen anders funktionieren als Ihre Tests: zeichengenau statt fachlich. Das gemeinsame Prinzip dieser drei Zeilen ist Buchstabentreue statt fachlicher Bewertung. Bei Schnittstellen vergleichen Sie Antwortformate zeichengenau.

5:29 Bei Dateiformaten gilt dasselbe einschließlich der Details, die man leicht übersieht: Reihenfolge der Spalten, Trennzeichen, Zeilenende. Ein von Unix auf Windows gewechseltes Zeilenende hat schon manche Importschnittstelle lahmgelegt. Bei Migrationen brauchen Sie Zählungen und Stichproben vor und nach dem Lauf — und zwar, wie die Fußzeile sagt, am echten Datenumfang.

5:50 Auf dem Entwicklungsbestand messen Sie eine Situation, die es so nicht gibt. Der erste Punkt ist der methodische Kern, den ich noch einmal betone: Fachliche Gleichwertigkeit ist nicht Kompatibilität. Der dritte ist der, den fast alle Teams betrifft: Der Rückweg ist geplant und wurde nie ausprobiert. Das ist keine Schlamperei, sondern Zeitmangel — und es rächt sich in genau der Situation, in der Sie am wenigsten Zeit haben.

6:15 Und der vierte beschreibt die typische Abkürzung: Diese Prüfungen sind aufwendig, die Suite ist grün, also lässt man sie weg. Die Suite prüft aber genau diesen Bereich nicht.

Leistungsverhalten im Blick behalten

6:25 Jetzt eine Klasse von Schäden, die im Diff unsichtbar ist, in den Tests unsichtbar ist — und in der Produktion am Monatsersten sehr sichtbar wird. Ein Beispiel, das häufiger vorkommt, als man denkt: Sie lösen eine Funktion heraus, die bisher auf eine bereits geladene Datenmenge zugriff. Nach dem Herauslösen kennt sie diese Menge nicht mehr und lädt selbst nach — pro Aufruf. Aus einem Datenbankzugriff werden tausend.

6:50 Der Diff sieht sauber aus, das Verhalten ist identisch, die Tests sind grün. Und der Monatslauf, der bisher zwanzig Minuten brauchte, läuft jetzt vier Stunden. Das ist eine Verhaltensänderung, auch wenn das Ergebnis stimmt. Der Grund ist einfach und wird selten ausgesprochen: Ihre Testdaten sind klein. Bei fünfzig Datensätzen macht der Unterschied zwischen einem und fünfzig Zugriffen keine messbare Zeit aus. Der Effekt skaliert erst mit echten Daten.

7:17 Der zweite Punkt nennt eine verwandte Falle: Eine eingezogene Abstraktion — genau die aus Modul sieben — kann eine Zwischenspeicherung unwirksam machen, weil der Schlüssel sich ändert. Und der dritte Punkt ist der entscheidende für den Review: Im Diff steht nichts über die Zahl der Zugriffe. Sie können das nicht lesen. Sie müssen es messen.

7:37 Die gute Nachricht: Das muss nicht aufwendig sein. Sie benennen vorher die kritischen Pfade — beim Fahrtenbuch ist das der Monatslauf. Sie messen die Laufzeit über einen realistisch großen Datenbestand und zählen die Datenbankzugriffe mit. Nach dem Umbau dieselbe Messung. Zwei Zahlen, vorher und nachher. Damit decken Sie die typischen Verschlechterungen bereits auf — Sie brauchen kein Lastwerkzeug und keine Messumgebung.

8:02 Und Schritt fünf ist die Disziplin: Abweichungen werden erklärt, bevor der Patch zusammengeführt wird, nicht danach.

Diff-first: was bei Umbauten typisch schiefgeht

8:09 Jetzt zum eigentlichen Lesen des Diffs. Und weil sich die Fehlerbilder bei Umbauten wiederholen, lohnt sich eine feste Liste — sie schlägt jedes allgemeine Qualitätsurteil. „Schau dir den Diff mal an“ führt zu einem diffusen Eindruck. Eine feste Liste führt zu Befunden. Der Grund ist, dass Sie beim Lesen etwas suchen müssen — sonst sehen Sie das, was auffällt, und nicht das, was zählt.

8:32 Die fünf Muster auf der nächsten Folie haben sich als Suchraster bewährt, weil sie genau die Situationen abdecken, die bei Umstrukturierungen entstehen. Sie können die Liste übrigens auch einem Agenten geben — dazu kommen wir im nächsten Kapitel. Die rechte Spalte ist hier die interessante, denn sie erklärt, warum diese Fehler entstehen — es sind fast immer gut gemeinte Änderungen.

8:54 Eine vereinfachte Bedingung, die einen Randfall verliert, entsteht beim Aufräumen. Eine entfernte Fehlerbehandlung entsteht, weil der Fangblock überflüssig aussah — sein Zweck war ja nicht kommentiert. Eine geänderte Sichtbarkeit erweitert stillschweigend Ihre Schnittstelle. Eine neue Abhängigkeit wirkt sinnvoll und war nicht beauftragt.

9:13 Und die letzte Zeile ist die aus Modul fünf: Formatierung ist selten schädlich für das Programm und immer schädlich für die Prüfbarkeit. Der erste Punkt ist der Kern: Nach Gefühl lesen findet, was auffällt — und die gefährlichen Änderungen fallen nicht auf. Der zweite beschreibt den Alltag: Bei achtzig Prozent Formatierungsanteil überfliegt man den Rest.

9:34 Deshalb steht das Nicht-Ziel im Auftrag; wenn es trotzdem passiert, ist das ein Grund, den Patch zurückzugeben, nicht ihn tapfer zu lesen. Und der vierte ist eine Erinnerung: Entfernte Fehlerbehandlung braucht immer eine Erklärung. In einem gewachsenen System steht ein Fangblock meistens dort, weil etwas passiert ist.

Selbstprüfung des Agenten gegen unabhängigen Review

9:53 Jetzt die Frage, wer eigentlich prüfen soll. Der naheliegende Gedanke ist, den Agenten seine eigene Arbeit prüfen zu lassen. Das ist besser als nichts — und schwächer, als es aussieht. Der Grund ist einfach: Die Annahmen, die zur Änderung geführt haben, stehen noch in seinem Kontext. Er hat sich beim Bauen etwas gedacht, dieser Gedanke ist präsent, und beim Prüfen bestätigt er ihn.

10:17 Das ist kein Mangel des Werkzeugs — Menschen tun dasselbe, wenn sie ihren eigenen Code reviewen. Der Ausweg ist derselbe wie bei Menschen: ein frischer Blick. Nur ist der bei einem Agenten billig zu haben. Sie starten einen neuen Kontext, geben ihm den Diff und den ursprünglichen Auftrag — und sonst nichts. Die drei Stufen unterscheiden sich darin, wie viel Kontext der Prüfende hat — und weniger ist hier mehr. Stufe eins bestätigt die eigenen Annahmen.

10:44 Stufe zwei sieht nur Diff und Auftrag und findet genau das, was die Entstehungsgeschichte verdeckt hat. Stufe drei ist die größte Verbesserung für den geringsten Aufwand, und sie steht in der Fußzeile: eine gezielte Frage statt einer allgemeinen. „Prüfe diesen Diff auf unbeabsichtigte Verhaltensänderungen an Randfällen“ liefert brauchbare Befunde. „Prüfe die Qualität“ liefert eine Aufzählung von Stilempfehlungen.

11:10 Und jetzt die Grenze, die auch mit dem besten Verfahren bleibt. Dass eine scheinbar sinnlose Sonderbehandlung für den Standort Süd gilt und einen guten Grund hat, steht in keinem Repository. Fachliche Absichten sind aus dem Code nicht rekonstruierbar — man sieht, was passiert, nicht warum es gewollt war. Wer sich außerhalb Ihres Systems auf etwas verlässt, weiß nur die Organisation.

11:31 Und der vierte Punkt ist die Klammer, die wir in Modul elf ausbauen: Die Verantwortung für das Zusammenführen bleibt in jedem Fall beim Menschen.

Den Erfolg eines Refactorings messen

11:40 Zum Abschluss eine Frage, die fast nie gestellt wird — und die man dank Modul fünf tatsächlich beantworten kann: Hat der Umbau eigentlich gebracht, was er sollte? Normalerweise endet ein Umbau damit, dass der Patch zusammengeführt wird. Ob das Ziel erreicht wurde, wird gefühlt beantwortet — der Code sieht besser aus, alle sind zufrieden.

12:00 Weil wir das Ziel in Modul fünf aber beobachtbar formuliert haben, gibt es hier eine andere Möglichkeit: nachsehen. „Die Abrechnung ist ohne laufende Datenbank testbar“ ist eine Behauptung, die man ausprobieren kann. Damit wird aus einer Meinungsfrage eine Beobachtung — und das ist der Grund, warum sich die Mühe mit dem beobachtbaren Ziel gelohnt hat.

12:21 Schritt eins und zwei sind die Hauptsache: Ziel hervorholen, wörtlich nehmen, ausprobieren. Die Schritte drei bis fünf sind Ergänzungen, die man leicht unterschätzt. Wie viele Dateien berührt eine typische Änderung jetzt? Wie schnell laufen die Tests dieses Bereichs? Und der fünfte ist mein Favorit, weil er nichts kostet: Lassen Sie jemanden, der den Code nicht kennt, ihn erklären, und stoppen Sie die Zeit.

12:45 Diese Zahl sagt mehr über Lesbarkeit als jede Metrik. Die Fußzeile benennt den eigentlichen Ertrag: Am lehrreichsten sind die Fälle, in denen viel Arbeit floss und das Ziel trotzdem verfehlt wurde. Der erste Punkt ist der übliche: Der Erfolg wird am Gefühl beim Lesen gemessen. Der zweite beschreibt, warum die Nachprüfung ausfällt — der Patch ist zusammen‐ geführt, das Thema gilt als erledigt, und niemand kommt zurück.

13:10 Setzen Sie sich den Termin gleich mit. Der dritte ist subtil: Man betrachtet die technische Metrik und vergisst das fachliche Ziel. Und der vierte ist der teuerste, weil er Wiederholung erzeugt: Ein verfehltes Ziel, das nicht dokumentiert wird, führt zum selben Vorgehen beim nächsten Mal.

Tagesübung: Einen großen Patch verkleinern

13:27 In der Tagesübung bekommen Sie einen echten KI-erzeugten Patch. Er erreicht sein Ziel, er sieht gut aus — und er enthält vier Probleme, die Sie mit den Verfahren dieses Moduls finden können. Der Reiz dieser Übung liegt darin, dass der Patch auf den ersten Blick überzeugend ist. Er ist strukturiert, sinnvoll benannt, das Ziel ist erreicht, die Tests sind grün.

13:49 Genau das ist der Normalfall in der Praxis — Patches, die offensichtlich schlecht sind, machen keine Probleme. Enthalten sind eine unbeabsichtigte Verhaltensänderung, eine angepasste Testerwartung, eine nicht beauftragte Abhängigkeit und großflächige Formatierung. Belegen Sie jeden Befund, statt ihn zu behaupten — mit Fundstelle, wie in Modul zwei geübt.

14:10 Fangen Sie mit Schritt eins an, den Testdateien — dann haben Sie einen der vier Befunde in zwei Minuten. Danach die Liste der typischen Befunde durchgehen. Der eigentliche Arbeitsteil ist Schritt drei: den Patch in eine Folge kleiner, einzeln prüfbarer Schritte zerlegen. Und Schritt vier verlangt etwas Mut — verwerfen, was nicht beauftragt war, auch wenn es eine Verbesserung ist. Der zerlegte Patch wird am Ende kleiner sein als der ursprüngliche.

14:36 Das ist kein Verlust an Substanz, sondern das Entfernen dessen, was niemand bestellt hat. Damit schließt Tag zwei.