Back home

Voor het moderniseren van oude code is eerst archeologie nodig

Voordat u AI in oude projecten plaatst, scheidt u de tijdperklaag, de bouwlaag en de testlaag

Voor het moderniseren van oude code is eerst archeologie nodig

Het moeilijkste aan oude code is nooit de oude syntaxis, maar de oude tijden. Een project zit vol met build.xml, oude JDK, een oud testframework en oude verpakkingsmethoden. Oppervlakkig gezien lijken het meerdere stapels dossiers, maar in werkelijkheid zijn het lagen van historische aannames die op elkaar zijn gestapeld. De code zelf is slechts de buitenste laag. Wat de uitvoering werkelijk blokkeert, is vaak de vraag of deze aannames er nog steeds zijn, of ze kunnen worden gereproduceerd en of het oude gedrag na veranderingen verloren zal gaan.

Dit is de reden waarom ‘archeologie’ aan ‘transformatie’ voorafgaat. Kijk eerst naar het buildbestand, vervolgens naar de afhankelijkheden, vervolgens naar de actieve omgeving en vervolgens naar de tests. De volgorde kan niet worden teruggedraaid. De build.xml is er nog steeds, maar de pom.xml bestaat niet. Dergelijke signalen zijn voldoende om aan te geven dat het project in het Ant-tijdperk leeft; of de code kan worden gecompileerd, of de tests kunnen worden uitgevoerd en of het product opnieuw kan worden opgebouwd, zijn het eerste bewijs. Het nuttigste deel van het model hier is niet om onmiddellijk nieuwe code voor de oude code te schrijven, maar om deze bewijzen te identificeren uit een stapel fragmenten.

Ook moet eerst de omgeving vastgezet worden. Oude code wordt vaak geleverd met oude JVM’s, oude containers en oude architecturale aannames. Gooi het rechtstreeks op de machines van vandaag, vooral in een omgeving die meerdere architectuur omvat, en het is gemakkelijk om er nieuwe ruis in te mengen als er zich problemen voordoen: is de code inherent kapot, of zijn het emulatie, spiegeling en toolketens die problemen veroorzaken? Als je in dit stadium niet eens kunt bereiken dat “dezelfde code stabiel kan worden gereproduceerd in dezelfde omgeving”, zullen alle daaropvolgende moderniseringsacties slechts giswerk zijn.

De waarde van AI in deze stap is duidelijk: het kan helpen bij de vertaling op karakter- en structuurniveau. Het converteren van Ant naar Gradle, het converteren van oude build-scripts naar een nu onderhoudbare vorm, het verplaatsen van een hoop repetitieve XML en boilerplate naar een duidelijkere locatie zijn allemaal dingen die goede kandidaten zijn om aan modellen over te laten. Het is snel, bereid om het keer op keer te proberen, en niet te triviaal. Maar het is niet geschikt voor scheidsrechters. Welke waarschuwingen kunnen als eerste worden bewaard, welke tests liegen er eigenlijk, welke modules moeten als eerste worden afgesneden en welke klassen moeten alleen worden verpakt en aangepast. Uiteindelijk moet het nog steeds door mensen worden besloten.

Testen is de gemakkelijkste manier om mensen voor de gek te houden. Het slagen voor de tests in het oude project betekent niet dat het systeem wordt begrepen, het kan alleen maar betekenen dat sommige oude gedragingen gewoon in de huidige omgeving zijn ingepakt. Dat ‘helemaal groene’ gevoel is gevaarlijk omdat het vaak een groter probleem maskeert: wat de test verifieert zijn de implementatiedetails van een bepaald tijdperk, niet de zakelijke semantiek die nu behouden moet blijven. Als je echt wilt hervormen, is het eerste wat je moet doen deze tests uit het ‘decoratieve gevoel van veiligheid’ halen en opnieuw beoordelen wat ze beschermen.

Daarom is de meest stabiele manier voor dit soort projecten meestal niet om het in één keer te herschrijven, maar om eerst een tijdcapsule te creëren om de oude omgeving, oud gedrag en oude afhankelijkheden te herstellen, en deze vervolgens langs de smalste scheuren te verwijderen. Maak eerst het systeem reproduceerbaar, geef het repetitieve werk vervolgens ter vertaling over aan AI en trek vervolgens de grenzen laag voor laag weg. Als de orde niet in orde is, zal het model het oude project versnellen en in een diepere chaos duwen; als de volgorde correct is, zal het model een echt nuttige archeologische assistent zijn, verantwoordelijk voor het verplaatsen van stenen, het opruimen van stof en het vergelijken van bewijsmateriaal, het bevrijden van mensen van vuil werk en het oordeel in hun handen laten.