Modernisez d’abord l’ancien système et construisez l’échelle de compatibilité

La première fois que j’ai ouvert un projet Java il y a vingt ans, la première chose que j’ai vue n’était pas l’odeur du code, mais l’odeur de l’âge. Le build.xml est toujours là, mais le pom.xml n’est pas là ; la structure des répertoires est démodée, l’entrée de test est également démodée, et même « s’il peut reconstruire un produit exécutable » doit être reconfirmé. L’erreur la plus courante à ce stade est de se concentrer sur les cours et les méthodes et d’ignorer que ce qui bloque réellement la modernisation, c’est l’environnement et l’entrée.

La première chose à faire lors de la modernisation d’anciens systèmes est de construire une échelle de compatibilité. La base de l’échelle n’a généralement qu’une seule chose : faire fonctionner l’ancien système de manière stable dans le cadre des anciennes règles, et de préférence servir de capsule temporelle. Docker, ancien JDK, anciens outils de construction, anciennes commandes de test, ces choses semblent grossières, mais elles sont très efficaces. Tant que cette base n’est pas droite, chaque changement ultérieur se mêlera à un nouveau bruit : que ce soit le code qui est cassé, ou la JVM, l’image, l’architecture et les plug-ins qui sont cassés, il est impossible de le dire.

Puis ce fut au tour de choisir le pont. Le but du pont est très précis : une extrémité est connectée à l’ancien code source, et l’autre extrémité est connectée à la nouvelle machine. Ce projet est finalement tombé entre les mains de Java 8 et Gradle 7.6, qui se sont contentés de contraintes des deux côtés : Java 17 n’est plus disposé à compiler le code source de Java 1.5, et Java 6 ne peut pas s’exécuter dans l’environnement natif d’ARM64. Si le pont est mauvais, la modernisation restera coincée dans la chaîne d’outils ; si le pont est correct, les migrations ultérieures pourront avancer étape par étape.

La chose la plus utile ici est de laisser le grand modèle se charger de l’organisation et de la traduction. Cela peut aider à traduire la logique Ant dans Gradle, à reconnecter les répertoires à l’ancienne présentation et à supprimer ces configurations répétitives et mécaniques. Par exemple, pointez explicitement le répertoire du code source vers l’ancien chemin et ajoutez une tâche personnalisée pour exécuter l’ancien test main() :

java {
    sourceCompatibility = JavaVersion.VERSION_1_5
    targetCompatibility = JavaVersion.VERSION_1_5
}
sourceSets {
    main {
        java {
            srcDirs = ['java']
        }
    }
}
tasks.register('runLegacyTest', JavaExec) {
    mainClass.set(project.findProperty('mainClass'))
    classpath = sourceSets.main.runtimeClasspath
}

L’intérêt de cette configuration est de rendre explicites les règles de l’ancien monde. La chose la plus gênante dans les anciens projets n’est souvent pas le manque de capacité, mais cette capacité est cachée dans les habitudes. Le test est exécuté via l’entrée main(), le code source est placé dans l’ancien répertoire et la construction est écrite en supposant le chemin de l’ère Ant. Copilot peut gagner du temps ici, mais il permet de gagner du temps de traduction, pas du temps de jugement.

Le temps de jugement ne peut pas être externalisé. Gradle 8 semble plus récent, Java 17 semble plus moderne et sauter directement vers le haut semble également plus propre, mais ces options peuvent ne pas satisfaire en même temps les contraintes de l’ancien code source et des anciens tests. La plus grande crainte en matière de modernisation est de considérer les mises à niveau des outils comme un progrès et l’exécution des commandes comme une compréhension du système. Tant qu’un projet n’a pas atteint la base opérationnelle, les tests écologiques ne sont pas considérés comme une victoire, ils peuvent seulement être considérés comme n’atteignant pas la surface exposée pour le moment.

L’approche à laquelle je fais le plus confiance consiste d’abord à diviser le problème en quatre niveaux : s’il peut être exécuté, s’il peut être modifié, s’il peut être testé et s’il peut être modifié. Le premier niveau consiste à reproduire la scène, le deuxième niveau consiste à déterminer le pont, le troisième niveau consiste à déterminer ce que l’ancien test a sauvegardé et le quatrième niveau est le véritable refactoring. Copilot est particulièrement utile sur les deux premiers niveaux. Il convient au travail physique suivant les journaux et les structures de répertoires, et à rassembler des indices fragmentés dans une carte lisible. Au quatrième niveau, le modèle ne devrait être responsable que du transport et des invites, et les gens doivent compter sur les gens pour prendre des décisions.

Le résultat le plus précieux de la modernisation de l’ancien système est de transformer un ensemble de choses qui « devraient fonctionner » en « des choses qui fonctionnent réellement et dont nous savons pourquoi elles fonctionnent ». Une fois cette échelle de compatibilité établie, les démantèlements ultérieurs auront un rythme et les changements auront des limites. Copilot est comme un assistant en première ligne en ce moment, tenant une lampe de poche pour regarder l’âge, l’entrée et les dépendances. Ce qui détermine réellement l’orientation, c’est le jugement sur l’histoire de l’ancien système.