Die Modernisierung alten Codes erfordert zunächst Archäologie

Das Schwierigste an altem Code ist nie die alte Syntax, sondern die alten Zeiten. Ein Projekt ist vollgestopft mit build.xml, altem JDK, altem Test-Framework und alten Verpackungsmethoden. Oberflächlich betrachtet sieht es aus wie mehrere Aktenstapel, in Wirklichkeit handelt es sich jedoch um übereinander gestapelte Schichten historischer Annahmen. Der Code selbst ist nur die äußerste Schicht. Was die Umsetzung wirklich blockiert, ist oft, ob diese Annahmen noch vorhanden sind, ob sie reproduziert werden können und ob das alte Verhalten nach Änderungen verloren geht.

Deshalb geht „Archäologie“ der „Transformation“ voraus. Schauen Sie sich zuerst die Build-Datei an, dann die Abhängigkeiten, dann die laufende Umgebung und dann die Tests. Die Reihenfolge kann nicht rückgängig gemacht werden. Die build.xml ist immer noch vorhanden, aber die pom.xml existiert nicht. Solche Signale reichen aus, um darauf hinzuweisen, dass das Projekt in der Ant-Ära lebt; Ob der Code kompiliert werden kann, ob die Tests ausgeführt werden können und ob das Produkt neu erstellt werden kann, sind die ersten Beweise. Der nützlichste Teil des Modells besteht hier nicht darin, sofort neuen Code für den alten Code zu schreiben, sondern diese Beweise aus einem Stapel von Fragmenten zu identifizieren.

Auch die Umgebung muss zunächst gepinnt werden. Alter Code geht oft mit alten JVMs, alten Containern und alten Architekturannahmen einher. Werfen Sie es direkt auf die heutigen Maschinen, insbesondere in einer architekturübergreifenden Umgebung, und es ist einfach, neues Rauschen einzumischen, wenn Probleme auftreten: Ist der Code von Natur aus kaputt oder sind es Emulation, Spiegelung und Toolketten, die Probleme verursachen? Wenn Sie zu diesem Zeitpunkt nicht einmal erreichen können, dass „derselbe Code in derselben Umgebung stabil reproduziert werden kann“, werden alle nachfolgenden Modernisierungsmaßnahmen nur Vermutungen sein.

Der Wert der KI in diesem Schritt liegt auf der Hand: Sie kann bei der Übersetzung auf Zeichen- und Strukturebene helfen. Das Konvertieren von Ant in Gradle, das Konvertieren alter Build-Skripte in eine jetzt wartbare Form und das Verschieben einer Reihe sich wiederholender XML- und Boilerplates an einen übersichtlicheren Ort sind alles Dinge, die sich gut für die Überlassung an Modelle eignen. Es ist schnell, bereit, es immer wieder zu versuchen, und nicht zu trivial. Als Schiedsrichter ist es aber nicht geeignet. Welche Warnungen können zuerst beibehalten werden, welche Tests lügen tatsächlich, welche Module sollten zuerst abgeschnitten werden und welche Klassen sollten nur verpackt und angepasst werden. Am Ende müssen es immer noch die Menschen entscheiden.

Tests sind der einfachste Weg, Menschen zu täuschen. Das Bestehen der Tests im alten Projekt bedeutet nicht, dass das System verstanden wird, es bedeutet möglicherweise nur, dass einige alte Verhaltensweisen einfach in die aktuelle Umgebung eingebettet sind. Dieses „ganz grüne“ Gefühl ist gefährlich, weil es oft ein größeres Problem verdeckt: Was der Test überprüft, sind die Implementierungsdetails einer bestimmten Ära, nicht die Geschäftssemantik, die jetzt erhalten bleiben muss. Wenn Sie wirklich reformieren wollen, müssen Sie diese Tests zunächst aus dem „dekorativen Sicherheitsgefühl“ herausnehmen und neu beurteilen, was sie schützen.

Daher besteht der stabilste Weg für diese Art von Projekt normalerweise nicht darin, es auf einmal neu zu schreiben, sondern zunächst eine Zeitkapsel zu erstellen, um die alte Umgebung, alte Verhaltensweisen und alten Abhängigkeiten zu reparieren, und sie dann entlang der engsten Risse zu entfernen. Machen Sie das System zunächst reproduzierbar, übergeben Sie dann die sich wiederholende Arbeit zur Übersetzung an die KI und lösen Sie dann die Grenzen Schicht für Schicht ab. Wenn die Ordnung nicht in Ordnung ist, wird das Modell das alte Projekt beschleunigen und es in noch tieferes Chaos stürzen; Wenn die Reihenfolge korrekt ist, wird das Modell wie ein wirklich nützlicher archäologischer Assistent sein, der für das Bewegen von Ziegeln, das Entfernen von Staub und das Vergleichen von Beweisen verantwortlich ist, wodurch die Menschen von der Drecksarbeit befreit werden und ihnen das Urteil überlassen bleibt.