- Dans la culture moderne du développement logiciel, les noms de projets et de bibliothèques sont de plus en plus remplis de mots arbitraires sans rapport avec leur fonction
- Autrefois, des noms comme grep, awk, sed, FORTRAN, COBOL décrivaient directement une fonction ou un objectif, mais aujourd’hui les appellations dénuées de sens prolifèrent
- Cette tendance s’est accélérée avec l’essor de GitHub et de la culture startup, jusqu’à rompre complètement le lien entre le nom et la fonction
- Le coût de compréhension et la charge cognitive augmentent, obligeant les développeurs à multiplier les recherches inutiles pour comprendre le rôle de chaque outil
- L’article appelle à rétablir des conventions de nommage claires et centrées sur la fonction, et souligne que pour les outils techniques, la clarté et le professionnalisme doivent primer sur la marque
L’évolution des pratiques de nommage dans le logiciel
- Lors d’une conférence EmacsConf en 2022, Richard Stallman a souligné l’importance des « noms faciles à mémoriser » et insisté sur le fait qu’un nom de package devrait révéler ce qu’il fait
- L’écosystème Emacs a traditionnellement conservé des conventions de nommage basées sur la fonction, comme dired (éditeur de répertoires) ou eshell (shell Emacs)
- Pourtant, les développeurs modernes ont tendance à donner à leurs outils des noms tirés de noms communs aléatoires, créatures mythologiques ou personnages fictifs
- Dans d’autres domaines techniques, ce comportement serait considéré comme un manque de professionnalisme
Le problème des noms sans signification
- Par exemple, des noms d’outils comme Viper, Cobra, Melody, Casbin ou Asynq ne permettent absolument pas de deviner leur fonction
- L’auteur évoque même une expérience où il a dû faire une recherche pour comprendre l’explication d’infrastructure donnée par un ami
- Dans d’autres branches de l’ingénierie, les noms décrivent la structure ou la fonction
- Ex. : Golden Gate Bridge, Hoover Dam, I-beam, butterfly valve rendent clairement visible leur forme ou leur rôle
- En chimie, des systèmes comme la nomenclature IUPAC imposent qu’un nom désigne précisément un seul objet
- Ex. : 2,2,4-trimethylpentane désigne une seule molécule ; on ne l’appelle pas arbitrairement « Steve »
Les règles d’hier et la rupture actuelle
- Dans les années 1980, des abréviations fonctionnelles comme grep, awk, sed, cat, diff dominaient
- Les noms de langages comme FORTRAN, COBOL, BASIC, SQL, Lisp reflétaient eux aussi leur objectif
- Depuis les années 2010, la diffusion des noms dépourvus de sens s’est accélérée
- Certains, comme MongoDB, conservaient encore un lien fonctionnel ou étymologique, mais avec GitHub et la culture startup, les noms arbitraires se sont multipliés
- L’article y voit notamment une imitation de réussites orientées marque, comme Google
Coût cognitif et baisse d’efficacité
- Un nom comme libsodium rend difficile l’inférence de sa fonction et pousse le développeur à multiplier les changements de contexte
- Du temps est inutilement perdu à se demander : « pourquoi sodium ? »
- Plus un projet a de dépendances, plus cette taxe cognitive (cognitive tax) s’accumule
- Cela finit par réduire la productivité des développeurs
- L’auteur souligne qu’en traitant une phrase comme « Viper, Cobra, Melody… », des ressources mentales sont gaspillées à interpréter des jetons sans signification
Réponses aux objections courantes
- « Un nom facile à retenir aide le marketing » → les outils pour développeurs ne sont pas des produits grand public, et la clarté fonctionnelle est plus importante
- « Les noms descriptifs sont ennuyeux » → cet ennui est un prix acceptable pour la clarté ; les instruments chirurgicaux sont ennuyeux aussi, mais précis
- « C’est juste pour s’amuser » → tous les utilisateurs paient le prix de cet “amusement”, ce qui se traduit par une perte de temps à l’échelle du secteur
- « Tous les bons noms sont déjà pris » → les espaces de noms, préfixes et mots composés permettent de contourner le problème ; au minimum, il faut choisir un nom lié à la fonction
Quelle direction pour la suite ?
- Le problème est présenté non comme une intention malveillante, mais comme le résultat d’une évolution culturelle
- À mesure que la programmation est passée d’un univers centré sur l’entreprise à un univers plus communautaire, les normes sociales se sont affaiblies
- La solution serait une restauration culturelle des conventions de nommage
- Plutôt qu’une régulation, l’amélioration devrait passer par le retour du professionnalisme, la formation et la pression sociale
- Le nom des bibliothèques devrait refléter leur fonction, quitte à accepter des mots composés et des formulations longues
- Par exemple, http-request-validator est bien plus clair que zephyr
- Il faut séparer la mascotte du nom
- Par exemple, PostgreSQL utilise Slonik comme mascotte en forme d’éléphant, mais son nom lui-même conserve une signification fonctionnelle
- S’il ne s’agit pas d’un produit grand public où le branding est crucial, il faut faire passer la clarté et le professionnalisme avant tout
- Avant de choisir « le nom de son personnage d’anime préféré », il faudrait se demander : « un ingénieur civil donnerait-il ce genre de nom à un système de pont ? »
- En conclusion, il faut mettre fin à la prolifération des noms dépourvus de sens et revenir à un langage professionnel clair
- La clarté n’est pas de l’ennui, c’est une marque de respect pour le temps et les ressources cognitives des utilisateurs
Aucun commentaire pour le moment.