Generierte Änderungen prüfen und freigeben

Generierte Änderungen prüfen

0:00 Der Vorschlag läuft. Das ist die schwächste aller Aussagen über Code — und trotzdem die, mit der die meisten Abnahmen enden. Läuft heißt: Er hat sich compilieren lassen und ist beim Klicken nicht abgestürzt. Über Architektur sagt das nichts, über Zugänglichkeit nichts, über die Aussagekraft der Tests erst recht nichts. In diesem Modul prüfen wir einen generierten Vorschlag entlang von vier Dimensionen und treffen am Ende eine nachvollziehbare Entscheidung.

Modernisierung, KI-Einsatz und Abschluss

0:26 Wir sind im letzten Tag und im zweiten der beiden KI-Module. Vorbereitet haben wir gestern — jetzt kommt der Teil, der die eigentliche Verantwortung trägt: die Abnahme.

Den Diff lesen, nicht das Ergebnis

0:37 Fangen wir mit dem an, worauf Sie überhaupt schauen. Und die Antwort ist nicht die laufende Anwendung. Ein Vorschlag wird Zeile für Zeile gegen die Aufgabe gelesen. Besonders interessant sind die Stellen, die niemand beauftragt hat: nachgezogene Formatierungen, umbenannte Felder, veränderte Konfiguration, ergänzte Abhängigkeiten.

0:57 Und jetzt der Satz, der schwerfällt: Umfang, der über die Aufgabe hinausgeht, wird zurückgewiesen — auch wenn er für sich genommen sinnvoll wirkt. Nicht weil er schlecht wäre, sondern weil er nicht geprüft wurde und in einem Diff mitschwimmt, der etwas anderes prüfen sollte. Fünf Schritte in einer Reihenfolge, die Absicht hat. Erst die Dateiliste gegen die benannten Bereiche — das dauert dreißig Sekunden und sortiert schon einiges aus.

1:22 Dann jede Datei außerhalb begründen lassen. Neue Abhängigkeiten gesondert prüfen und meistens ablehnen. Und Schritt vier ist der, den ich Ihnen besonders ans Herz lege: Konfigurationsänderungen zuletzt lesen. Wenn Sie sie zwischendurch lesen, rutschen sie durch — sie sehen unscheinbar aus. Die Fußzeile sagt das Grundproblem: Ein zu großer Diff wird nicht gründlicher gelesen, sondern oberflächlicher.

1:47 Der erste Punkt ist der, mit dem ich das Modul eröffnet habe: Der Vorschlag wird ausgeführt und danach abgenommen, ohne den Diff zu lesen. Der zweite ist die verführerischste Falle: Eine unbeauftragte Verbesserung wird mit übernommen — sie ist ja gut. Und ein halbes Jahr später kann niemand erklären, warum diese Stelle so aussieht, weil sie in keinem Ticket steht.

2:08 Und der dritte ist der, den Schritt vier verhindern soll: Eine neue Abhängigkeit rutscht in die Konfiguration.

Architektur und Laufzeitverhalten prüfen

2:15 Jetzt zur zweiten Dimension. Und die Frage dabei lautet: Passt es zum Entwurf, oder passt es nur zum Compiler? Geprüft wird, ob der Vorschlag die getroffenen Entscheidungen einhält: Zuständigkeiten zwischen Komponente, Service und Datenzugriff, die Art des Zustands, der Umgang mit Fehlern. Und dann kommt der Teil, der mit erstaunlicher Regelmäßigkeit auftritt: veraltete Muster.

2:39 NgModule, Dekoratoren für Eingaben, die alten Struktur-Direktiven, Konstruktor-Injektion, Annahmen über Zone.js. Das passiert auch dann, wenn die Version im Kontext genannt war — nur seltener. Fünf Zeilen, und ich empfehle Ihnen, daraus eine Suchliste zu machen. Wirklich: Suchen Sie im Diff gezielt nach diesen Begriffen, bevor Sie ihn lesen.

3:01 Das dauert eine Minute und findet den Großteil dessen, was aus der alten Welt stammt. Die interessanteste Zeile ist die letzte — ein erzwungener Durchlauf der Change Detection im Code. Das ist ein Muster, das es in einer zoneless Anwendung mit Signals nicht geben sollte, und es ist ein zuverlässiges Zeichen dafür, dass der Vorschlag aus einer anderen Zeit stammt.

3:22 Der erste Punkt ist der subtilste: Der Vorschlag hält sich an die Aufgabe, aber nicht an den Architekturentscheid. Er erfüllt alle Kriterien und schneidet die Zuständigkeiten falsch — das fällt nur auf, wenn man den Entscheid kennt. Der zweite ist ein Klassiker aus Modul fünf: Zustand wird zusätzlich in einem Feld geführt und läuft auseinander.

3:42 Und der dritte ist der, der diesen ganzen Abschnitt motiviert: Das Laufzeitverhalten wird nie beobachtet, nur der Code gelesen.

Tests und Zugänglichkeit mitprüfen

3:50 Die dritte und vierte Dimension — und genau die beiden, die am leichtesten hohl aussehen können, ohne es zu sein. Generierte Tests sehen oft vollständig aus. Sie haben gute Namen, sie decken mehrere Fälle ab, die Zeilenzahl stimmt — und sie prüfen die Umsetzung statt des Verhaltens. Die Gegenprobe ist einfach und dauert dreißig Sekunden: Code bewusst falsch machen und beobachten, ob der Test rot wird.

