Bestandscode modernisieren

Bestandscode modernisieren

0:00 Eine Migration in einem Schritt ist keine Migration, sondern ein Neubau mit anderem Namen. Ich sage das so deutlich, weil der Wunsch verständlich ist: Man will das einmal durchziehen und dann Ruhe haben. Das Ergebnis ist regelmäßig ein Diff über vierhundert Dateien, den niemand mehr prüfen kann, und ein Zweig, der drei Wochen neben dem Hauptzweig herläuft.

0:20 In diesem Modul geht es um den anderen Weg — kleine Schritte, jeder lauffähig, jeder überprüfbar.

Modernisierung, KI-Einsatz und Abschluss

0:27 Der letzte Tag. Vormittags Modernisierung — der Teil, der die meisten von Ihnen im eigenen Projekt erwartet. Danach KI-gestützte Entwicklung in zwei Modulen, und zum Schluss das Abschlussprojekt mit dem Transfer in Ihre eigene Codebasis.

Ausgangslage aufnehmen

0:42 Fangen wir da an, wo jede Migration anfangen sollte und selten anfängt: bei der Frage, wo wir eigentlich stehen. Vor dem ersten Commit steht die Bestandsaufnahme: aktuelle Angular-Version, Node und TypeScript, Zustand der Tests, Abhängigkeiten mit eigenem Angular-Bezug. Der Aktualisierungsbefehl plant den Weg und führt mitgelieferte Migrationen aus.

1:04 Und ein Punkt, der regelmäßig überrascht: Über zwei Hauptversionen hinweg sind es zwei Updates, nicht eines. Man kann das nicht abkürzen — wer es versucht, überspringt Migrationen, die zwischen den Versionen liegen, und die fehlen dann. Fünf Schritte, und die Fußzeile nennt den wichtigsten Grund für Schritt zwei: Ohne grüne Tests vor dem Start lässt sich später nicht sagen, ob die Migration etwas kaputt gemacht hat.

1:29 Wenn drei Tests schon vorher rot waren, wird jede Diskussion danach zäh. Schritt drei ist der, der Projekte aufhält: Abhängigkeiten mit eigenem Angular-Bezug. Wenn eine davon die Zielversion nicht unterstützt, ist der Plan hinfällig — und das sollte man vorher wissen, nicht nach zwei Tagen Arbeit. Vier Punkte, und alle vier habe ich schon erlebt.

1:49 Der Sprung überspringt eine Version, und deren Migrationen laufen nie — die Anwendung funktioniert trotzdem, und drei Monate später wundert sich jemand über eine merkwürdige Stelle. Eine Fremdbibliothek passt nicht und blockiert alles. Die Tests waren schon vorher rot, und niemand weiß welche. Und der vierte ist der organisatorische: Der Aufwand lässt sich nicht schätzen und wird dauerhaft unterschätzt — jedes Mal aufs Neue.

2:14 Der erste Punkt ist der, vor dem ich eben gewarnt habe: Zwei Hauptversionen werden in einem Durchgang übersprungen. Der zweite ist eine Reihenfolgefrage mit unangenehmer Wirkung: Fremdbibliotheken werden erst am Ende geprüft — nachdem die Arbeit gemacht ist. Und der dritte ist der, der die Beweisführung unmöglich macht: Der Ausgangszustand der Tests wird nicht festgehalten.

2:36 Machen Sie einen Screenshot, schreiben Sie die Zahl auf, irgendetwas. Es dauert zehn Sekunden.

Von NgModule zu Standalone

2:43 Jetzt zum ersten großen Schritt. Und zur Frage, in welchen Portionen man ihn macht. Die Migration löst Komponenten, Direktiven und Pipes aus den Modulen und lässt sie ihre Abhängigkeiten selbst benennen. Angular liefert sie mit — Sie schreiben das nicht von Hand. Der sinnvolle Zuschnitt ist der entlang der Features: ein Bereich, ein lauffähiger Stand, ein Review. Denken Sie an eine Wohnungsrenovierung.

