Migration mit Coding Agents

Migration mit Coding Agents

0:00 Wenn Sie aus diesem Seminar eine Sache mit ins Haus nehmen, die sich unmittelbar in Geld ausdrücken lässt, dann ist es dieses Modul. Migrationen sind in Java-Häusern das Thema, das seit Jahren auf der Liste steht und immer wieder verschoben wird — zu groß, zu riskant, zu wenig sichtbarer Nutzen. Was sich mit einem Coding Agent ändert, ist nicht die Schwierigkeit.

0:20 Es ist die Zugänglichkeit: Analyse, Kartierung und das stumpfe Abarbeiten von Übersetzungsfehlern werden erheblich billiger. Die Entscheidungen bleiben bei Ihnen.

Migration mit Coding Agents

0:30 Der dritte Tag ist der Tag der Anwendung. Wir kartieren die Java-Stände von Lagerwerk, schneiden eine Migration in prüfbare Schritte, prüfen Ersatzwege für entfernte APIs — und ziehen dann tatsächlich ein Modul auf den Zielstand. Hier zahlt sich alles aus, was wir in den letzten beiden Tagen aufgebaut haben. Oder eben nicht, und dann sehen wir das auch. Beides ist ein gutes Ergebnis.

0:53 Vier Ziele. Wir stellen zuerst den tatsächlichen Migrationsstand von Lagerwerk fest — und Sie werden sehen, dass „tatsächlich" hier das entscheidende Wort ist. Wir zerlegen die Migration in Schritte, die einzeln prüfbar sind. Wir bewerten Ersatzwege für entfernte APIs kritisch, denn hier ist die Trefferquote von Sprachmodellen am schlechtesten. Und wir ziehen ein Modul vollständig hoch.

1:17 Das ist die Übung, an der sich zeigt, ob unsere Arbeitsweise trägt.

Gemischte Java-Stände kartieren

1:21 Beginnen wir mit der Karte. Vor jeder Migration steht die Frage, wo man eigentlich steht — und in einem Mehrmodulprojekt ist das keine triviale Frage. Wir lassen die Karte vom Agenten erstellen und prüfen sie gemeinsam gegen die Konfiguration. Denn genau bei dieser Art Aufgabe zeigt sich eine typische Schwäche: Zusammenfassen ist einfacher als nachsehen.

1:42 Bevor migriert wird, braucht es eine Karte: welches Modul auf welchem Stand steht, welche Abhängigkeit welchen Sprung blockiert, in welcher Reihenfolge sich das auflösen lässt. Denken Sie an eine Straßensanierung. Sie können nicht mit der Straße anfangen, die auf der Brücke endet, die selbst noch saniert werden muss. Die Reihenfolge steckt in den Abhängigkeiten, nicht in Ihren Wünschen. Und diese Reihenfolge lässt sich nicht raten — sie muss erhoben werden.

2:09 Achten Sie darauf, wie präzise dieser Auftrag ist: nicht „analysiere die Migration", sondern drei benannte Angaben je Modul — Stand aus der Konfiguration, Abhängigkeiten, Blocker. Das ist der Unterschied zwischen einer Tabelle, mit der Sie arbeiten können, und einem Aufsatz. Und die Fußzeile enthält den wichtigen Hinweis: Prüfen Sie das Ergebnis gegen die Konfigurationsdateien.

2:30 Hier wird nämlich gern zusammengefasst statt gelesen — eine Angabe, die für drei Module gilt, wird auf vier ausgedehnt, und schon stimmt die Reihenfolge nicht mehr. Der erste Punkt ist der praktische: Ohne Karte migriert man das falsche Modul zuerst. Meistens das, das am meisten stört — und das ist selten das, das zuerst dran wäre.

2:50 Der dritte Punkt ist der, der Ihnen im Haus hilft: Die Karte ist die Grundlage für jede Aufwandsaussage nach außen. Mit ihr können Sie sagen, welche drei Module unkritisch sind und wo die Entscheidung ansteht. Ohne sie sagen Sie „ein paar Wochen" und liegen daneben. Der erste Punkt ist der Fehler, der die ganze Karte wertlos macht: den Stand je Projekt statt je Modul erheben.

