Au hasard de nos lectures matinales, on tombe parfois sur des réflexions intéressantes sur des pratiques qui semblent bonnes mais qui peuvent se révéler piégeuses. Ainsi, un développeur veut nettoyer les dépendances d'un projet suite à la décision d'une monter de version impliquant forcément une modification de la stack technique. Cela implique aussi de faire évolution les dépendances du projet. 

En apparence :

1 / super bonne idée = bonne pratique !

2 / audit des dépendances (côté développement)

3 / des dépendances paraissent obsolètes ou pas utilisées : donc je supprime

Conséquence :

4 / je supprime une à une les dépendances qui ne semblent pas utile en production. Action manuelle.

Bref : bonne pratique en théorie mais en réalité, elle peut se retourner contre vous en introduisant des effets de bord. Car certaines dépendances peuvent se révéler cacher...

Notre développeur travaille méthodiquement :

1 / comme le projet est bien couvert par les tests, il avance en terrain relativement connu, a priori.

2 / il établit tout d'abord un arbre de dépendances

3 / il avance étape par étape : retrait d'une dépendance, tests

Si le test est OK, la dépendance retirée n'a a priori aucun impact. On passe à l'étape suivante. Si le dépendance retirée génère une erreur dans les tests, on fixe, on documente et on passe à la suite. Le projet s'appuie sur des composants Apache, Web, Java, bref du classique. 

Notre développeur supprime alors la dépendance commons-io. En environnement de développement et en pré-production, tout semble ok. Les tests ne génèrent pas d'erreurs ou de warnings. En toute confiance, il déploie l'application avec les nouvelles dépendances... Et là : échec. 

Comment expliquer le problème ? Notre développeur décide d'utiliser un outil Apache très pratique : mvn dependency:tree pour voir l'arbre du projet et les dépendances liées. En analysant le tree, il comprend que commons-io se cache dans une dépendance de test. La subtilité vient du fait que la dépendance est "cachée" par une autre dépendance technique qui ne se voit pas forcément sauf quand il est passé en production. 

C'est que l'on appelle une dépendance transitive, un problème bien connu.

Pour faire simple, une dépendance n'est pas forcément directement importée dans le projet mais par un autre dépendance. On se retrouve alors avec une imbrication de dépendances mêlant les dépendances directes et indirectes (= dépendances transitives). Cette imbrication multiplie les appels de dépendances et peut alors générer des effets de bord quand on commence à retirer une dépendance transitive sans le savoir (dépendance appelée par une dépendance directe par exemple). 

Une bonne pratique serait alors d'automatiser la gestion des dépendances pour tenir à jour les arbres de dépendances et versionner chaque dépendance. Ainsi, ce mécanisme évite de supprimer une dépendance manuellement et de maintenir un arbre à jour et propre.

Autre bonne pratique : avoir l'environnement de production strictement identique pour tester dans des conditions réelles avec la même configuration, les mêmes contraintes. Cela peut éviter de découvrir le problème lors de la mise ne production. 

Inspiration : Julien L., Thomas C., Alexandre P.