Personnellement, si je comprends l'assertion "le développeur doit savoir ce qu'il a écrit", en pratique il est facile de voir que ce n'est pas toujours le cas : chacun évolue, et relire un code après plusieurs années peut amener à ne plus se comprendre. Et même sans aller aussi loin, un programme fait à la va vite pour répondre à une urgence, une fois qu'on s'y penche quelques jours après pour mieux concevoir la chose, peut être plus difficile à revoir que de refaire un code depuis zéro. On peut discuter le fait que l'Homme soit une machine ou non, mais je pense qu'on peut s'entendre sur le fait qu'il n'est pas une machine à programmer. Et pour palier à ses oublis et autre "défauts" (qui pris sous une autre perspective en font des qualités), les tests unitaires sont un outil utile. D'autant plus quand on généralise à une équipe, de surcroit qui évolue aussi avec des membres qui s'en vont et d'autres qui y entrent : on ne peut tout simplement pas partir du principe que la personne sait ce qui est codé. En revanche, on peut organiser le code pour que celui-ci soit facile à lire et à conceptualiser :Envoyé par autran
- utiliser des classes qui trouvent leurs analogies dans la pratique de tous les jours (et en donner des exemples dans la documentation),
- minimiser les dépendances avec d'autres classes pour ne pas avoir besoin de comprendre beaucoup de choses avant de comprendre celle qui nous intéresse,
- etc.
On peut naturellement s'inspirer de bonnes pratiques en rédaction :
- faire des phrases courtes = écrire des instructions courtes
- utiliser un vocabulaire adapté au contexte = utiliser un nommage adapté au contexte
- structurer le document en titre, sections, sous-sections, etc. avec des noms explicites = structurer le code en classe, fonctions, appelant d'autres fonctions, etc. avec des noms explicites
- mettre des illustrations = faire des analogies dans la documentation
Et je pense personellement que bien écrire un code est de la même essence que bien écrire un rapport de stage, un rapport technique, un roman, etc. Il faut que le code soit organisé pour qu'un nouveau lecteur puisse :
- démarrer à un point de départ connu (e.g. fonction main()),
- facilement voyager dans le code (i.e. fonctions courtes dans lesquelles chaque ligne est explicite, pas seulement le nom de la fonction et des variables mais aussi l'organisation des arguments de fonctions -de façon à lire l'appel comme une phrase naturelle- et la suite d'instructions),
- lire les détails une fois qu'on a trouvé ce qui nous intéresse (i.e. code pour comprendre le comment, documentation pour comprendre le reste : quoi, pourquoi, etc.)
Répondre avec citation
.
.
Partager