3:13 Ein Projekt hat oft keinen einheitlichen Stand — genau deshalb machen wir die Karte. Der letzte Punkt wird regelmäßig vergessen und rächt sich am Ende: die Laufzeitumgebung. Sie können ein Modul auf den Zielstand ziehen, so viel Sie wollen — wenn der Anwendungsserver oder das Basisabbild im Betrieb die Version nicht trägt, war die Arbeit vergeblich.

3:33 Klären Sie das früh, nicht beim Ausliefern.

Migrationsschritte planbar schneiden

3:36 Im zweiten Kapitel geht es um eine Definition, die härter ist, als sie zunächst klingt. Ein Migrationsschritt ist erst dann einer, wenn er allein übersetzt, allein getestet und allein zurückgenommen werden kann. Alles andere ist kein Schritt, sondern ein Vorhaben mit unklarem Ende. Der Agent schlägt einen Schnitt vor, und er ist darin gut — die Entscheidung darüber ist und bleibt trotzdem eine Teamentscheidung.

4:00 Warum diese drei Bedingungen? Weil sie zusammen den Rückweg sichern. Ein Schritt, der allein übersetzt, lässt sich prüfen. Einer, der allein getestet werden kann, lässt sich bewerten. Und einer, der sich allein zurücknehmen lässt, macht aus einem Fehlschlag einen Zwischenfall statt einer Katastrophe. Stellen Sie sich das Umziehen einer Wohnung vor: Sie räumen Zimmer für Zimmer, und nach jedem Zimmer kann man schlafen.

4:26 Wer alles gleichzeitig auseinandernimmt, hat abends kein Bett. Das Prinzip hinter dieser Tabelle ist Trennschärfe. Links wird vermischt, rechts getrennt. Die zweite Zeile ist mir die wichtigste, und die Fußzeile sagt auch warum: Version und Refactoring im selben Schritt macht jede Fehlersuche doppelt so teuer. Wenn danach etwas nicht mehr funktioniert, wissen Sie nicht, ob es an der neuen Java-Version liegt oder an Ihrem Umbau.

4:50 Also erst hochziehen, dann aufräumen — auch wenn es sich beim Arbeiten unnatürlich anfühlt, weil man die Stelle ja gerade offen hat. Der dritte Punkt ist der, den ich für den Alltag am wichtigsten halte: Lauffähige Zwischenstände erlauben, jederzeit zu unterbrechen. Und unterbrochen wird immer — durch einen Produktionsfehler, einen Urlaub, eine Priorität von oben.

5:12 Eine Migration, die nur im fertigen Zustand funktioniert, ist damit ein Risiko, das mit jedem Tag wächst. Der letzte Punkt ist der organisatorische Gewinn: Kleine Schritte lassen sich zwischen Personen aufteilen. Aus einem Ein-Personen-Projekt wird damit eine Teamaufgabe. Der erste Punkt trifft gerade die Gewissenhaften: aufräumen, weil man schon dabei ist. Der Impuls ist gut — Sie sind in der Datei, Sie sehen die Altlast, warum nicht gleich.

5:39 Weil der Diff dadurch unlesbar wird und der nächste Prüfer die eine wichtige Zeile zwischen achtzig unwichtigen sucht. Der letzte Punkt ist der, den man erst braucht, wenn es zu spät ist: keinen Rückweg definieren, weil man nicht damit rechnet. Der Rückweg kostet fünf Minuten Nachdenken, bevor Sie anfangen.

Entfernte APIs und ihre Ersatzwege

5:57 Im dritten Kapitel kommen wir zu der Stelle, an der ich Ihnen ausdrücklich Misstrauen empfehle. Wenn eine API verschwunden ist, schlägt der Agent einen Ersatz vor — und genau hier ist die Trefferquote am schlechtesten. Der Grund ist derselbe wie im dritten Modul: Über entfernte APIs und ihre Nachfolger steht wenig im Netz, also wird die Lücke gefüllt. Sehr überzeugend.

