Bij het moderniseren van het oude systeem organiseert Copilot eerst het bewijsmateriaal

De eerste keer dat ik een Java-project uit het 1.5-tijdperk naar een moderne machine trok, was het eerste dat opdook niet het codeprobleem, maar het bewijsprobleem. Of de build nu kan worden gereproduceerd, of de testuitvoer hetzelfde is, of het foutpunt afkomstig is van de JVM, de afbeelding of de broncode, deze dingen bepalen hoe verder te gaan voordat we beginnen met refactoring. De grootste angst bij het moderniseren van oude systemen is niet dat de veranderingen langzaam gaan, maar dat het onmogelijk is te zeggen wat er na de veranderingen is gebeurd.

Repareer eerst de scène, daarna zullen de daaropvolgende acties zinvol zijn. Het meest waardevolle in die stap is niet de voltooiing in de IDE, maar een box die herhaaldelijk kan worden uitgevoerd: de oude JDK, oude buildtools, oude ingangen en oude testopdrachten zijn allemaal vergrendeld in Docker. Commando’s zoals de volgende zijn niet mooi, maar ze werken:

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

Dit commando heeft maar één functie: de mislukking van vandaag omzetten in herspeelbaar bewijsmateriaal. Zonder dit zou elk volgend succes wel eens het resultaat kunnen zijn van omstandigheden die toevallig vergevingsgezind waren. De rol van Copilot is hier ook heel duidelijk. Het is niet bedoeld om het oordeel te vervangen, maar om sporen te helpen uitzoeken: herhaalde fouten in lange logs, paden die elkaar herhalen in build-scripts en verschillende terugkerende vermeldingen in oude tests kunnen allemaal eerst worden gebruikt voor een ruwe screening. Wat eruit wordt gezeefd is geen conclusie, maar een kaart om mee te beginnen.

Als het tijd is om daadwerkelijk onder het mes te gaan, moet het veranderingsgebied erg smal zijn. De gemakkelijkste manier om oude projecten ongedaan te maken is door de pakketnaam, build, entry en test in één keer te veranderen. Uiteindelijk kun je niet eens zeggen welke stap het systeem kapot heeft gemaakt. Een stabielere aanpak is om eerst de kleinste opening te benutten: bedek bijvoorbeeld de oude ingang met een laag adapters, laat de nieuwe gereedschapsketen eerst buiten de oude wereld staan ​​en de structuur duidelijk zien, en dan langzaam naar binnen bewegen. Copilot is zeer geschikt voor het afhandelen van dit soort mechanisch werk: het vullen van importen, het verplaatsen van configuraties, het extraheren van herhaalde fragmenten en het genereren van tijdelijke testskeletten. Laat het model deze dingen doen, en de efficiëntie is inderdaad hoog; maar het is nog steeds aan mensen om te beslissen of deze naad moet worden doorgesneden en welk gedrag na het snijden moet worden behouden.

Ook als het om testen gaat, kun je je gemakkelijk laten misleiden door de schijn. Het doorstaan ​​van de oude test betekent niet dat modernisering veilig is, het betekent alleen dat bepaalde historische gedragingen nog niet zijn doorbroken. De tests van veel oude projecten lijken meer op gedragsmomentopnamen dan op zakelijke semantische specificaties. Groen is gewoon groen en kan niet direct worden geïnterpreteerd als ‘het systeem begrijpen’. Een van de belangrijkste acties tijdens de transformatie is het toevoegen van nieuwe, smallere testgrenzen aan elke kleine incisie, zodat de test geleidelijk verandert van “historische erfenis” naar “huidige beperkingen”. Copilot kan helpen bij het afbreken van oude beweringen, het voltooien van sjablonen en het uitrollen van dubbele testshells. Welke semantiek moet echter in de test worden gehandhaafd en het model kan geen beslissingen nemen voor het systeem.

Bij archeologische modernisering is de meest betrouwbare taakverdeling eigenlijk heel eenvoudig: de omgeving en de boomstammen zijn verantwoordelijk voor het vaststellen van de feiten, Copilot is verantwoordelijk voor het verplaatsen van stenen en het vertalen, en mensen zijn verantwoordelijk voor het beslissen welke geschiedenis behouden moet blijven en welke geschiedenis moet worden afgesneden. Als er eenmaal een model is opgesteld om het verleden van het systeem te verklaren, zijn gissingen vaak overtuigender dan bewijs; Door het terug te plaatsen in de positie van bewijsbeheer en mechanische organisatie, wordt het meer een werkelijk nuttige assistent.