Moderniser l’ancien code nécessite d’abord l’archéologie

La chose la plus difficile dans l’ancien code n’est jamais l’ancienne syntaxe, mais l’ancien temps. Un projet est rempli de build.xml, d’ancien JDK, d’ancien cadre de test et d’anciennes méthodes d’empaquetage. En apparence, cela ressemble à plusieurs piles de dossiers, mais il s’agit en réalité de couches d’hypothèses historiques empilées les unes sur les autres. Le code lui-même n’est que la couche la plus externe. Ce qui bloque réellement la réalisation, c’est souvent la question de savoir si ces hypothèses sont toujours là, si elles peuvent être reproduites et si l’ancien comportement sera perdu après les changements.

C’est pourquoi « l’archéologie » précède la « transformation ». Regardez d’abord le fichier de build, puis les dépendances, puis l’environnement d’exécution, puis les tests. L’ordre ne peut pas être annulé. Le build.xml est toujours là, mais le pom.xml n’existe pas. De tels signaux suffisent à indiquer que le projet vit à l’ère des fourmis ; si le code peut être compilé, si les tests peuvent être exécutés et si le produit peut être reconstruit sont la première preuve. La partie la plus utile du modèle ici n’est pas d’écrire immédiatement un nouveau code pour l’ancien code, mais d’identifier ces preuves à partir d’une pile de fragments.

L’environnement doit également être épinglé en premier. L’ancien code est souvent accompagné d’anciennes JVM, d’anciens conteneurs et d’anciennes hypothèses architecturales. Jetez-le directement sur les machines d’aujourd’hui, en particulier dans un environnement multi-architecture, et il est facile d’ajouter du nouveau bruit lorsque des problèmes surviennent : le code est-il intrinsèquement défectueux, ou est-ce l’émulation, la mise en miroir et les chaînes d’outils qui causent des problèmes ? Si vous ne parvenez même pas à « le même code puisse être reproduit de manière stable dans le même environnement » à ce stade, toutes les actions de modernisation ultérieures ne seront que des suppositions.

La valeur de l’IA dans cette étape est claire : elle peut aider à la traduction au niveau des caractères et de la structure. Convertir Ant en Gradle, convertir d’anciens scripts de build en une forme désormais maintenable, déplacer un tas de XML répétitifs et de passe-partout vers un emplacement plus clair sont autant de choses qui sont de bons candidats à laisser aux modèles. C’est rapide, prêt à essayer encore et encore, et ce n’est pas trop anodin. Mais ce n’est pas adapté à l’arbitrage. Quels avertissements peuvent être conservés en premier, quels tests mentent réellement, quels modules doivent être supprimés en premier et quelles classes doivent uniquement être empaquetées et adaptées. En fin de compte, cela doit encore être décidé par les gens.

Les tests sont le moyen le plus simple de tromper les gens. Réussir les tests dans l’ancien projet ne signifie pas que le système est compris, cela peut simplement signifier que certains anciens comportements sont simplement intégrés dans l’environnement actuel. Ce sentiment de « tout vert » est dangereux car il masque souvent un problème plus vaste : ce que le test vérifie, ce sont les détails de mise en œuvre d’une certaine époque, et non la sémantique commerciale qui doit être préservée aujourd’hui. Si l’on veut vraiment réformer, la première chose à faire est de sortir ces tests du « sentiment décoratif de sécurité » et de réévaluer ce qu’ils protègent.

Par conséquent, le moyen le plus stable pour ce type de projet n’est généralement pas de le réécrire d’un seul coup, mais de créer d’abord une capsule temporelle pour corriger l’ancien environnement, les anciens comportements et les anciennes dépendances, puis de la supprimer le long des fissures les plus étroites. Rendez d’abord le système reproductible, puis confiez le travail répétitif à l’IA pour traduction, puis éliminez les limites couche par couche. Si l’ordre est en désordre, le modèle accélérera l’ancien projet et le poussera dans un chaos plus profond ; si l’ordre est correct, le modèle sera comme un assistant archéologique vraiment utile, chargé de déplacer les briques, de nettoyer la poussière et de comparer les preuves, libérant ainsi les gens du sale boulot et leur laissant le jugement entre leurs mains.