NCraft 17 : le syndrome du Babel informatique

Comme tous les ans vers la fin du mois de mai s’est tenue la conférence NCraft à Paris. Vous ne connaissez pas ? Dommage. Il s’agit d’un rassemblement de passionnés du développement applicatif qui viennent partager et échanger sur les nouvelles pratiques. Un événement qui s’inscrit dans la tendance du “software craftmanship”, cette fameuse méthode qui met en avant le savoir-faire des développeurs et la bonne conception des logiciels. Dans ces rassemblements, l’important n’est pas tant les technologies évoquées que les pratiques des uns et des autres et le partage des expériences. Et le moins que l’on puisse dire c’est que cette année encore les conférences de NCraft 2017 ont été riches d’enseignements.

Personnellement, c’est le “key point” Laura Savino qui m’a le plus interpellé. Vous trouverez le préambule de son intervention ici et la vidéo ici. Développeuse iOS à Seattle, elle a partagé avec nous son point de vue sur l’écriture du code. Son opinion a certainement été influencée par son parcours puisqu’elle parle plusieurs langues. Or il y a des similitudes évidentes entre l’apprentissage d’un nouveau langage et celui d’une nouvelle langue. Comme cette erreur que l’on commet (presque tous) en apprenant une langue et qui se vérifie quand on apprivoise un nouveau langage : la translation de schéma. J’entends par là reproduire les schémas que l’on connaît déjà et qui semblent acceptables. Par exemple si l’on “prend une décision” en français, on est tenté dire “take a decision”? Or on dira plutôt “make a decision”. C’est un peu la même chose dans la pratique du développement. Si je puise dans mon expérience personnelle, lorsque j’ai voulu apprendre le F#, j’ai souvent utilisé le formalisme du C# (et des langages impératifs en général) en choisissant d’utiliser une boucle for plutôt que la fonction map pour parcourir une structure de données.

let narr = Array.zeroCreate arr.Length
for j in 0 .. arr.Length-1 do
    narr.[j]  f

Array.map f arr

L’exemple que je vous propose est une transposition sur ma propre expérience de celui développé par Laura Savino qui utilisait le langage swift. Mais la conclusion reste la même. Et les conséquences de cette démarche également.

Si tous les éléments d’un groupe pratiquent un même langage ou une même langue, c’est avant tout pour partager des idées de façon claire. Le langage (ou une langue) charrie en lui même un formalisme qu’il faut savoir respecter si l’on veut pouvoir se faire comprendre des autres et ne pas les déstabiliser.

Parler la même langue, c’est plus simple

C’est encore plus vrai dans la pratique du développement, car chaque morceau du code fait partie d’un tout plus grand qui ne peut fonctionner et être maintenu seulement si chacun est en mesure d’en assimiler les subtilités. Je ne suis pas certain que la “compréhensibilité” soit la caractéristique unique d’un “bon code”. Mais ce qui est certain, c’est qu’un code qui n’est pas compréhensible ne peut pas être bon.

On dispose cependant d’un outil lorsque l’on écrit du code qui peut aider à la compréhension. En effet, un code en soi peut parfois être difficile d’accès, lorsque l’on fait des optimisations de performance, par exemple. Dans ce cas, nous pouvons toujours laisser un commentaire afin d’aiguiller les développeurs qui vont passer derrière nous. C’est plutôt une bonne pratique à mon sens, et je suis surpris de voir autant de personnes opposées aux commentaires dans le code. Pourquoi ? Parce qu’en général, les personnes qui passent pour faire évoluer ou pour refactorer un code, et en particulier les parties commentées, ne touchent pas aux commentaires en eux même. Cela aboutit à des situations assez cocasses où le commentaire est complètement déconnecté du code qu’il renseigne !!!

// do not change the way we use the default value named def
let computeValue x y = x+y |> Math.abs

De l’art d’écrire un bon commentaire dans un code

Bien évidement, il faut faire évoluer les commentaires en même temps que le code pour éviter ce genre de situation. Une autre raison souvent entendue pour dénigrer le rôle des commentaires est qu’ils ne seraient finalement compréhensibles que de la personne qui les écrit. Reconnaissons que c’est souvent vrai. Pour une raison simple : la personne qui les a écrits agit dans un contexte dont elle est parfaitement imprégnée. Si bien que selon elle, certains points apparaissent parfaitement triviaux alors qu’ils ne le sont pas du tout. Là encore, une règle simple permet de corriger le tir : se remettre en question avant tout. En d’autres termes, si on vous fait remarquer que quelque chose n’est pas clair dans votre code, c’est qu’il ne l’est pas. Il y a d’ailleurs fort à parier que si vous deviez relire votre commentaire plusieurs mois après l’avoir rédigé, vous éprouveriez des difficultés à comprendre à la fois votre code et votre commentaire. C’est du vécu. Et j’imagine que je ne suis pas le seul dans cette situation.

En synthétisant tous ces points soulevés lors de la présentation de Laura Savino, on arrive finalement à une sorte de maxime : un code clair est un code qui évite d’avoir à décrypter les éléments de langage et de style pour pouvoir se concentrer sur l’essentiel. Ne serait-ce que parce qu’il est déjà assez complexe de comprendre l’ensemble des idées présentes dans le code d’une application. Et puis disposer d’un code clair et de commentaires qui le sont tout autant permet de :

• diminuer le coût de la maintenance,
• faciliter les évolutions,
• faciliter la communication entre les développeurs,
• faciliter l’intégration des nouveaux arrivants.

Penser aux codes review

Bien entendu il s’agit d’un résultat idéal. L’atteindre peut paraître très difficile. Cependant il existe des pratiques simples qui permettent de tendre vers ce résultat. Les codes review ou le “mob programming” me paraissent parfaitement appropriés pour cet exercice. Ils permettent l’apport d’un regard extérieur et ils poussent à la discussion. Cela nécessite également une attitude positive face à la critique qui ne doit pas être prise ni faite comme une mise en accusation. Au contraire, cela doit être un moyen de faire avancer les choses.