A Longitudinal Study of Dependency Reclassifications in JavaScript Projects
Cette étude longitudinale de 33 087 projets JavaScript révèle que la reclassification des dépendances (suppression, réaffectation de rôle ou réintroduction) est une activité de maintenance prédominante et souvent cyclique, s'étendant sur de longues périodes et nécessitant de nouvelles approches pour les outils et les gestionnaires de paquets.
Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète
Imaginez que gérer les dépendances d'un projet informatique, c'est comme gérer le placard à épices d'un grand restaurant.
Dans ce restaurant (le projet logiciel), vous avez trois types d'épices :
- Les épices de base (Core) : Celles qu'on utilise chaque jour pour cuisiner les plats servis aux clients (en production).
- Les outils de cuisine (Dev) : Les couteaux, les mixeurs ou les épices qu'on utilise seulement pour préparer le menu ou tester de nouvelles recettes, mais qu'on ne met pas dans l'assiette finale.
- Les ingrédients du client (Peer) : Des ingrédients que le client est censé apporter lui-même. Le restaurant dit : "Vous apportez le sel, nous apportons le poivre".
Le problème : Le placard change tout le temps
Jusqu'à présent, les chercheurs s'intéressaient surtout à savoir si les gens changeaient la marque de leur farine (mettre à jour la version). Mais personne ne se demandait : "Est-ce qu'on se trompe parfois sur le fait que cette épice doit être dans le placard de base ou dans celui des outils ?"
Cette étude, menée par des chercheurs suédois et canadiens, a regardé 33 000 projets informatiques (des milliers de placards) pour voir comment les chefs (les développeurs) réorganisent leurs épices au fil du temps.
Ce qu'ils ont découvert (en images)
1. C'est un travail de réorganisation constant
Ils ont découvert que 79 % des projets ne se contentent pas d'ajouter des épices. Ils les déplacent.
- Parfois, on réalise qu'une épice qu'on croyait indispensable pour le service (Core) n'était en fait utile que pour la préparation (Dev). On la déplace donc du placard principal vers l'arrière-cuisine.
- Parfois, on réalise qu'on a oublié d'acheter une épice et qu'on doit la remettre.
- Parfois, on se dit : "Attends, ce client devrait apporter ce sel lui-même" (on passe de Core à Peer).
2. Le grand ménage (Suppression)
La chose la plus fréquente ? Jeter des épices.
- 97 % des projets finissent par retirer des dépendances.
- Souvent, c'est un grand ménage : on jette 10 épices d'un coup parce qu'on a changé de méthode de cuisson.
- Mais attention : Parfois, on jette trop vite ! Dans 33 % des cas, les chefs réalisent quelques jours ou mois plus tard : "Oh non, on a besoin de cette épice !". Ils doivent donc la remettre dans le placard. C'est comme si vous jetiez un ustensile, puis vous deviez courir au magasin pour le racheter deux jours plus tard.
3. L'errance (Oscillation)
Certains ingrédients sont très indécis. Ils passent du placard principal à l'arrière-cuisine, puis reviennent, puis repartent.
- Imaginez un développeur qui hésite : "Est-ce que cette librairie sert à l'application finale ou juste pour tester ?".
- Il la met dans "Core", puis réalise qu'elle alourdit le plat, la met dans "Dev", puis réalise qu'il en a besoin pour une fonctionnalité spécifique, et la remet dans "Core".
- Cette "danse" autour du bon endroit prend beaucoup de temps.
4. Le temps, c'est long
C'est le point le plus surprenant : ce n'est pas rapide.
- Quand un développeur se rend compte qu'une épice est mal placée, il ne la déplace pas immédiatement.
- En moyenne, il faut plus d'un an (408 jours) entre le moment où l'épice est mise au mauvais endroit et le moment où le chef décide enfin de la déplacer correctement.
- C'est comme si vous utilisiez un couteau de cuisine pour couper du pain pendant un an, avant de réaliser qu'il faut utiliser un couteau à pain, et de faire le changement.
Pourquoi est-ce important ?
Aujourd'hui, les outils informatiques (comme npm) sont un peu comme des sommeliers passifs. Ils disent : "Vous avez mis cette épice dans le placard principal, d'accord, je la mets dans l'assiette." Mais ils ne vérifient pas si c'est logique.
Si vous mettez un outil de test (Dev) dans le placard principal (Core), cela alourdit le plat final et rend le restaurant plus vulnérable aux voleurs (sécurité).
Les leçons pour l'avenir :
- Pour les outils : Il faudrait des outils qui disent : "Hé, tu as mis cette épice dans le placard principal, mais dans 100 autres restaurants, on l'utilise seulement pour la préparation. Tu es sûr ?"
- Pour les développeurs : Il faut accepter que la gestion des dépendances n'est pas un "réglage unique". C'est un processus continu, comme faire le ménage dans son garage : on range, on se trompe, on déplace, et on recommence.
En résumé :
Gérer les dépendances, ce n'est pas juste une liste statique. C'est une histoire vivante où les ingrédients voyagent, sont jetés, réintégrés et déplacés pendant des années. Les développeurs passent beaucoup de temps à essayer de trouver la "bonne place" pour chaque outil, et ce processus est beaucoup plus long et complexe qu'on ne le pensait.
Noyé(e) sous les articles dans votre domaine ?
Recevez des digests quotidiens des articles les plus récents correspondant à vos mots-clés de recherche — avec des résumés techniques, dans votre langue.