3:07 Man macht ein Zimmer fertig und zieht wieder ein, bevor das nächste drankommt — statt alle Wände gleichzeitig aufzureißen und drei Wochen in der Küche zu schlafen. Vier Stationen, und der Kreislauf ist der Punkt. Feature wählen, Migration laufen lassen, Ergebnis prüfen, committen. Und dann wieder von vorn. Das Entscheidende ist die dritte Station: Ergebnis prüfen. Die Migration macht ihre Arbeit gut, aber sie kennt Ihre Konventionen nicht und sie versteht Ihren Code nicht.

3:36 Wer den Diff nicht liest, übernimmt auch das, was nicht passt. Und nach dem dritten ungeprüften Durchlauf weiß niemand mehr, was eigentlich passiert ist. Der erste Punkt ist der Klassiker, mit dem ich das Modul eröffnet habe: Die Migration läuft über die gesamte Anwendung und erzeugt einen unlesbaren Diff. Der zweite ist die Folge davon: Das Ergebnis wird übernommen, ohne den Diff zu lesen — weil er ohnehin zu groß ist.

4:02 Und der dritte ist der, der einen Rückzug unmöglich macht: Zwischenstände sind nicht lauffähig. Dann sitzen Sie fest und können weder vor noch zurück, und die einzige Option ist, weiterzumachen.

Ältere Syntax gezielt migrieren

4:14 Kommen wir zu den mitgelieferten Migrationen. Und zu der Frage, warum man sie benutzen sollte, statt von Hand umzuschreiben. Angular liefert eine ganze Reihe: für standalone, für den eingebauten Kontrollfluss, für die Dependency-Injection-Funktion, für signalbasierte Eingaben, Ausgaben und Abfragen, für das Nachladen von Routen, für selbstschließende Elemente, für Klassen- und Stilbindungen statt der älteren Direktiven, für das Entfernen ungenutzter Importe und für den Ersatz des gemeinsamen Moduls durch einzelne Direktiven.

4:43 Das deckt den Großteil dessen ab, was sich in den letzten Jahren geändert hat. Fünf Zeilen, und lesen Sie die rechte Spalte als Inventarliste Ihrer eigenen Anwendung. Wenn Sie dort etwas finden, gibt es dafür eine Migration — Sie müssen sie nur laufen lassen. Die interessante Zeile ist die vorletzte: Dekoratoren für Eingaben, Ausgaben und Abfragen.

5:03 Das sind in einer mittelgroßen Anwendung schnell zweihundert Stellen, und keine davon ist schwierig. Aber zweihundertmal dieselbe mechanische Änderung von Hand — dabei passieren Fehler, und zwar genau bei Nummer hundertsiebzig. Vier Gründe, und der erste ist der pragmatischste: Die Migration trifft alle Stellen, auch die vergessenen. Sie sucht nicht mit einer Textsuche, sie versteht den Code.

5:27 Der zweite ist ein Review-Argument: Der Diff ist gleichförmig und damit schnell zu lesen — man prüft das Muster, nicht jede Zeile. Der dritte ist der, der mir am wichtigsten ist: Eigene Umschreibungen führen versehentlich Verhaltensänderungen ein. Und der vierte: Die Reihenfolge der Migrationen ist erprobt. Der erste Punkt ist vermeidbarer Aufwand mit Fehlerrisiko: Von Hand umgeschrieben, während eine Migration dafür existiert. Schauen Sie erst nach, bevor Sie anfangen.

5:56 Der zweite ist der, der jede Migration riskant macht: Das Ergebnis wird nicht durch Tests abgesichert — und genau deshalb stand Schritt zwei der Bestandsaufnahme am Anfang. Und der dritte macht das Review unmöglich: Mehrere Migrationen laufen gemeinsam und vermischen sich im Diff. Eine nach der anderen, je ein Commit.

ZoneJS und Change Detection ablösen

