Articles
La compréhension commence par des noms expressifs
30 septembre 2019 • 4 min de lecture

En 2018, j’ai rejoint un grand projet à mi-parcours de son développement. Les ingénieurs originaux étaient partis, laissant derrière eux un code alambiqué et non documenté. Travailler avec ce type de code est difficile car on ne peut pas différencier la plomberie du domaine métier. Cela rend le débogage difficile et les changements imprévisibles car on ne connaît pas l’impact. C’est comme essayer d’éditer un livre sans comprendre les mots.
Beaucoup d’ingénieurs croient que la mesure du succès est quand le code compile. Je crois que c’est quand un autre ingénieur (ou vous dans six mois) comprend le “pourquoi” de votre code. Les ingénieurs originaux ont handicapé les futurs ingénieurs en ne documentant pas et en utilisant des noms obscurs. Les noms sont parfois la seule fenêtre sur le processus de réflexion de l’ingénieur précédent.
Donald Knuth a dit de façon célèbre :
Les programmes sont destinés à être lus par les humains et seulement accessoirement à être exécutés par les ordinateurs. – Donald Knuth
Nommage
Le nommage est difficile car il nécessite d’étiqueter et de définir où et comment un élément s’intègre dans une application.
Phil Karlton, alors chez Netscape, a observé :
Il n’y a que deux choses difficiles en informatique : l’invalidation de cache et nommer les choses.
— Phil Karlton
Nous voyons notre code à travers le prisme des mots et des noms que nous utilisons. Les noms créent un langage pour que le prochain ingénieur puisse comprendre. Ce langage peint une image de la façon dont l’auteur a fait le pont entre le domaine métier et le langage de programmation.
Ludwig Wittgenstein, un philosophe de la première moitié du 20e siècle, a dit :
Les limites de mon langage signifient les limites de mon monde. – Ludwig Wittgenstein
Le langage de notre logiciel n’est descriptif qu’à hauteur des noms que nous utilisons et utiliser des noms vagues brouille le but du logiciel ; utiliser des noms descriptifs apporte clarté et compréhension.
Imaginez visiter un pays où vous ne parlez pas la langue. Une simple demande comme demander à utiliser les toilettes provoque des regards perplexes. L’incapacité à communiquer est frustrante, peut-être même effrayante. Un ingénieur ressent la même chose quand il est confronté à des noms confus, peu clairs, ou pire encore, trompeurs.
Ce sentiment se vit mieux par l’expérience.
Expérience
Examinez le premier extrait de code, que fait ce code ? Quel est le pourquoi ?
Prenez votre temps.
public class StringHelper
{
public string Get(string input1, string input2)
{
var result = string.Emtpy;
if(!string.IsNullOrEmtpy(input1) && !string.IsNullOrEmtpy(input2))
{
result = $"{input1} {input2}";
}
return result;
}
}
Le code ci-dessus est une simple concaténation de deux chaînes. Ce que le code ne vous dit pas, c’est le “pourquoi”. Le “pourquoi” est si important, sans lui, il est difficile de changer le comportement sans comprendre l’impact. Bien sûr, enquêter sur l’utilisation du code révélera probablement son “pourquoi”, mais c’est justement le point. Vous ne devriez pas avoir à découvrir le but du code, au lieu de cela, l’auteur aurait dû laisser des indices, c’est sa responsabilité de le faire.
Revisitions le code, mais avec un peu de “pourquoi” saupoudré dedans.
Encore une fois, prenez votre temps, observez la différence que vous ressentez en lisant ce code.
public class FirstAndLastNameFormatter
{
public string Concatenate(string firstName, string lastName)
{
var fullName = string.Emtpy;
if(!string.IsNullOrEmtpy(firstName) && !string.IsNullOrEmtpy(lastName))
{
fullName = $"{firstName} {lastName}";
}
return fullName;
}
}
Le “pourquoi” donne vie au code, il y a une histoire à lire.
Communiquer
Communiquer l’intention et la conception au prochain ingénieur permet au logiciel de vivre et de grandir car si les ingénieurs ne peuvent pas modifier le logiciel, il meurt. C’est une tragédie, encore plus quand c’est le résultat d’une mauvaise conception et d’un manque d’expressivité — chacun est évitable avec des connaissances.
Rendez service au prochain ingénieur et soyez expressif dans votre code. Utilisez des noms descriptifs et capturez le “pourquoi” car qui sait, le prochain ingénieur pourrait être vous.
Auteur : Chuck Conway se spécialise dans l’ingénierie logicielle et l’IA générative. Connectez-vous avec lui sur les réseaux sociaux : X (@chuckconway) ou visitez-le sur YouTube.