Abschlussprojekt

Abschlussprojekt

0:00 Zum Abschluss bringen Sie alles zusammen. Und ich sage gleich vorweg: Hier kommt kein neuer Stoff. Alles, was Sie jetzt brauchen, kam in den dreizehn Modulen davor — die Leistung besteht darin, es zusammenzubringen. Das ist übrigens auch die Leistung im Berufsalltag: Einzelne Techniken zu kennen, ist die eine Hälfte. Zu wissen, welche wann dran ist, die andere.

0:21 Sie migrieren ein fremdes Projekt, bauen eine neue Funktion, prüfen den Änderungssatz und schreiben am Ende einen ehrlichen Bericht.

Abschlussprojekt — Agentic TypeScript Engineering

0:30 Der Leitsatz für dieses Projekt ist zugleich mein Schlusswort zum ganzen Seminar: Ein ehrlich benanntes Restrisiko ist mehr wert als ein vollständig wirkender Bericht. Das gilt für Ihre Migration, das gilt für Ihren Review, und das gilt für alles, was Sie über generierten Code sagen. Wir gehen durch acht Stationen — von der Bestandsaufnahme über die Migration und die neue Funktion bis zum Bericht. Und die letzte Station schließt den Kreis zurück zu Modul 12.

Die Ausgangslage

0:56 Sie bekommen eine gewachsene Codebasis, die niemand aus der Runde geschrieben hat. Das ist Absicht und ein wichtiger Teil der Übung: Wer sein eigenes Projekt migriert, umgeht den schwierigsten Teil — sich in unbekanntem Bestand zurechtzufinden. Sie erhalten Kurbelwerk als gewachsenes Projekt auf Version 6: ein Monorepo mit mehreren Paketen, einer Werkstattlogik, einer Anbindung an den Teilekatalog des Großhändlers und einem Kassenterminal, das nie modernisiert wurde.

1:23 Also ziemlich genau das, was einem im Berufsleben begegnet. Und der entscheidende Satz steht am Schluss: Nichts davon haben Sie geschrieben. Genau das ist der Punkt. Sie müssen sich orientieren, bevor Sie handeln — und diese Orientierung ist in der Praxis der Teil, für den nie Zeit eingeplant wird. Fünf Bereiche, und jeder trägt ein Thema aus diesem Seminar. Die Domäne ist brauchbar, aber teils verflacht — optionale Felder statt Zustände, das Thema aus Modul 3.

1:51 Die Katalog-Anbindung nimmt Fremddaten ungeprüft entgegen, Modul 6. Das Kassenterminal hängt an altem Modulformat und alter Zielversion und hat damit seine eigenen Zwänge. Die Konfiguration blockiert den Wechsel, Modul 9. Und die Werkzeuge warten auf die Compiler-Schnittstelle, Modul 8. Die rechte Spalte ist Ihre Landkarte für die nächsten Stunden.

2:14 Fünf Schritte, und der fünfte ist eine Regel, keine Empfehlung — das steht so in der Fußzeile und ich meine es ernst. Lesen Sie die Struktur: Pakete, Referenzen, Vererbungsketten. Notieren Sie die Konfiguration je Paket und markieren Sie Abweichungen. Listen Sie die Werkzeuge auf, die den Compiler als Abhängigkeit führen.

2:34 Finden Sie die Stellen, an denen Fremddaten eintreffen. Und erst danach ändern Sie eine Zeile. Wer früher ändert, ändert unter Annahmen, die er noch nicht geprüft hat — und merkt es erst, wenn schon Arbeit darin steckt.

Migrationsrisiken identifizieren

2:48 Der erste echte Arbeitsschritt ist eine Liste — und diese Liste ist mehr als Vorbereitung. Sie ist das Ergebnis, an dem sich der Plan messen lassen muss, den Sie gleich beauftragen. Ohne eigene Liste können Sie einen fremden Plan nicht beurteilen. Das Lernziel: aus einer fremden Codebasis die Stellen ableiten, an denen ein Compilerwechsel bricht, und sie nach Wirkung ordnen.

3:10 Erfolgreich sind Sie, wenn jedes Risiko mit Ort, Ursache und Prüfweg benannt ist — alle drei — und wenn die Werkzeugrisiken vor den Coderisiken stehen. Diese Reihenfolge ist der Kern aus Modul 9: Ein Coderisiko verschiebt keine Migration, ein blockiertes Werkzeug schon. Wer früh fertig ist, schätzt je Risiko, ob es maschinell behebbar ist oder eine Entscheidung verlangt. Das ist die Grundlage für jede seriöse Aufwandsangabe.

