Bei der Modernisierung des alten Systems organisiert Copilot zunächst die Beweise

Als ich zum ersten Mal ein Java-Projekt aus der 1.5-Ära auf eine moderne Maschine zog, war das erste, was auftauchte, nicht das Codeproblem, sondern das Beweisproblem. Ob der Build reproduziert werden kann, ob die Testausgabe identisch ist, ob der Fehlerpunkt von der JVM, dem Image oder dem Quellcode stammt, diese Dinge bestimmen, wie vor dem „Starten des Refactorings“ vorzugehen ist. Die größte Angst bei der Modernisierung alter Systeme besteht nicht darin, dass die Veränderungen langsam vonstattengehen, sondern darin, dass man nicht sagen kann, was nach den Veränderungen geschah.

Korrigieren Sie zuerst die Szene, dann sind die nachfolgenden Aktionen sinnvoll. Das Wertvollste an diesem Schritt ist nicht die Vervollständigung in der IDE, sondern eine Box, die wiederholt ausgeführt werden kann: Das alte JDK, die alten Build-Tools, die alten Eingänge und die alten Testbefehle sind alle in Docker gesperrt. Befehle wie die folgenden sind nicht schön, aber sie funktionieren:

docker run --rm -v "$PWD":/src -w /src legacy-jdk8 \
  sh -lc './gradlew test 2>&1 | tee logs/baseline.log'

Dieser Befehl hat nur eine Funktion: den „heutigen Fehler“ in wiederholbare Beweise umzuwandeln. Ohne sie könnte jeder spätere Erfolg nur das Ergebnis zufällig verzeihender Umstände sein. Die Rolle des Copiloten ist hier ebenfalls sehr klar. Es soll nicht das Urteilsvermögen ersetzen, sondern helfen, Spuren zu klären: Wiederholte Fehler in langen Protokollen, Pfade, die sich in Build-Skripten widerspiegeln, und mehrere wiederkehrende Einträge in alten Tests können zunächst für eine grobe Überprüfung verwendet werden. Es handelt sich nicht um eine Schlussfolgerung, sondern um eine Ausgangskarte.

Wenn es darum geht, sich tatsächlich unters Messer zu legen, muss der Bereich der Veränderung sehr eng sein. Der einfachste Weg, alte Projekte umzuwerfen, besteht darin, den Paketnamen, den Build, den Eintrag und den Test auf einmal zu ändern. Am Ende kann man nicht einmal sagen, welcher Schritt das System kaputt gemacht hat. Ein stabilerer Ansatz besteht darin, zuerst die kleinste Lücke zu schließen: Decken Sie beispielsweise den alten Eingang mit einer Schicht Adapter ab, lassen Sie die neue Werkzeugkette zunächst außerhalb der alten Welt stehen und sehen Sie die Struktur klar und bewegen Sie sich dann langsam hinein. Copilot eignet sich sehr gut für die Bewältigung dieser Art mechanischer Arbeit: Importe füllen, Konfigurationen verschieben, wiederholte Fragmente extrahieren und temporäre Testskelette erstellen. Lassen Sie das Modell diese Dinge tun, und die Effizienz ist tatsächlich hoch. Es bleibt jedoch den Menschen überlassen, ob diese Naht geschnitten werden soll und welches Verhalten nach dem Schneiden erhalten bleiben soll.

Auch beim Testen kann man sich leicht vom Schein täuschen lassen. Das Bestehen des alten Tests bedeutet nicht, dass die Modernisierung sicher ist, sondern nur, dass bestimmte historische Verhaltensweisen noch nicht aufgebrochen wurden. Die Tests vieler alter Projekte ähneln eher Verhaltensschnappschüssen als geschäftssemantischen Spezifikationen. Grün ist einfach nur Grün und kann nicht direkt als „Systemverstehen“ interpretiert werden. Eine der wichtigsten Aktionen während der Transformation besteht darin, jedem kleinen Einschnitt neue, engere Testgrenzen hinzuzufügen, sodass sich der Test allmählich vom „historischen Erbe“ zu „aktuellen Einschränkungen“ ändert. Copilot kann dabei helfen, alte Behauptungen aufzuschlüsseln, Vorlagen zu vervollständigen und doppelte Test-Shells einzuführen. Allerdings sollte die Semantik im Test beibehalten werden und das Modell kann keine Entscheidungen für das System treffen.

Bei der archäologischen Modernisierung ist die zuverlässigste Arbeitsteilung eigentlich ganz einfach: Die Umgebung und die Protokolle sind für die Ermittlung der Fakten verantwortlich, Copilot ist für das Verschieben von Steinen und das Übersetzen verantwortlich, und die Menschen sind für die Entscheidung verantwortlich, welche Geschichte erhalten bleiben und welche Geschichte abgeschnitten werden soll. Sobald ein Modell so angeordnet ist, dass es die Vergangenheit des Systems erklärt, sind Vermutungen oft überzeugender als Beweise. Wenn man es wieder in die Position des Beweismanagements und der mechanischen Organisation bringt, wird es eher zu einem wirklich nützlichen Assistenten.