Que vous soyez développeur/développeuse junior ou expérimenté(e), vous vous confronterez forcément au code spaghetti un jour… Mais qu’est-ce que c’est au juste et comment s’en dépêtrer ? Notre expert Anthony, lead développeur PHP chez AddixGroup et chef de projet technique vous partage ses bonnes pratiques.
Qu’est-ce que le code spaghetti et comment l’identifier ?
C’est un code illisible, bien mélangé comme un bon plat de spaghetti bolognaise al dente, mais sans le goût et le plaisir. “ On parle de code difficile à maintenir, qui a des dépendances de partout, qui est tout emmêlé à l’intérieur. Du coup, pour quelqu’un qui veut intervenir sur le projet, c’est très difficile et illisible. Un code spaghetti peut être dû au code lui-même mais aussi au niveau de toute l’architecture du projet.” . s’exprime Anthony. “ Comment l’identifier ? Il faut compter le nombre de fois où on va être étonné ! Si, à chaque fois, on se dit que c’est pas normal où qu’on ne comprend pas quelque chose, c’est qu’il s’agit très probablement d’un code spaghetti ! ”
Un problème pour les équipes et les projets
Le code spaghetti entraîne des problématiques non-négligeables au niveau des équipes qui vont travailler sur le projet. Comme le dit si bien Anthony, “ Un nouveau développeur qui arrive sur un code spaghetti, va mettre trois à quatre fois plus de temps que sur un code qui est bien fait.”
Cela pose également des problèmes sur tout le développement du projet. “Si le code est fait n’importe comment, c’est très dur d’identifier quel sera l’impact de quoi. Une simple petite modification peut entraîner de gros impacts partout, sans même qu’on le sache ! En général, ce qui se passe dans les codes comme ça, c’est qu’il s’agissait de code spaghetti bien avant. Vu qu’on a pas envie de casser quelque chose, on rajoute de la surcouche, encore et encore et là… C’est la maxi carbonara !”
Quelques bonnes pratiques de développement pour éviter le code spaghetti
On sait ce que c’est, on sait comment l’identifier et quelles problématiques il entraîne. Maintenant, rentrons au cœur du sujet : comment concrètement l’éviter ? Anthony nous a présenter une liste non-exhaustive de ses bonnes pratiques :
1. Le nommage doit être clair et précis
“ Tout d’abord, il y a le nommage. Quand on nomme quelque chose, on doit savoir ce que c’est. Prenons par exemple un Dollar Client. S’il contient un identifiant à un moment, il faut qu’il le garde en permanence et pas qu’il passe d’un seul coup dans une condition et qu’il change tout le temps de variable. Une variable doit avoir un contenu unique. Maintenant, c’est de plus en plus facile de ne pas le faire, parce que les langages sont de plus en plus typés. Quand on déclare une variable, on doit lire de quelle type elle est”. Soit, c’est un integer (nombre entier) soit c’est un “string”, etc.” Avoir des noms de variables claires permet instantanément à la personne qui suit derrière de comprendre immédiatement de quoi il s’agit.
2. Utiliser correctement les fonctions
Une fonction doit faire une seule et unique chose. Tout comme le nommage, il est nécessaire de savoir ce qu’elle fait. “ Hier, j’avais un cas où ils voulaient récupérer de la Data dans un format spécifique. Ils voulaient retirer tous les accents, puis après mettre en majuscule. Si on fait une seule fonction qui fait les deux choses, ça sera moins lisible que si on fait deux fonctions différentes, spécifiques à un cas particulier ! ” Ainsi, une fonction spécifique à quelque chose sera plus facilement réutilisable.
3. Respecter les spécificités du langage en question
Chaque langage a des spécificités qui lui sont propres. Ses spécificités créent une sorte de convention globale à chaque langage qui permet à tout le monde de bien travailler. “ En PhP par exemple, Class commence toujours par une majuscule. On affiche aussi les noms de la variable “underscore” une autre. Si on ne respecte pas ça, le code sera beaucoup plus difficile à maintenir parce qu’il n’y a pas eu de respect des normes ”.
4. Quelques outils pour veiller à la qualité du code
Tout le monde peut écrire un code à sa manière. Mais il y a des normes à respecter. “ Par exemple, si on écrit un “if”, on met entre parenthèses le paramètre. Normalement, c’est censé être un espace et une accolade ” explique Anthony. “ Maintenant il existe des outils de qualité de code qui permettent de formater directement le code pour nous. Pour Javascript, il y a par exemple ESLint. Pour PHP, on a CS Fixer, PHP Insight. “ Cela permet de faire un code normé, quel que soit le développeur/la développeuse présent(e) sur le projet.
5. Aérer son code
Ce conseil s’adresse surtout aux jeunes développeurs : “ Si on a 40 lignes d’affilée, sans aucun saut de ligne, c’est indigeste à lire. Par exemple, on va avoir une fonction qui va prendre 10 paramètres. Il y en a beaucoup qui ont tendance à vouloir tout mettre à la suite. Il vaut mieux sauter des lignes et ne pas avoir peur de prendre un écran entier. Il faut que ça soit lisible ! ”
Comment s’extirper d’une situation de code spaghetti ?
1. Ne pas se laisser faire
“ Ce n’est pas parce que quelqu’un avant à fait n’importe quoi sur son code, qu’il faut aussi faire n’importe quoi. Au final, c’est en appliquant les changements minimums, comme par exemple, renommer les variables que ça aidera la prochaine personne qui viendra travailler sur le code.” Selon Anthony, si tout le monde y met du sien, le code deviendra de plus en plus propre. “ On devrait avoir 20% de temps en plus pour relire son code et le remettre au propre. ”
2. La review pour s’enrichir les uns, les autres
“ Les reviews devraient être nécessaires dans tous les projets car elles servent à faire avancer le développeur et celui/celles qui va faire la review. Quand quelqu’un a fini quelque chose, il devrait le faire relire. La personne qui relit peut ainsi mettre tous les commentaires qu’elle veut et la personne qui a codé peut ensuite réagir. ” La review permet d’engager une discussion améliore la vision des deux personnes. En plus, cela permet de raccorder l’équipe !
