Pourquoi notre propre code nous est-t-il incompréhensible ?
Pourquoi notre propre code nous est-il incompréhensible ?
Un développeur se penche sur la question et identifie six problèmes
Tous les développeurs se sont posé un jour cette question : « pourquoi je n’arrive pas à comprendre ce bout de code ? Pourtant, c’est moi qui l’avais écrit quelques mois auparavant ! ». Le pire, c’est que parfois même en lisant les commentaires on ne comprend pas, et ça arrive si souvent qu’on se demanderait dans ces cas-là si notre intelligence s’est dégradée ou si au moment d’écrire ce code nous étions possédés par une entité intellectuelle supérieure.
Stephen Young, un développeur, designer et blogueur, a écrit récemment sur ce sujet qu’on devrait apprendre à éparpiller les miettes de pain derrière nous lorsqu’on écrit un code source pour pouvoir retrouver notre chemin lorsqu’on y revient. Oui, mais comment ?
Selon lui, il existerait 6 problèmes qui font que notre programme -si clair et élégant- ressemblera à du charabia lorsqu’on le relira quelques mois plus tard :
- Les modèles mentaux trop complexes : un programme est une solution à un problème du monde réel, lorsqu’on veut trouver cette solution on doit d’abord former un modèle du problème, puis un modèle de la solution (que Stephen Young appelle modèle sémantique) avant de passer au code. Il faudra donc veiller à ne pas sauter directement du problème à la solution sans former de modèles. Aussi, il faudra veiller à simplifier ces modèles autant que possible, car « les problèmes que nous tentons de résoudre sont suffisamment complexes. On ne doit pas ajouter à cela plus de complexité ».
- La mauvaise traduction du modèle mental : cette traduction « syntaxique » vise à transformer le modèle sémantique en code source. Le problème est qu’il est facile de traduire ce code lorsque le modèle sémantique est fraîchement cartographié dans notre tête, mais lorsqu’on y revient plus tard, ceci n’est pas aussi évident.
Pour éviter les problèmes syntaxiques, il faudra veiller à bien choisir les noms des variables, fonctions et arguments pour qu’on puisse facilement comprendre leurs rôles. Aussi il faudra veiller que les noms des modules et classes soient autant que possible proches du modèle sémantique. De plus, il faudra que chaque classe ait un seul but : « je finis souvent par réécrire une classe parce que j’ai du mal à lui donner un nom assez court qui décrit tout ce qu'elle fait », assure Young.
Quant aux commentaires, ils sont utiles si on n’en abuse pas, ils doivent décrire pourquoi vous avez eu à faire quelque chose et non pas comment vous l’avez fait.- Pas assez de regroupement : lorsqu’on programme, on remarque qu’on a souvent besoin de répéter un nombre de choses plusieurs fois, c’est pour ça qu’il existe maintenant plusieurs Design Pattern, des fonctions standard et des bibliothèques qui sont très utiles dans le sens où « on n’a plus besoin de penser à la façon dont le code fait quelque chose, mais plutôt se concentrer sur ce qu'il fait ».
- Utilisation obscure de vos bouts de code : « lorsque vous revenez plus tard à votre code source, il est souvent très difficile de reconstituer toutes les utilisations prévues de vos classes et méthodes. Généralement, ceci est dû aux différents usages qui sont dispersés dans tout le reste de votre programme », écrit Young. Une des solutions à ce problème, selon lui, est de disposer d’un ensemble complet de cas de tests qui permettent d’avoir une image complète du code et de comment l’utiliser.
- Pas de chemin clair entre les différents modèles : ce chemin qui relie l’objectif de votre programme, au modèle sémantique puis au modèle syntaxique (code) doit être aussi simple que possible. « Parfois, il est préférable de choisir une structure de classe particulière ou un algorithme non pas pour son élégance, mais pour sa capacité à relier les différents modèles d’une façon claire et naturelle ».
- Inventer des algorithmes : « dans presque tous les cas, il existe des algorithmes qui peuvent être mis ensemble pour résoudre votre problème ». Programmer consiste donc à choisir des algorithmes existants dans la bonne combinaison pour résoudre un problème. Selon lui, « si vous inventez de nouveaux algorithmes, c’est soit que vous ne connaissez pas le bon algorithme à employer, soit vous travaillez sur une thèse de doctorat ».
Pour conclure, Young conseille de fournir autant d'indices que possible afin de permettre à quiconque regardant votre code de recréer le même modèle sémantique que vous aviez à l'origine dans l'esprit. « Cela paraît simple, mais en réalité c’est très difficile de faire bien ».
Source : Medium
Et vous ?
Êtes-vous d’accord avec Stephen Young sur ces six points ?
Répondre avec citation
. Ecrire un algorithme pour encoder un truc, sérialiser, interpréter, ok. Mais c'est pas de la programmation objet, c'est du modulaire.
Envoyé par Washmid
)...
Mais pas sous ses termes, que je trouve bien choisi !
Partager