La barrière de la langue plombe vos projets IT
C'est incroyable le nombre de pièges dans le domaine du développement logiciel.
En particulier, il y en a un dans lequel je tombe encore : la barrière de la langue.
Non, je ne parle pas de la maîtrise de l'Anglais ou du Vietnamien. Je parle du langage de ceux qui vont utiliser le truc qu'on code.
Car chaque métier dispose de son vocabulaire spécifique.
Un “dossier” ne signifie pas la même chose pour un plasturgiste ou une avocate. Une “activité” ne correspond pas à la même chose pour un technicien de maintenance et une maîtresse d'école.
Et même au sein d'une entreprise, le même mot peut révéler des chose différentes.
Par exemple un “client” est en fait :
- un compte pour le service comptable, qui a aussi besoin d'une adresse de facturation,
- un destinataire pour le service logistique, qui a besoin d'une adresse d'expédition,
- un client pour le service commercial, qui a lui aussi besoin d'une adresse à laquelle envoyer les offres promotionnelles.
Lorsqu'on construit un logiciel, il y a donc une phase d'appropriation de ce langagespécifique. C’est nécessaire pour bien comprendre le métier avant de pouvoir le coder.
Sauf que :
- on ne passe pas assez de temps à se mettre d'accord sur la signification des termes employés dans nos discussions,
- on les oublie lorsqu'on code.
Le poids des mots, le choc des bugs
Les erreurs de conception naissent de la mauvaise compréhension du besoin. Et cette incompréhension prend naissance dans le flottement du vocabulaire. On croit parler de la même chose, mais pas du tout.
Voila mon mantra désormais :
TOUT PROJET TECH COMMENCE PAR UN THESAURUS.
Non, un thésaurus n'est pas un animal préhistorique cousin du diplodocus.
Reprenons la définition donnée par Wikipédia :
Un thésaurus ou dictionnaire analogique est un ouvrage de référence dans lequel les mots sont organisés par champ lexical, où l’on peut trouver des synonymes et antonymes de mots. Il est destiné aux personnes qui écrivent, pour aider à trouver le meilleur mot pour exprimer une idée.
Ce thésaurus devrait être le premier livrable du projet. Il oblige à se mettre d'accord sur les termes et leurs significations pour le métier qui utilisera le logiciel.
Une fois que l'on s'est accordé sur ce vocabulaire, on peut alors discuter des fonctionnalités attendues.
Mais s'ouvre alors le second piège : la traduction dans le code.
Do you speak Javascript ?
L'un des problèmes les plus compliqués dans le développement logiciel est de nommer les choses. En effet, quand on code, on doit tout le temps attribuer des noms à des variables, des fonctions ou des modules.
Et là, c'est la fête.
L'imagination débordante des développeurs peut enfin se débrider. Ca fuzze de noms exotiques, en anglais, en français, dans un mélange des deux parfois.
A la fin, ça donne ça :
Pouvez-vous deviner à quoi sert ce bout de code ?
Non ?
Moi non plus !
A sa lecture, on ne comprend absolument pas l'intention du développeur.
Mais est-ce important de le savoir ? Car après tout, il y aura des tests. Le principal est que ça fonctionne sans bug.
Et bien c'est pourtant à ce moment précis que l'on torpille le projet. Au fur et à mesure, on construit une machine infernale qui sera impénétrable pour tout nouvel arrivant dans le projet.
Même celui qui est à l'origine du code aura le plus grand mal à y revenir quelques mois plus tard.
Ah si seulement on avait eu un thésaurus pour nous guider dans le choix des noms ! On aurait pu écrire le même code, comme ça par exemple :
Et là, vous deviner ce que fait le code ?
Bien sûr.
En utilisant les termes du thésaurus, on peut exprimer dans le code l'intention du métier. Sans ajouter d'étape nuisible de traduction.
Les bénéfices sont perceptibles :
- le développeur comprend le sens de ce qu'il code, réduisant ainsi le risque d'une fonctionnalité à coté de la plaque,
- le code est plus facile à faire évoluer, y compris par un autre développeur,
- inutile de commenter le code : il parle de lui même.
Pour y parvenir, ça demande de décloisonner les codeurs et de les mettre en contact avec le métier pour s'accorder sur un langage commun et non ambigu. Ca demande un peu d'énergie, pour que chacun contribue à la construction du thésaurus et à sa mise à jour lorsque de nouvelles fonctionnalités doivent être ajoutées.
Mais sur le long terme, ce vocabulaire commun utilisé partout (y compris dans le code) offre un moyen efficace de conserver la maîtrise de son projet.