3:36 Vier Ordnungsprinzipien, die Sie aus den letzten Modulen kennen. Werkzeuge zuerst: Sie entscheiden über den Termin, nicht der Code. Konfiguration vor Code: Sie ändert, was überhaupt beanstandet wird. Die bekannten Verhaltensunterschiede gezielt suchen, statt abzuwarten, ob etwas bricht — Sie kennen ja beide. Und der vierte Punkt ist der, der eine Risikoliste von einer Sorgenliste unterscheidet: Je Risiko einen Prüfweg nennen.

4:03 Ohne Prüfweg bleibt es eine Vermutung, und Vermutungen kann man weder abarbeiten noch abhaken. Der erste Punkt ist die Fehleinschätzung aus Modul 9: nach Codezeilen schätzen statt nach Konfiguration und Werkzeugen. Der zweite ist eine konkrete Falle, die in diesem Projekt wartet: den Snapshot-Test über eine Union übersehen, bis er bricht — und dann in der Hektik das Falsche tun.

4:26 Sie wissen inzwischen, dass die richtige Antwort nicht darin besteht, die Typordnung zurückzudrehen. Und der dritte ist der bekannte: Risiken sammeln, ohne je einen Prüfweg dazuzuschreiben. Eine Liste ohne Prüfwege beruhigt nur.

Den Plan erstellen lassen

4:40 Jetzt kommt Modul 11 zum Einsatz. Und die Anweisung ist eindeutig: Beauftragen Sie einen Plan, keine Änderung. Der Plan ist an dieser Stelle das wertvollste Zwischenprodukt, das Sie bekommen können — weil er sich gegen Ihre eigene Liste halten lässt. Das Lernziel: einen Auftrag so formulieren, dass der zurückgelieferte Plan gegen die eigene Risikoliste prüfbar ist.

5:02 Erfolgreich sind Sie, wenn der Plan vor der ersten Codeänderung gegen die Liste gehalten wurde und jede Lücke auf eine fehlende Angabe im Auftrag zurückgeführt ist. Denken Sie an die vier Elemente aus Modul 11: Ziel, Kontext, Randbedingungen, Abschlusskriterium — und das vierte fehlt erfahrungsgemäß im ersten Versuch, auch bei Leuten, die es gerade gelernt haben.

5:23 Wer früh fertig ist, ergänzt den Auftrag und lässt einen zweiten Plan erstellen. Vier Wirkungen. Er zeigt, was verstanden wurde, bevor Arbeit entsteht — das ist der billigste Korrekturzeitpunkt, den es gibt. Er lässt sich gegen Ihre eigene Risikoliste halten, und das ist hier eine echte Probe: zwei unabhängig entstandene Sichten auf dasselbe Projekt.

5:44 Eine Lücke im Plan verweist fast immer auf eine Lücke im Auftrag — nicht auf Unfähigkeit. Und er wird später zum Maßstab für den Review des Änderungssatzes, wenn Sie fragen: Wurde gemacht, was geplant war?

Migrieren in Schritten

5:57 Jetzt die Migration selbst — der Weg aus Modul 9, diesmal an einem Projekt, das Sie nicht kennen. Die Regel dazu ist knapp: Jeder Schritt ein Commit, nach jedem Schritt die Prüfung. Das ist Ihr Rückweg, falls etwas schiefgeht. Die fünf Schritte kennen Sie: den Schalter für veraltete Optionen entfernen und die Meldungen in Stufen abarbeiten. Basispfad und Quellverzeichnis umstellen, maschinell wo möglich.

6:23 Die stabile Typordnung einschalten und sauber übersetzen. Parallelbetrieb einrichten und beide Diagnosen vergleichen. Und dann auf 7.0 wechseln und gegenprüfen. Die Fußzeile erinnert an das Entscheidende: Diese Reihenfolge ist die Bedingung der Verhaltenszusage, nicht eine Empfehlung. Wer sie abkürzt, hat keine Zusage mehr — und weiß bei jeder Abweichung nicht, woher sie kommt.

6:47 Der zweite Punkt ist die Falle, vor der wir gewarnt haben, und sie ist verlockend: den Snapshot-Test reparieren, indem die Typordnung zurückgedreht wird. Damit machen Sie den Test grün und die Migration kaputt. Der erste ist der Verlust des Rückwegs: mehrere Schritte in einem Commit bündeln. Und der dritte ist eine Umfangsfrage: das Kassenterminal mitmigrieren wollen, obwohl es eigene Zwänge hat — eine alte Laufzeit, die bedient werden muss.

