Les 9 Commandements D'une Migration

Vous arrivez sur un projet qui semble avoir été laissé à l’abandon. Il s’agit d’une véritable zone de guerre ou chaque modification peut vous péter à la figure. Les technologies utilisées sont complétement obsolètes. Votre mission, remettre en état ce projet.

9 Commandements

Sans plus attendre voici la liste des 7 commandements à appliquer pour survivre sur un tel projet

Sans tests, tu ne commenceras.

Afin de valider que les changements apportés au système ne cassent rien, il faut absolument des tests. Le mieux est de disposer d’une couverture de test automatisée complète de l’application. Le problème est que souvent ce genre d’application à l’abandon ne dispose généralement pas de couverture de test.

Dans ces cas-là, il faut soit la développer avant de commencer, soit prévoir un cahier de test le plus exhaustif possible qui sera joué manuellement pour vérifier que rien n’est cassé.

Une version à la fois, tu feras.

Chaque changement de version majeur d’une bibliothèque ou d’un cadriciel se fera de manière unitaire et sera suivi d’une passe complète de tests. Cela évitera de couteuses recherches pour déterminer qui est la cause d’un bogue.

Même dans le cas d’un cadriciel comme SpringBoot, il est possible de changer la version des bibliothèques séparément les unes des autres. Dans ce cas, il convient de regarder quelle bibliothèque dispose d’une nouvelle version cassante.

Compiler, en premier, tu devras

Il est souvent tentant lors de l’adaptation du code suite à une montée de version d’une bibliothèque ou d’un cadriciel de vouloir aussi corriger du code mal écrit ou un peu vieillot. Ce qu’on appelle couramment du refactoring.

Il s’agit d’un piège à éviter absolument, car cela rendra très difficile de savoir d’où proviens d’une erreur. Il est, en effet, très facile d’oublier un cas d’usage dans un algorithm. Le refactoring sera fait soit une fois que les montées de version seront terminées, soit avant afin de faciliter ces montées.

Les notes de version, avec empressement, tu chercheras

Rien de mieux que des notes de version ou changelog, afin de déterminer les changements importants pouvant poser un problème. Si un bogue apparaît suite à une montée de version, la solution se trouve peut-être dans la documentation du projet.

Certains projets proposent même des guides de migration. Ces derniers sont un gain de temps non négligeable s’ils sont bien réalisés

Les dépréciations tu enlèveras

Après une montée de version, il est possible que des dépréciations apparaissent. Une fois, le projet tourne à nouveau sans bogues, il est important de supprimer ces dépréciations qui seront autant de bogues potentiel dans une future version. Pour le moment, ces dépréciations sont clairement indiquées et généralement correctement documentées. Cela ne sera plus forcément le cas lorsque la bibliothèque ou le cadriciel aura complétement abandonné cette manière de faire.

Sur ton IDE, tu t’appuieras.

Avoir un bon IDE est important en règle générale dans le développement. Cela devient vital lors d’une montée de version entrainant des changements dans le code. En effet, le gain de temps d’un ide signalant les erreurs ou capables de migrer automatiquement du code déprécié est un plus non négligeable. Pouvoir réusiner du code en grande quantité sans introduire de nouveaux bogues est aussi un atout des bons IDE.

Vers les standards, tu te dirigeras

Une des causes principales de l’échec des montées de version, est le fait d’avoir trop dévié des standards et des conventions suivis par la bibliothèque ou le cadriciel. Il faut dont autant que possible profiter du refactoring induit par une montée de version pour retourner le plus possible vers les standards actuels.

Cela peut également être une chose à faire avant une migration afin de faciliter cette dernière.

T’obstiner, tu ne feras

Il arrive souvent sur ce genre de projet, penser avoir la solution à une migration pour se rendre compte que les modifications prennent plus de temps que prévue. Dans ce genre de cas, c’est fréquemment le signe qu’une autre méthode est possible et qu’il faut repenser la stratégie. S’obstiner ne sert à rien et fait perdre du temps. Il ne faut pas hésiter à supprimer l’ensemble des modifications réalisées avant de recommencer différemment.

Des commits réguliers tu feras

Afin de faciliter les retours en arrière, des commits réguliers devront être fait à chaque état stable atteint suite à une montée de version. Cela permet de revenir en arrière facilement sans devoir supprimer de précieuses modifications. Cela fait aussi office de documentation pour la migration de futurs projets utilisant la même stack technologique.

Conclusion

Voici le 9 commandements issus de mon expérience de développeur, principalement passé sur ce genre de projet. Ces tâches ne sont jamais faciles, mais peuvent être extrêmement gratifiantes et formatrices en obligeant à entrer dans le détail du fonctionnement des bibliothèques et cadriciel utilisés.