6:19 Auf dem Weg von älteren Ständen verschwinden Pakete, Klassen und Methoden. Für jede Fundstelle brauchen Sie einen Ersatz — und für jeden Ersatz eine Prüfung. Das Tückische daran: Ein falscher Ersatz ist meist kein Fehler, der auffällt. Er übersetzt, er läuft, er tut nur bei bestimmten Eingaben etwas anderes. Denken Sie an ein Ersatzteil, das passt und aus anderem Material ist. Es funktioniert — bis zu dem Tag, an dem die Belastung höher ist als sonst.

6:48 Fünf Schritte, und der zweite ist der, auf den es ankommt — die Fußzeile sagt es auch: gleicher Name, anderes Verhalten. Das ist der gefährlichste Fall, weil er beim Lesen unauffällig ist. Schritt drei fragt nach den Sonderfällen, denn genau dort weichen Nachfolger ab: leere Eingaben, Grenzwerte, Zeitzonen, Rundung. Und Schritt vier ist die ehrliche Frage: Gibt es einen Test, der den Unterschied überhaupt zeigen würde? Wenn nicht, wissen Sie nicht, ob der Ersatz stimmt — Sie hoffen es nur.

7:18 Das ist der Moment, in dem Modul 8 relevant wird. Der erste Punkt ist die Zusammenfassung des Kapitels: Ein falscher Ersatz übersetzt und verhält sich trotzdem anders. Alle unsere billigen Prüfinstanzen — Compiler, statische Analyse — greifen hier nicht. Der dritte Punkt ist der pragmatische Rat: Die Dokumentation ist schneller geprüft als der Fehler gefunden.

7:40 Zwei Minuten nachlesen gegen zwei Stunden suchen, das ist keine schwere Rechnung. Und trotzdem tut man es nicht, weil der Vorschlag so plausibel aussieht. Genau deshalb steht dieser Schritt hier als Vorgehen und nicht als guter Vorsatz. Die Punkte drei und vier sind die java-typischen. Zeit- und Zeichensatzverhalten als Nebensache behandeln — das rächt sich zuverlässig, denn genau dort haben sich zwischen den Ständen Standardwerte geändert.

8:06 Wenn Ihre Anwendung Datumsangaben oder Umlaute verarbeitet, und das tut praktisch jede, gehört das auf die Risikoliste. Und der letzte Punkt ist eine Frage der Disziplin: mehrere Ersetzungen bündeln und die Ursache nicht mehr zuordnen können. Eine Ersetzung, ein Testlauf. Es dauert länger und Sie wissen hinterher, was passiert ist.

Abhängigkeiten hochziehen

8:26 Im vierten Kapitel geht es um den häufigsten echten Blocker einer Java-Migration: Bibliotheken. Nicht Ihr eigener Code hält Sie auf, sondern etwas, das jemand anders vor Jahren geschrieben und irgendwann nicht mehr gepflegt hat. Wir sehen uns an, wie man diese Fälle sortiert — und vor allem, welche davon technische Fragen sind und welche in Wahrheit Projektentscheidungen, für die Sie jemanden brauchen.

8:48 Bibliotheken ohne aktuellen Nachfolger halten ganze Module zurück. Der Agent kann die Kandidaten ermitteln und Alternativen vorschlagen — das ist stumpfe Recherchearbeit und genau seine Stärke. Die Bewertung, ob ein Wechsel vertretbar ist, bleibt dagegen bei Ihnen. Denn dabei geht es nicht um Technik, sondern um Fragen wie: Kennt jemand im Team diese Alternative?

9:10 Wer pflegt sie? Wollen wir uns davon abhängig machen? Auf keine dieser Fragen kann ein Werkzeug antworten. Diese Tabelle ist nach steigendem Schmerz sortiert. Oben die angenehmen Fälle — neue Version da, einzeln hochziehen, fertig. In der Mitte wird es interessanter, unten wird es zur Projektfrage. Und deshalb steht die Fußzeile da: Die letzten beiden Zeilen sind keine technischen Fragen.

9:34 Eine aufgegebene Bibliothek ohne Ersatz bedeutet Eigenentwicklung oder Modul zurückstellen — das ist eine Managemententscheidung. Und die hausinterne, nicht gepflegte Bibliothek ist die unangenehmste von allen, weil zuerst geklärt werden muss, wer überhaupt zuständig ist. Der zweite Punkt spart am meisten Zeit: die Unterscheidung zwischen „blockiert" und „unbequem".