7:13 Das ist ein eigenes Vorhaben, kein Nebenprodukt. Es abzugrenzen ist eine Leistung, kein Versäumnis.

Die neue Funktion

7:20 Nach der Migration bauen Sie etwas Neues: eine Abholbenachrichtigung. Drei Wege, ein Zustandsübergang. Und darin steckt eine kleine Falle, die genau prüft, ob Modul 3 angekommen ist — einer der drei Wege braucht ein Feld, das die anderen beiden nicht haben. Die Fachlichkeit ist einfach: Erreicht ein Auftrag den Zustand „fertig", wird der Kunde benachrichtigt — per SMS, per E-Mail oder per Rückruf mit Zeitfenster.

7:46 Das Lernziel: eine fachliche Funktion so bauen, dass Zustände, Varianten und Fremddaten jeweils am richtigen Ort behandelt werden. Erfolgreich sind Sie unter drei Bedingungen: Kein optionales Feld trägt eine Variante, die Kontaktdaten sind zur Laufzeit geprüft, und ein neuer Zustand bricht den Übersetzungslauf. Wer früh fertig ist, führt Marken für Telefonnummer und Adresse ein.

8:09 Hier ist die Lösung der kleinen Falle. Nur der Rückruf trägt ein Zeitfenster, und er trägt es verpflichtend. Die beiden anderen Wege haben keines — nicht ein leeres, sondern gar keines. Die Fußzeile erklärt, warum die naheliegende Alternative schlechter ist: Als optionales Feld wäre das Zeitfenster in allen drei Wegen darstellbar und in zweien sinnlos.

8:30 Sie hätten also einen Zustand modelliert, den es nicht geben darf — genau das, was wir seit Modul 3 zu vermeiden versuchen. Vier Zeilen, und die Fachlichkeit ist im Typ. Sehen Sie, wie viel in dieser einen kleinen Funktion steckt: die unterscheidbare Union und die Vollständigkeitsprüfung aus Modul 3. Marken für Nummer und Adresse aus Modul 5.

8:51 Die Validierung der Kontaktdaten an der Grenze aus Modul 6 — denn eine Telefonnummer kommt aus einem Formular und ist erst mal nur Text. Und Tests für die Fehlerfälle, nicht nur für den Erfolgspfad, aus Modul 8. Vier Module in einer Funktion, die man in fünf Minuten erklären kann. So sieht die Praxis aus: Nicht ein großes Konzept, sondern vier kleine, richtig angeordnet.

Alle Prüfungen ausführen

9:14 Jetzt laufen alle Tore. Vollständig. Und der Grundsatz dazu ist streng: Ein übergangenes Tor macht das ganze Ergebnis unbrauchbar. Nicht nur das eine Tor — das ganze Ergebnis. Alle Prüfungen laufen vollständig, jede Meldung wird behoben. Und jetzt die Begründung für die Strenge: Ein übersprungenes Tor entwertet nicht nur sich selbst.

9:36 Danach kann niemand mehr sagen, was geprüft wurde und was nicht — und damit verlieren auch die grünen Tore ihre Aussagekraft. Das gilt auch dann, und ich würde sagen: gerade dann, wenn ein Tor wegen der Werkzeuglage klemmt. Denn das ist in diesem Projekt sehr wahrscheinlich — das typbezogene Linting wartet ja auf die Compiler-Schnittstelle.

9:56 Vier Skripte, und die Aufteilung kennen Sie: jedes Tor einzeln, plus einen Sammelaufruf für die Pipeline. Dieselben Befehle lokal wie in der Pipeline — der Akzeptanzpunkt aus Modul 8. Und die Fußzeile beschreibt genau die Situation, in der Sie gleich sein werden: Klemmt ein Tor wegen der fehlenden Compiler-Schnittstelle, wird das vermerkt — nicht stillschweigend entfernt.

10:18 Ein Vermerk ist ein offener Punkt. Eine gelöschte Zeile ist ein vergessener. Der erste Punkt ist der, der Ihnen in diesem Projekt begegnen wird: ein Tor abschalten, weil es klemmt, ohne es zu dokumentieren. Schreiben Sie es auf, sonst findet es niemand wieder — auch Sie nicht. Der zweite ist ein Reihenfolgefehler: die Prüfung nur lokal laufen lassen und die Pipeline nicht nachziehen.

10:41 Und der dritte ist ein Arbeitsstil, der sich rächt: Meldungen sammeln und am Ende in einem Rutsch beheben wollen. Dann sitzen Sie vor fünfzig verschränkten Fehlern statt vor fünfmal zehn.