4:14 Für die Zugänglichkeit gilt dasselbe in Handarbeit: Tastaturbedienung, Fokus und Beschriftung der neuen Elemente prüfen. Auch das dauert keine drei Minuten. Fünf Schritte, und die ersten drei sind die Gegenprobe im engeren Sinn: Test auswählen, Code kaputt machen, schauen ob er rot wird. Die Fußzeile nennt den Grund noch einmal in aller Deutlichkeit: Ein Test, der bei falschem Code grün bleibt, erzeugt Sicherheit ohne Grundlage — und das ist schlechter als gar kein Test, weil man sich darauf verlässt.

4:44 Schritt vier und fünf sind die Handarbeit an der Oberfläche: einmal ohne Maus durch, Beschriftung und Fehlerrückmeldung ansehen. Der erste Punkt ist der, den die Gegenprobe aufdeckt: Die Tests prüfen interne Aufrufe statt beobachtbares Verhalten. Der zweite ist die häufigste Lücke bei generierten Tests: Der Fehlerfall fehlt, nur der Erfolgsfall ist abgedeckt — was verständlich ist, denn der Erfolgsfall steht in der Aufgabe, der Fehlerfall oft nicht.

5:09 Und der dritte ist der, den man nur findet, wenn man wirklich hinschaut: Ein neuer Knopf ist ein Container und mit der Tastatur nicht erreichbar.

Freigabe und Ausblick

5:17 Bleibt der Abschluss: die Entscheidung — und die Frage, was davon übrig bleibt. Am Ende steht je Vorschlag eine Entscheidung: angenommen, geändert übernommen oder verworfen, jeweils mit Grund und verantwortlicher Person. Diese Spur ist die Grundlage dafür, dass die Änderung später erklärbar bleibt. Und noch ein Ausblick, der in die Einordnung gehört: WebMCP, das Anwendungen eigene Werkzeuge für Assistenten anbieten lässt, steht derzeit zum Ausprobieren bereit.

5:45 Es ist keine Voraussetzung dieses Seminars und sollte in keiner Projektplanung als gesetzt auftauchen. Vier Punkte, und der erste ist der, der später am häufigsten gebraucht wird: was beauftragt war und was tatsächlich kam. Diese beiden Dinge auseinanderzuhalten ist der Kern der ganzen Abnahme. Der zweite: welche Teile übernommen, geändert oder verworfen wurden.

6:08 Der dritte: welche Prüfungen gelaufen sind und mit welchem Ergebnis — denn „wurde geprüft" ist keine Aussage. Und der vierte ist der, der Verantwortung festhält: wer freigegeben hat. Der erste Punkt ist der, der in schnellen Teams normal ist: Die Freigabe erfolgt mündlich und ist später nicht nachvollziehbar. Der zweite ist der, der Arbeit wiederholen lässt: Verworfene Teile werden nicht festgehalten und kommen beim nächsten Lauf wieder — mitsamt der Diskussion darüber.

6:36 Und der dritte ist eine Planungsfrage: Ein experimentelles Werkzeug wird als gesetzte Grundlage eingeplant. Bei WebMCP heute wäre das genau der Fehler.

Übung

6:46 Jetzt kommt der Teil, auf den Modul zwanzig hingearbeitet hat. Der Assistent liefert — und Sie nehmen nicht entgegen, sondern prüfen. Die in Modul zwanzig vorbereitete Aufgabe wird ausgeführt: Ein Assistent schlägt die sortierbare Monteur-Spalte für die Auftragsübersicht vor. Und ich möchte betonen, wie die Gruppe damit umgeht — sie nimmt den Vorschlag nicht entgegen, sie prüft ihn.

7:10 Das ist ein Unterschied in der Haltung, und er wirkt sich auf das Ergebnis aus. Wer entgegennimmt, sucht nach Gründen, es anzunehmen. Wer prüft, sucht nach dem, was nicht stimmt. Das Lernziel nennt alle vier Dimensionen: Architektur, Laufzeitverhalten, Tests und Zugänglichkeit. Das Erfolgskriterium verlangt ein Protokoll mit einer Entscheidung je Teil — und mindestens einen Test, der die Gegenprobe bestanden hat.

7:35 Wer früh fertig ist, formuliert die Aufgabe so um, dass der beanstandete Teil beim nächsten Lauf gar nicht erst entsteht. Das ist die eigentliche Lernschleife: Ein Befund im Review ist auch immer eine Lücke in der Beschreibung. Fünf Schritte, und sie entsprechen genau den vier Kapiteln plus der Entscheidung. Schritt eins: Dateiliste gegen die benannten Bereiche.

7:57 Schritt zwei: nach veralteten Mustern suchen, mit der Liste von vorhin. Schritt drei: in der Anwendung beobachten, nicht nur lesen. Schritt vier: die Gegenprobe an einem Test. Schritt fünf: ohne Maus bedienen und entscheiden. Wenn Sie die Zeit überziehen, dann bei Schritt drei — das Beobachten ist das, was man am ehesten weglässt und am wenigsten sollte.

8:20 Der erste Punkt ist der, gegen den dieses ganze Modul geschrieben ist: Die Prüfung endet, sobald die Anwendung startet. Der zweite ist die Verwechslung von Menge und Aussage: Die Tests werden gezählt statt auf ihre Aussage geprüft — zwölf Tests klingen gut und sagen nichts. Und der dritte macht das Protokoll wertlos für den nächsten: Es hält nur die Annahme fest, nicht die Gründe.

8:42 Im letzten Modul führen wir alles zusammen — und Sie schreiben Ihren eigenen Plan.