Un code de qualité

Au risque d’être un peu polémique, je vais essayer de définir ce qu’est, de mon point de vue, un code de qualité. Je tenterai ensuite d’expliquer quels sont pour moi les moyens qui permettent d’écrire du bon code.

Pour ceux qui ne sont pas d’accord avec moi, les commentaires sont ouverts pour en débattre ! Je précise simplement que je me place dans le contexte d’un code qui va vivre et être exploité en production, et pas un code de POC  destiné à être jeté.

Qu’est-ce qu’un bon code ?

Si on se place du côté de l’utilisateur du produit (après tout c’est pour lui qu’on travaille),  un bon code, c’est d’abord un code qui est fiable, qui fonctionne correctement et ne se contente pas de tomber en marche (j’aime bien cette expression) sur la machine du développeur (le fameux ça marche chez moi). Cela paraît évident, mais en réalité ce n’est pas toujours facile et ce n’est pas forcément ce vers quoi le développeur tend spontanément.

Mais un bon code, c’est aussi un code lisible. Et pas seulement par une machine ! Les machines sont capables de gérer une grande complexité, mais ce n’est pas le cas des humains, et de moi en particulier. Quand nous écrivons du code, c’est à destination des développeurs, et tout code doit pouvoir être compris par un développeur lambda sans avoir à se lancer dans une aventure vers l’inconnu tel que l’ont fait les grands explorateurs de ce monde lorsqu’ils se lançaient à la découverte de zones inconnues de notre planète afin de les cartographier. Je suis sûr que si vous êtes développeur, vous voyez très bien ce que je veux dire parce que ça a bien dû vous arriver au moins une fois. D’ailleurs, écrire du code lisible, ce n’est pas seulement penser aux autres, c’est aussi se rendre service à soi-même. Qui ne s’est jamais posé la question suivante : quel est le con qui a écrit ce code ? Et quelques minutes plus tard : mince, en fait le con c’est moi !

Un bon code, c’est également un code évolutif qui est donc capable de suivre et de s’adapter à  l’évolution du produit plutôt que de la subir tant bien que mal jusqu’au point de rupture qui sera nécessairement douloureux : ah ben là nous devons réécrire l’ensemble de ce module et il nous faut trois mois. Aïe aïe aïe…

Comment fait-on du code propre ?

Je ne vais pas détailler l’ensemble des bonnes pratiques qui permettent d’écrire du code propre, l’oncle Bob l’a déjà fait et il l’a très bien fait dans son fameux livre Clean Code. Cet ouvrage est à mon sens incontournable pour un développeur. Et en plus, les bonnes pratiques abordées dans ce livre sont applicables dans plus ou moins tous les langages.

Je vais me contenter de citer très brièvement quelques bonnes pratiques qui permettent de faire du code propre :

• La longueur d’un fichier ne doit pas excéder 200 ou 300 lignes, une fonction pas plus de 10 lignes
• Les éléments du code (fichiers, variables, fonctions, classes…) doivent avoir des noms qui ont du sens
• Lorsqu’on ressent le besoin de commenter son code, c’est qu’on a quelque chose à se reprocher. Plutôt que de passer du temps à expliquer ce qu’il fait, il est préférable de le modifier de sorte à le rendre compréhensible. Et oui c’est quasiment systématiquement possible !
• En orienté objet, respecter les principes SOLID et particulièrement Single Responsibility Principle, et pour cela s’appuyer sur les design patterns

Quel est le rapport entre code propre et bon code ?

Il se trouve que faire du code propre c’est un moyen très efficace pour écrire du bon code. Bien que ce ne soit pas suffisant, j’aurais tendance à dire que c’est bel et bien nécessaire.

Un code propre c’est avant tout un code lisible. En effet, utiliser des noms qui ont du sens et faire des petits fichiers et des petites fonctions par exemple est un moyen redoutablement efficace d’augmenter la lisibilité du code.

Un code propre c’est aussi un code évolutif. En effet, le découpage en petits fichiers et petites fonctions permet de travailler à une granularité plus fine. En plus de favoriser la réutilisation et le partage de code, cela permet d’éviter la fameuse métaphore du plat de spaghettis dans lequel tout dépend de tout le monde, et lorsqu’un élément change, tout le monde est impacté.

Enfin, j’avais également précisé qu’un bon code c’est avant tout un code qui fonctionne. Déjà un code propre, c’est un code clair, dans lequel les bugs se voient plus facilement à l’œil, juste en écrivant le code. Comme c’est un code évolutif, les bugs se corrigent plus facilement. Mais tout cela ne suffit pas pour faire un code fiable. Pour s’assurer qu’un code fonctionne correctement, il faut le tester, il n’existe pas vraiment d’autre moyen. Seulement, pour qu’un code soit testé, il faut qu’il soit testable, et écrire du code testable n’est pas forcément trivial. Il se trouve qu’un code propre c’est également un code testable, principalement parce que la granularité des composants est fine, et que toute classe ne dépend pas de l’univers entier. On peut donc tester unitairement chaque brique du puzzle, et ça augmente grandement la fiabilité de l’ensemble.

Et c’est compliqué d’écrire du code propre ?

Écrire du code propre, c’est à la portée de tout le monde. Il suffit d’avoir un peu de volonté pour se discipliner. Comme pour tout, c’est surtout le début qui est difficile, assez rapidement on en prend l’habitude et ça devient naturel.

Il existe des outils d’analyse statique de code qui sont très efficaces pour apprendre à écrire du bon code, car ils mettent en évidence les zones où le code n’est pas propre en expliquant pourquoi. L’outil le plus connu est SonarQube et je le recommande vivement.

Alors plus d’excuse, soyons professionnels et arrêtons d’aggraver de jour en jour notre dette technique : écrivons tous du bon code !

L’image d’en-tête provient de Flickr.