Den Diff reviewen

10:52 Jetzt kommt Modul 13 zum Einsatz: der Review des gesamten Änderungssatzes. Und diesmal haben Sie zwei Maßstäbe — den Plan, den Sie vorher geprüft haben, und die neun Fragen der Checkliste. Das Lernziel: einen umfangreichen Änderungssatz systematisch gegen Plan und Checkliste prüfen und Befunde nach Wirkung priorisieren. Erfolgreich sind Sie, wenn Konfiguration und Manifestdateien zuerst geprüft wurden, alle neun Fragen beantwortet sind — auch mit „hier nicht nötig" — und mindestens ein Befund begründet nicht behoben ist.

11:23 Dieser letzte Punkt ist Teil der Aufgabe, kein Zugeständnis: Er zwingt zur Begründung und schützt Sie davor, jede gemeldete Lücke abzuarbeiten. Wer früh fertig ist, lässt zusätzlich in einem frischen Kontext prüfen und vergleicht. Vier Schwerpunkte für diesen konkreten Änderungssatz. Stillschweigende Lockerungen der Strenge in der Konfiguration — der erste Griff, und in einem Migrationsprojekt besonders verlockend, weil es ja gerade um Konfiguration geht.

11:51 Tests, die nur die Implementierung nachzeichnen. Änderungen außerhalb des beauftragten Umfangs. Und der vierte ist neu und nur hier möglich: Abweichungen vom Plan, die niemand angesprochen hat. Eine Abweichung kann völlig richtig sein — sie sollte nur nicht unbemerkt bleiben.

Instructions und Dokumentation

12:08 Und damit schließt sich der Kreis zurück zu Modul 12. Jeder Befund aus Ihrem Review ist ein Kandidat für die Anweisungsdatei — denn was einmal beanstandet wurde, sollte beim nächsten Lauf gar nicht erst entstehen. Jeder Punkt, den Sie im Review beanstandet haben, ist ein Kandidat für die Anweisungsdatei — oder für eine Ebene darunter, je nachdem, wie verbindlich er sein muss.

12:30 Damit wird aus einem einmaligen Review dauerhafte Wirkung, und das ist der eigentliche Ertrag der Arbeit. Und zum Abschluss gehört ein Bericht, der ehrlich benennt, was migriert wurde, was bewusst offen blieb und woran ein Nachfolger das erkennt. Das dritte ist das schwierigste — und das nützlichste. Fünf Schritte, und der letzte wird am häufigsten weggelassen und ist am wertvollsten. Befunde durchgehen und je Befund die passende Ebene wählen.

12:56 Regeln so formulieren, dass ihr Fehlen zu Fehlern führen würde — die Prüffrage aus Modul 12. Die Anweisungsdatei gegen die Obergrenze prüfen und kürzen. Restrisiken benennen, mit Ort und Prüfweg. Und dann: dokumentieren, was Sie bewusst nicht getan haben, und warum. Denn das verhindert, dass eine bewusste Entscheidung später als Versehen gilt — und Sie sind dann vermutlich nicht mehr da, um es richtigzustellen.

13:22 Fünf Abschnitte, und drei davon handeln von dem, was nicht fertig ist. Das ist Absicht. Migriert: was umgestellt wurde, mit Nachweis beider Compiler. Offen: was bewusst offen blieb, mit Begründung. Blockiert: welche Werkzeuge warten und worauf. Restrisiko: wo etwas brechen könnte, mit Prüfweg. Und der fünfte ist ein Geschenk an Ihr künftiges Selbst: Was ist zuerst zu tun, wenn Version 7.1 da ist?

13:49 Diesen Abschnitt werden Sie in einigen Monaten lesen und dankbar sein, dass ihn jemand geschrieben hat.

Danke!

13:56 Damit sind wir am Ende von drei Tagen. Sie nehmen mit: ein Typsystem, mit dem sich unmögliche Zustände nicht mehr hinschreiben lassen. Eine klare Trennung zwischen dem, was der Compiler prüft, und dem, was Sie zur Laufzeit prüfen müssen. Einen belegten Migrationsweg. Und ein Vorgehen für die Arbeit mit Coding Agents, das einen Werkzeugwechsel überlebt.

14:18 Alle Materialien und das Quellendossier liegen in der Freigabe — und die Belegkette gehört ausdrücklich dazu, nicht nur die Folien. Rückfragen jederzeit. Vielen Dank für Ihre Aufmerksamkeit und viel Erfolg mit Ihrem Projekt.