Comment mesurer la qualité du code ?

Bonne question, Watson !

Durant des meetups, des formations, des discussions autour d’un verre … ou deux (ce sont les plus studieuses à ce qui paraît… ! ), etc… J’entends beaucoup de choses sur la qualité du code.

Quelques exemples parmi tant d’autres :

• Il faut suivre les standards du langage !
• Il est impératif d’écrire le minimum de lignes
• Un projet avec 10 000 fichiers, c’est n’importe quoi, il ne peut pas être bien codé.

Vous voyez le délire ? On peut partir très loin comme ça et c’est un sujet tendu car à ces 3 affirmations il est possible de répondre : Non, non et … non ! Mais aussi : Oui, oui et… oui ? En tant que développeur, je vous répondrais donc avec le fameux “Ça dépend“.

Quand mesure t’on la qualité d’un code ?

Un des moments fatidiques durant lequel vous allez pouvoir vous rendre compte de la qualité d’un code, c’est lorsque vous effectuez une code review ! Cela implique d’avoir établit vos propres critères de qualité. Ces critères sont eux-mêmes, très souvent définit par un minimum de principes à suivre que l’on connait déjà.

Vous faîtes de la POO, alors suivez le principe SOLID. Vous écrivez du PHP, alors suivez un standard d’écriture (PHPCS, WPCS, … ). Vous êtes un puriste du “if” en une ligne ? Vous prenez en compte la complexité algorithmique ? Maintenabilité, flexibilité, testabilité, … tout autant de critères qu’il vous faut définir.

Beaucoup de critères qui, finalement mis bout-à-bout, forment un ensemble de ce qu’est la qualité d’un code. Pour autant, cela signifie-t-il que, si vous n’avez pas la connaissance nécessaire pour pouvoir mesurer et vérifier toutes ces problématiques, vous êtes un imposteur ou un mauvais développeur ? Non !

J’ai énuméré ces points très rapidement, mais les problématiques sont bien plus nombreuses. Elles peuvent différer selon les langages, l’application du code (côté serveur ou côté client), et bien d’autres choses. Alors comment faire ? Quelle est la bonne mesure ? Et bien… il y a un autre moment très important où l’on mesure la qualité du code, lors de l’ouverture du code source d’un projet. Et là, c’est le drame !

Le nombre de “WTF” (What The Fuck) à la minute

Vous avez bien lu : “WTF”. Ce n’est pas une unité de mesure officielle mais, pour ma part, c’est ma préférée. Que ce soit votre code ou celui de quelqu’un d’autre, c’est le moment où vous êtes en train de (re)découvrir ce qui est écrit et où vous ne pouvez que vous exclamer : “Qu’est-ce que c’est que ce bordel ?”.

Il y a plusieurs raisons à cela :

• Vous venez d’identifier une faille de sécurité
• Une suite de 10 instructions “if”, parsemé de quelques “foreach”. Merci pour la complexité algorithmique.
• Des noms de variables incompréhensibles
• Du code en Français (oups) quoique… Le “Franglais” n’est-il pas pire ?
• Aucun standard d’écriture
• Une ligne en PascalCase puis … camelCase puis… snake_case
• Un fichier / Une classe = une responsabilité. Ce principe n’est pas respecté, on préfère le mode 1 000~2 000 lignes par fichier.
• …

Et bien d’autres exemples pourraient venir compléter cette liste. Malheureusement, cela demanderait beaucoup d’efforts pour la rendre exhaustive (cf. plus haut, il y a beaucoup de critères !).

Vous remarquerez aussi que cette unité de mesure évolue dans le temps. Elle évolue en fonction de vos compétences, de votre savoir, de vos connaissances. On retrouve régulièrement cette sensation 3~4 mois plus tard (plus ou moins, ça dépend de vos découvertes, de votre veille, … ), quand on revient sur du code que l’on a produit : “Qu’est-ce que j’ai fait ?!”.

Avec cette exclamation, vous venez de juger de la qualité de votre code. Celle-ci n’est donc pas dépendante que de quelques critères que l’on peut faire rentrer dans un programme automatique qui nous donne une note.

Que faut-il retenir ?

Tout d’abord, je dirais que l’important dans la qualité, c’est de diminuer au maximum le nombre de “WTF” que vous allez dire à la minute. Ensuite, pour obtenir les meilleures mesures, il faut aussi un maximum de connaissances.

Par exemple, vous remarquez que le major d’une promotion d’étudiants en informatique de 1ère année produira un code d’une qualité surprenante pour ses camarades. En revanche, si l’on doit le comparer aux attentes d’une entreprise, si l’on doit juger de sa maintenabilité, de sa sécurité, … il serait logique que cet étudiant n’ait pas un code si extraordinaire que ça (même s’il peut toujours exister des exceptions, évidemment). Typiquement, cela n’aurait pas de sens de le comparer à celui d’un 5ème année.

Il faut donc adapter son jugement en fonction de ses attentes. Les meilleurs développeurs sont tout à fait capables de toujours produire des perles rares. Seulement, est-il toujours intéressant d’être à la recherche du “meilleur” dans tous les contextes ? Rien n’est moins sûr. Soyez pragmatique en fonction du projet, des attentes et du budget qui lui est accordé. Choisissez vos critères, mesurez-les et respectez-les (même au point de devoir les afficher sur une feuille dans les toilettes !).