Modernisieren Sie zunächst das alte System und bauen Sie die Kompatibilitätsleiter auf

Als ich vor zwanzig Jahren zum ersten Mal ein Java-Projekt öffnete, war das erste, was ich sah, nicht der Code-Geruch, sondern der Altersgeruch. Die build.xml ist immer noch da, aber die pom.xml ist nicht da; Die Verzeichnisstruktur ist altmodisch, der Testeingang ist ebenfalls altmodisch und selbst „ob es ein lauffähiges Produkt wiederherstellen kann“ muss erneut bestätigt werden. Der häufigste Fehler in dieser Phase besteht darin, sich auf Unterricht und Methoden zu konzentrieren und zu ignorieren, dass die Umgebung und der Zugang die Modernisierung wirklich behindern.

Der erste Schritt bei der Modernisierung alter Systeme ist der Aufbau einer Kompatibilitätsleiter. Die Basis der Leiter dient meist nur einem: das alte System innerhalb der alten Regeln stabil laufen zu lassen und möglichst als Zeitkapsel zu dienen. Docker, altes JDK, alte Build-Tools, alte Testbefehle – diese Dinge sehen grob aus, sind aber sehr effektiv. Solange diese Basis nicht aufrecht steht, wird jede nachfolgende Änderung neues Rauschen mit sich bringen: Ob es der Code ist, der kaputt ist, oder die JVM, das Image, die Architektur und die Plug-Ins, die kaputt sind, lässt sich nicht sagen.

Dann war es an der Reihe, die Brücke zu wählen. Das Ziel der Brücke ist sehr spezifisch: Ein Ende ist mit dem alten Quellcode verbunden und das andere Ende ist mit der neuen Maschine verbunden. Dieses Projekt fiel schließlich an Java 8 und Gradle 7.6, die einfach an den Einschränkungen beider Seiten festhielten: Java 17 ist nicht mehr bereit, den Quellcode von Java 1.5 zu kompilieren, und Java 6 kann nicht in der nativen Umgebung von ARM64 ausgeführt werden. Wenn die Brücke falsch ist, bleibt die Modernisierung in der Werkzeugkette stecken; Wenn die Brücke stimmt, können nachfolgende Migrationen Schritt für Schritt voranschreiten.

Hier ist es am sinnvollsten, die Organisation und Übersetzung dem großen Modell zu überlassen. Es kann dabei helfen, die Ant-Logik in Gradle zu übersetzen, Verzeichnisse wieder dem alten Layout zuzuordnen und diese sich wiederholenden und mechanischen Konfigurationen zu entfernen. Verweisen Sie beispielsweise das Quellcodeverzeichnis explizit auf den alten Pfad und fügen Sie eine benutzerdefinierte Aufgabe hinzu, um den alten main()-Test auszuführen:

java {
    sourceCompatibility = JavaVersion.VERSION_1_5
    targetCompatibility = JavaVersion.VERSION_1_5
}
sourceSets {
    main {
        java {
            srcDirs = ['java']
        }
    }
}
tasks.register('runLegacyTest', JavaExec) {
    mainClass.set(project.findProperty('mainClass'))
    classpath = sourceSets.main.runtimeClasspath
}

Die Bedeutung dieser Konfiguration besteht darin, die Regeln der alten Welt deutlich zu machen. Das Schlimmste an alten Projekten ist oft nicht der Mangel an Fähigkeiten, sondern diese Fähigkeit, die in Gewohnheiten verborgen ist. Der Test wird über den main()-Eintrag ausgeführt, der Quellcode wird im alten Verzeichnis abgelegt und der Build wird unter der Annahme des Pfads in der Ant-Ära geschrieben. Copilot kann hier Zeit sparen, aber es spart Übersetzungszeit, nicht Beurteilungszeit.

Die Urteilszeit kann nicht ausgelagert werden. Gradle 8 sieht neuer aus, Java 17 sieht moderner aus und der direkte Sprung nach oben sieht auch sauberer aus, aber diese Optionen erfüllen möglicherweise nicht gleichzeitig die Einschränkungen des alten Quellcodes und alter Tests. Die größte Angst bei der Modernisierung besteht darin, Werkzeug-Upgrades als Fortschritt und das Ausführen von Befehlen als Verständnis des Systems zu betrachten. Solange ein Projekt die operative Basislinie nicht erreicht hat, gelten grüne Tests nicht als Sieg, sondern nur als vorläufiges Nichterreichen der exponierten Oberfläche.

Der Ansatz, dem ich mehr vertraue, besteht darin, das Problem zunächst in vier Ebenen zu unterteilen: ob es ausgeführt werden kann, ob es bearbeitet werden kann, ob es getestet werden kann und ob es geändert werden kann. Die erste Ebene besteht darin, die Szene zu reproduzieren, die zweite Ebene besteht darin, die Brücke zu bestimmen, die dritte Ebene besteht darin, zu bestimmen, was der alte Test gespeichert hat, und die vierte Ebene ist das eigentliche Refactoring. Copilot ist besonders auf den ersten beiden Ebenen nützlich. Es eignet sich für die physische Arbeit nach Protokollen und Verzeichnisstrukturen und zum Zusammenfügen fragmentierter Hinweise zu einer lesbaren Karte. Auf der vierten Ebene sollte das Modell nur für Transport und Eingabeaufforderungen verantwortlich sein, und die Menschen müssen sich bei Entscheidungen auf Menschen verlassen.

Das wertvollste Ergebnis der Modernisierung des alten Systems besteht darin, eine Reihe von Dingen, die „funktionieren sollten“, in „Dinge zu verwandeln, die tatsächlich funktionieren, und wir wissen, warum sie funktionieren“. Sobald diese Kompatibilitätsleiter etabliert ist, wird der anschließende Abbau einen Rhythmus haben und den Änderungen Grenzen gesetzt sein. Copilot ist zu diesem Zeitpunkt wie ein Assistent an vorderster Front, der mit einer Taschenlampe nach Alter, Eintritt und Abhängigkeiten sucht. Was wirklich die Richtung bestimmt, ist die Beurteilung der Geschichte des alten Systems.