9:56 Vieles, was auf der ersten Liste als Blocker steht, ist in Wahrheit nur lästig — eine neue Version existiert, sie ändert nur ein paar Signaturen. Echte Blocker sind selten. Wenn Sie diese Unterscheidung sauber machen, schrumpft die Liste oft auf ein Drittel. Und der letzte Punkt ist die Begründung dafür, das früh zu tun: Es verhindert die Migration, die auf halbem Weg stehen bleibt, weil plötzlich eine Grundsatzfrage auftaucht.

10:21 Der zweite Punkt ist der java-spezifischste dieser Folie: transitive Abhängigkeiten. Sie ziehen eine Bibliothek hoch und merken nicht, dass sie eine andere mitbringt, die den Stand faktisch festlegt. Diese indirekten Abhängigkeiten sieht man in der Konfiguration nicht — man muss den Abhängigkeitsbaum ausgeben lassen. Der dritte Punkt ist der menschliche: einen Ersatz wählen, den im Team niemand kennt. Technisch ist das oft die beste Lösung.

10:47 Praktisch haben Sie damit für die nächsten Jahre eine Bibliothek, bei der niemand weiß, wie sie sich im Fehlerfall verhält.

Modul für Modul statt Big Bang

10:54 Und damit zur zentralen Übung des Tages. Wir ziehen ein Modul vollständig hoch — Version anheben, Übersetzungsfehler abarbeiten, Tests grün bekommen, Ergebnis prüfen. Hier kommt alles zusammen: die Karte, der Schnitt, die Anweisungsdatei, die Prüfroutine. Nehmen Sie sich Zeit dafür. Das ist die Stunde, in der sich zeigt, ob die Arbeitsweise der letzten beiden Tage trägt.

11:19 Ein Modul vollständig zu migrieren ist der kleinste Schritt, der sich nach außen als Fortschritt verkaufen lässt. Und das ist wichtiger, als es klingt — denn Migrationen scheitern selten an der Technik, sie scheitern an der Ausdauer. Wer nach zwei Wochen sagen kann „ein Modul ist fertig und läuft", bekommt weitere zwei Wochen. Wer sagt „wir sind bei siebzig Prozent", bekommt Fragen.

11:40 Sichtbarer, abgeschlossener Fortschritt ist also nicht nur technisch sinnvoll, sondern auch politisch. Fünf Schritte, und Schritt zwei ist der, bei dem die Arbeitsweise zählt: Übersetzungsfehler in Blöcken abarbeiten lassen, nicht alle auf einmal. Nach jedem Block das Modulkommando — deshalb steht es in der Anweisungsdatei, jetzt zahlt es sich aus.

12:01 Schritt vier ist der, den man in der Euphorie überspringt: Verhaltensänderungen gegen die Tests prüfen. Grün beim Übersetzen heißt nicht, dass sich nichts geändert hat. Und Schritt fünf ist derselbe wie gestern: den Diff vollständig lesen. Auch wenn er lang ist. Gerade dann. Der dritte Punkt ist der praktische Grund für das blockweise Vorgehen: Es hält den Diff prüfbar.

12:24 Wenn Sie zweihundert Übersetzungsfehler in einem Durchgang beheben lassen, bekommen Sie eine Änderungsliste, die niemand mehr liest — und damit haben Sie die Prüfung faktisch abgeschafft. Der letzte Punkt ist der, der aus einer Übung ein Verfahren macht: Der Ablauf lässt sich anschließend auf die übrigen Module übertragen.

12:41 Sie haben also am Ende nicht ein migriertes Modul, sondern ein Vorgehen für die restlichen drei. Der dritte Punkt ist der, den man erst am nächsten Tag bemerkt: das Modul für fertig erklären, bevor die abhängigen Module gebaut wurden. Ihr Modul ist grün, alle Tests laufen — und die drei Module, die davon abhängen, übersetzen nicht mehr. Deshalb steht in unserem Testkommando der Zusatz für die abhängigen Module.

13:05 Und der letzte Punkt klingt banal und passiert wirklich: den Zielstand während der Übung wechseln. Wenn zwischendurch jemand sagt „nehmen wir doch gleich die neuere Version", fangen Sie faktisch von vorne an. Das ist die zentrale Übung dieses Seminars. Ziehen Sie ein Modul hoch — die Karte sagt Ihnen, welches zuerst dran ist.

