Brève histoire de la modularité
Josh Emerson
21 novembre 2016
0 minutes de lectureIl y a un peu plus d’une semaine, nous étions sponsors de la conférence ffconf, à Brighton. Une journée riche en conférences brillantes, à la fois stimulantes et utiles. Ashley Williams, de npm, y a présenté une conférence intitulée « Brève histoire de la modularité », qui nous a semblé particulièrement pertinente pour Snyk. Nous avons donc pensé en partager ici un résumé.
En plus de lire notre compte rendu, vous pouvez télécharger les diapositives via npm en exécutant npm install a-brief-history (nous adorons le fait que la conférence d’Ashley soit elle-même un module npm !). La vidéo sera bientôt disponible ; nous ajouterons un lien dès qu’elle le sera.
Pourquoi modulariser ?
npm est le plus grand dépôt de modules au monde. Il compte désormais plus de modules que Bower (JS), nuget (.NET), Packagist (PHP), PyPI et Rubygems.org réunis. Alors, pourquoi npm compte-t-il autant de modules ?
Les réponses au tweet d’Ashley ont été très variées, mais la plupart des personnes ont avancé des raisons similaires pour modulariser le code :
Cela permet de réutiliser du code courant
Cela impose une séparation des responsabilités
Cela facilite la documentation et les tests du code
Pourquoi ne pas modulariser ?
La modularisation a un véritable coût en complexité. Comme l’explique Guy Podjarny dans Les 5 dimensions d’une dépendance npm, vous pouvez avoir bien plus de dépendances que vous ne le pensez au premier abord. Pour chacune d’elles, vous devez vous poser de nombreuses questions.
Vous finissez par trouver un package qui semble plus ou moins répondre à vos besoins. Mais vos problèmes ne font que commencer. À vous d’évaluer la bibliothèque : dispose-t-elle de tests ? Pouvez-vous comprendre son code source ? Est-elle activement maintenue ? Sa documentation est-elle facile à trouver et à consulter ?
Rich Harris – Les petits modules, ce n’est pas si simple
À ces questions, vous devriez aussi ajouter celles de la sécurité. Les responsables du package corrigent-ils les vulnérabilités de leur code ? Des vulnérabilités sont-elles connues dans cette dépendance ou dans ses propres dépendances ?
Le développement logiciel, c’est gérer le changement
Après avoir examiné les avantages et les coûts de la modularisation, Ashley s’intéresse surtout à l’écart entre la perception et la réalité de cette approche.
Quand nous pensons au développement logiciel, nous songeons sans doute à la résolution de problèmes et à la création de systèmes qui exécutent des tâches. Mais nous oublions souvent que les logiciels évoluent en permanence, et pas toujours dans la même direction.
En 1972, David Parnas a écrit un ouvrage intitulé « Critères de décomposition des systèmes en modules », dans lequel il aborde la modularisation sous l’angle de la gestion du changement.
[Commencez] par dresser la liste des décisions de conception difficiles ou susceptibles d’évoluer. Concevez ensuite chaque module de façon à isoler ces décisions des autres.
En abordant la modularisation sous cet angle, vous cherchez à isoler la complexité au sein des modules, afin que le reste du système n’ait pas à se préoccuper de leur implémentation.
Sur son blog, programming is terrible, Tef nous propose une méthode pour y parvenir.
Écrivez du code facile à supprimer, pas à faire évoluer. Au lieu de créer des logiciels réutilisables, cherchons à créer des logiciels jetables. Inutile de vous dire qu’il est plus amusant de supprimer du code que d’en écrire.
En conclusion
Ashley conclut sa conférence en rappelant que modulariser le code est difficile, car il y a beaucoup plus de choses à comprendre avant de pouvoir déterminer comment et quand le découper. L’un des principaux défis consiste à choisir le bon moment et la bonne manière de modulariser le code : le facteur temps est essentiel. Ce n’est qu’avec le temps que nous pouvons observer si une stratégie joue en notre faveur ou contre nous.
