En modernisant l’ancien système, Copilot organise d’abord les preuves

La première fois que j’ai transféré un projet Java de l’ère 1.5 sur une machine moderne, la première chose qui est apparue n’était pas le problème du code, mais le problème des preuves. Que la construction puisse être reproduite, que le résultat du test soit le même, que le point de défaillance provienne de la JVM, de l’image ou du code source, ces éléments déterminent comment procéder avant de « démarrer le refactoring ». La plus grande crainte lors de la modernisation des anciens systèmes n’est pas que les changements soient lents, mais qu’il soit impossible de savoir ce qui s’est passé après les changements.

Corrigez d’abord la scène, les actions suivantes auront alors un sens. La chose la plus précieuse dans cette étape n’est pas l’achèvement dans l’EDI, mais une boîte qui peut être exécutée à plusieurs reprises : l’ancien JDK, les anciens outils de construction, les anciennes entrées et les anciennes commandes de test sont tous verrouillés dans Docker. Les commandes comme celles-ci ne sont pas jolies, mais elles fonctionnent :

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

Cette commande n’a qu’une seule fonction : corriger « l’échec d’aujourd’hui » en preuve rejouable. Sans cela, chaque succès ultérieur pourrait simplement être le résultat de circonstances qui se sont avérées indulgentes. Le rôle de Copilot ici est également très clair. Il ne s’agit pas de remplacer le jugement, mais d’aider à trier les traces : des erreurs répétées dans de longs journaux, des chemins qui se font écho dans les scripts de construction et plusieurs entrées récurrentes dans d’anciens tests peuvent tous être utilisés pour un premier tri. Ce qui est filtré n’est pas une conclusion, mais une carte de départ.

Quand vient le temps de passer réellement sous le bistouri, la zone de changement doit être très étroite. Le moyen le plus simple de renverser d’anciens projets est de modifier le nom du package, la construction, l’entrée et le test en même temps. En fin de compte, vous ne pouvez même pas dire quelle étape a brisé le système. Une approche plus stable consiste à saisir d’abord le plus petit espace : par exemple, recouvrir l’ancienne entrée avec une couche d’adaptateurs, permettre d’abord à la nouvelle chaîne d’outils de se tenir en dehors de l’ancien monde et de voir clairement la structure, puis d’y entrer lentement. Copilot est très approprié pour gérer ce type de travail mécanique : remplir des importations, déplacer des configurations, extraire des fragments répétés et générer des squelettes de test temporaires. Laissez le modèle faire ces choses, et l’efficacité est effectivement élevée ; mais c’est toujours aux gens de décider si cette couture doit être coupée et quel comportement doit être conservé après la coupe.

Il est également facile de se laisser tromper par les apparences lorsqu’il s’agit de tests. Réussir l’ancien test ne signifie pas que la modernisation est sûre, cela signifie simplement que certains comportements historiques n’ont pas encore été brisés. Les tests de nombreux projets anciens ressemblent davantage à des instantanés comportementaux qu’à des spécifications sémantiques métier. Le vert est simplement vert et ne peut pas être directement interprété comme « comprendre le système ». L’une des actions les plus importantes au cours de la transformation consiste à ajouter de nouvelles limites de test plus étroites à chaque petite incision, afin que le test passe progressivement d’un « héritage historique » à des « contraintes actuelles ». Copilot peut aider à décomposer les anciennes assertions, à compléter des modèles et à déployer des shells de test en double. Cependant, la sémantique qui doit être conservée dans le test et le modèle ne peuvent pas prendre de décisions pour le système.

Dans la modernisation archéologique, la division du travail la plus fiable est en réalité très simple : l’environnement et les journaux sont responsables de la fixation des faits, Copilot est responsable du déplacement des briques et de la traduction, et les gens sont responsables de décider quelle histoire doit être conservée et laquelle histoire doit être supprimée. Une fois qu’un modèle est élaboré pour expliquer le passé du système, il donne souvent lieu à des suppositions plus convaincantes qu’à des preuves ; en le replaçant dans la position de gestion des preuves et d’organisation mécanique, il devient davantage un assistant véritablement utile.