6:15 Bleibt der letzte Schritt — und der aufschlussreichste, weil er Dinge zutage fördert, die vorher verborgen waren. Für die Ablösung entfernen Sie Zone.js aus der Konfiguration der Bau- und Testziele, streichen den Import aus den Polyfills und deinstallieren das Paket. Die Abfragen nach Stabilität und die Ereignisse rund um die Mikrotask-Warteschlange entfallen; das Ausführen innerhalb und außerhalb der Zone bleibt nutzbar und ist weiter sinnvoll.

6:40 Und der Punkt, der Arbeit macht: Reactive Forms brauchen eine ausdrückliche Meldung oder die Umstellung auf Signals. Das ist der Befund, den wir in Modul sechs stehen gelassen haben. Fünf Schritte, und der fünfte ist der, an dem sich die Qualität entscheidet: je Befund auf Signals umstellen, die ausdrückliche Markierung nur für Fremdcode.

7:00 Schritt drei ist der, den man wirklich machen muss — durchklicken und notieren. Und Schritt vier ist ein Fallstrick: Tests auf das Warten auf Stabilität umstellen statt auf erzwungene Durchläufe. Ein erzwungener Durchlauf im Test verdeckt genau die fehlende Meldung, die Sie suchen. In der Fußzeile steht ein Werkzeughinweis: Der MCP-Server der Kommandozeile bringt eine Analyse dafür mit.

7:24 Der erste Punkt ist der, den wir in Modul sechs schon hatten: Das Paket bleibt installiert und wird über eine Abhängigkeit geladen. Prüfen Sie es nach der Deinstallation wirklich nach. Der zweite ist der, der die Umstellung wertlos macht: Tests erzwingen Durchläufe und verdecken fehlende Meldungen — dann ist alles grün, und im Browser steht die Ansicht.

7:43 Und der dritte ist der erwartbare: Der Zustand von Reactive Forms meldet sich nicht, und die Ansicht steht.

Übung

7:50 Nehmen wir uns das Altfeature vor, das uns die ganze Woche begleitet hat, ohne dass wir es angefasst hätten. In Spurweite liegt ein älteres Feature: die Ersatzteilsuche. Sie ist NgModule-basiert, nutzt Dekoratoren für Eingaben und Ausgaben, die alten Struktur-Direktiven im Template und ein Formular auf Basis von Reactive Forms.

8:10 Und im zoneless Betrieb bleibt ihre Ansicht teilweise stehen — das war unser Befund aus Modul sechs, den wir damals notiert und liegen gelassen haben. Jetzt ist er dran. Sie haben also alle sechs Befunde in einem Feature beisammen. Das Lernziel nennt die eigentliche Fähigkeit: eine Migration in lauffähige Schritte zerlegen und jeden gegen Build, Tests und Review absichern. Nicht „migrieren" — zerlegen.

8:35 Das Erfolgskriterium verlangt vier Dinge, und das dritte ist das, worauf es ankommt: Jeder Zwischenstand war lauffähig. Wer früh fertig ist, begründet im Review je Schritt, warum er allein steht. Das ist eine gute Übung — es zwingt dazu, den Schnitt bewusst zu machen statt zufällig. Fünf Schritte, und der erste ist der, den man überspringen will: Tests grün bekommen, bevor es losgeht. Schritt zwei und drei sind die Migrationen, einzeln, mit je einem Commit.

9:03 Schritt vier ist der, der Handarbeit verlangt und bei dem Sie verstehen, warum: die stehende Ansicht beheben. Und Schritt fünf ist die Übergabe — ein Migrationsplan mit den verbleibenden Risiken. Betonung auf verbleibend: Was noch offen ist, gehört hinein, nicht nur das Erledigte. Der erste Punkt ist der, mit dem das Modul angefangen hat: Alle Migrationen laufen gemeinsam, und der Diff ist nicht mehr lesbar.

9:28 Der zweite ist der, der Sie festsetzt: Ein Zwischenstand ist nicht lauffähig, und der Rückweg fehlt. Und der dritte macht den Plan wertlos für den nächsten: Er nennt die erledigten Schritte, aber keine verbleibenden Risiken. Als Nächstes wenden wir uns der Frage zu, wie man einen Assistenten so vorbereitet, dass sein Ergebnis überhaupt abnehmbar ist.