13:24 Erfolgskriterium sind vier Dinge: Das Modul steht auf dem Zielstand, alle Tests laufen, die abhängigen Module bauen weiterhin, und — das ist der eigentliche Punkt — jede übernommene API-Ersetzung ist begründet. Nicht „der Agent hat das vorgeschlagen", sondern warum Sie es angenommen haben. Wer früher fertig wird, nimmt sich das nächste Modul aus der Karte vor.

Regressionsrisiko beherrschen

13:47 Zum Abschluss dieses Moduls die unangenehme Frage, die vor jeder Migration stehen sollte und meistens erst danach gestellt wird: Was ist eigentlich abgesichert? Ich nehme das Ergebnis vorweg — bei den meisten Bestandsprojekten lautet die ehrliche Antwort „weniger, als wir dachten". Das ist kein Grund aufzugeben, aber es verändert den Plan.

14:06 Und es ist die Überleitung zum nächsten Modul, in dem wir genau dieses Netz bauen. Migrationen ändern Verhalten an Stellen, die niemand angefasst hat. Das ist das Wesen des Risikos: Es geht nicht um Ihre Änderungen, sondern um die des Sprachstands. Ohne Tests an diesen Stellen merkt es zuerst der Betrieb, und der meldet es nicht als Migrationsfolge, sondern als Fehlfunktion — drei Wochen später, wenn niemand mehr an die Migration denkt.

14:33 Deshalb die ehrliche Frage vor dem Start: Was ist überhaupt abgesichert? Nicht wie viele Prozent, sondern welche fachlichen Fälle. Der zweite Punkt ist der, den ich Ihnen als Argumentationshilfe mitgeben möchte: Fehlende Absicherung ist ein Argument für mehr Zeit, nicht gegen die Migration. Diese Unterscheidung geht in Diskussionen gern verloren. „Wir haben keine Tests, also können wir nicht migrieren" ist eine Kapitulation.

14:58 „Wir haben keine Tests, also brauchen wir zwei Wochen mehr für das Netz" ist ein Plan. Und der dritte Punkt ist der pragmatische: Wer die ungeschützten Stellen kennt, kann sie nach der Umstellung gezielt beobachten. Diese Tabelle ist eine Entscheidungshilfe, und sie hat bewusst fünf Abstufungen statt zwei. Denn „wir haben Tests" und „wir haben keine" ist zu grob.

15:19 Die zweite Zeile ist der häufigste Fall in der Praxis: Tests vorhanden, aber wenig aussagekräftig. Das ist gefährlicher als gar keine Tests, weil es Sicherheit vorspiegelt. Und die letzte Zeile ist die, an die man selten denkt: Wenn das Verhalten nirgends dokumentiert ist, kann auch kein Test es festhalten — dann muss der Fachbereich mit an den Tisch.

15:40 Die Zeilen drei und vier führen direkt ins nächste Modul. Der zweite Punkt ist der methodisch wichtigste: migrieren und absichern gleichzeitig. Wenn Sie den Test schreiben, während Sie die Umstellung machen, prüft der Test die neue Annahme — und bestätigt genau das, was Sie gerade geändert haben. Das Netz muss vorher gespannt sein, sonst ist es keines. Der dritte Punkt ist die Versuchung, wenn die Zeit knapp wird: auf den Betrieb als Prüfinstanz vertrauen.

16:08 Das funktioniert sogar — nur ist der Betrieb die teuerste Teststufe, die es gibt. Damit haben Sie das Kernstück dieses Seminars. Die Karte der Java-Stände steht und bestimmt die Reihenfolge — nicht Ihre Wünsche, sondern die Abhängigkeiten. Migrationsschritte sind so geschnitten, dass jeder einzeln übersetzt, testet und sich zurücknehmen lässt.

16:29 Ersatzwege für entfernte APIs werden geprüft und nicht geglaubt, gerade weil sie plausibel klingen. Ein Modul ist migriert. Und Sie wissen jetzt, welche Stellen ungeschützt sind. Genau die sichern wir im nächsten Modul ab — bevor die restlichen Module drankommen.