Pourquoi est-il important de pouvoir écrire du code "sale" ? (et comment faire pour qu’il ne le reste pas ?)

On voit souvent des articles expliquant pourquoi il est important d’avoir du code « propre ». Cela permet d’avoir du code plus lisible, plus facile à maintenir et avec généralement moins de bugs. Tout cela est parfaitement vrai, ce n’est pas moi ou les équipes de développement qui vous dirons le contraire. Sauf que, comment arrive-t-on à ce code de qualité ? Est-ce que l’on doit le créer parfait (ou presque) sinon c’est « fichu » ?

Certaines personnes seront sans doute en désaccord, mais je pense que quand on veut créer quelque chose, le plus important c’est de créer. La qualité viendra après. 

Coder s’apparente à monter un meuble. Il vous faut rassembler plein d’éléments différents pour ensuite les assembler afin de parvenir au résultat souhaité. Et une fois que vous avez fini, il va vous falloir tout ranger et passer un coup de balai parce que vous avez mis de la poussière partout.

Lorsque l’on monte un meuble, on doit temporairement ignorer le fait que la pièce où l’on travaille est désormais « en bazar ». Ce n’est pas esthétique, mais c’est une étape nécessaire. Il est parfaitement possible de monter un meuble en minimisant le bazar créé (par exemple, en rangeant le tournevis entre chaque utilisation), cependant, on devient alors moins efficace. Se préoccuper du rangement quand on monte un meuble, c’est passer deux fois plus de temps à monter ledit meuble.

Pour cette raison, je vous conseille fortement de ne PAS vous préoccuper de la qualité de votre code lorsque vous écrivez la 1ère version. Faites quelque chose de moche, avec du code redondant, dupliqué et des copier-coller sales, mais faites quelque chose qui fonctionne ! Vous ferez le ménage ensuite (et je vous en prie, faites effectivement le ménage ensuite. Les gens n’aiment pas plus le code sale que les maisons sales. Particulièrement s’ils doivent ensuite s’occuper de ladite maison ou dudit code).

Personnellement, je suis assez « obsédée » par l’idée d’avoir du code propre et de qualité. Mes fichiers ne doivent pas être trop longs, mes fonctions idem, il ne doit pas y avoir de code redondant, tout doit être bien rangé, à sa place et facile à comprendre.

Sauf que voilà, lorsque je crée du nouveau code, cette obsession pour la « propreté » peut me paralyser. J’envisage tout plein de scénarios, mon cerveau part dans tous les sens et je n’avance pas. Alors dans ces moments-là, je suis obligée de me rappeler : « Crée quelque chose qui fonctionne, tu créeras quelque chose de beau et propre après ».

Chez Ekwateur, on est à fond pour la qualité, cependant, si votre obsession pour cette dernière vous empêche d’avancer, alors vous avez un problème.

On veut du code beau et propre parce que ce genre de code est plus facile à comprendre, à maintenir et contient moins de bugs. Néanmoins, pour arriver à ce résultat, il faut parfois commencer par faire du code un peu moins beau avec des morceaux inutiles et redondants. Il faut du temps pour créer quelque chose et ça ne sera jamais parfait du premier coup. Alors ne vous mettez pas trop la pression avec ça et créez quelque chose à l’image de l’humanité : imparfait mais qui s’améliore.

Certain-e-s parmi vous sont probablement en train de s’inquiéter de la dette technique (la « dette technique » pouvant se définir comme « tous les problèmes que l’on accumule lorsqu’on laisse son code sale ») et du fait que remettre le « ménage » à plus tard, c’est prendre le risque de ne jamais le faire. Vous avez raison, si vous remettez le « ménage » à la toute fin du projet, c’est effectivement ce qui arrivera (et vous vous retrouverez avec du code non maintenable que vous serez obligé-e de refaire de A à Z deux ans plus tard tellement cela sera devenu ingérable).

Il y’a cependant une différence entre « commencer par écrire quelque chose de potentiellement sale » et « ne jamais nettoyer son code avant qu’absolument tout soit terminé ». Attendre la toute fin d’un projet pour nettoyer le code, c’est définitivement chercher les ennuis. Déjà, vous n’aurez pas le temps, ensuite ça va vous barber et enfin vous aurez l’impression qu’on vous demande d’escalader le Mont-Blanc en une fois et sans entrainement ; ce que vous n’êtes définitivement pas prêt-e à faire. Bref, vous allez rapidement vous décourager et abandonner (laissant au passage une montagne de dette technique à votre successeur-euse ce qui n’est vraiment pas cool).

C’est pour cela que je préconise de faire le ménage « par étape » tout au long du développement de votre code.

Généralement, quand on vit quelque part, on ne se contente pas de faire le ménage une fois par an. Et quand on fait le ménage, on ne fait pas tous les « types » de ménage en même temps. Par exemple, on fait la vaisselle tous les jours, on passe le balai une fois par semaine, on change ses draps une fois par mois et on refait la peinture tous les 10 ans.

Pour le code, c’est pareil. Seulement la métrique n’est pas le temps écoulé (si vous n’avez pas touché à votre code, il n’y a pas de raison qu’il soit devenu sale) mais plutôt le nombre de lignes de code ajoutées/modifiées.

Ainsi, une fois que vous avez fini d’écrire une fonction (et après avoir vérifié qu’elle fonctionnait), faites le ménage au sein de cette fonction. N’attendez pas d’avoir fini entièrement votre fonctionnalité. Attendre ici ne vous servira à rien puisque votre fonction est terminée. Faites de même après avoir implémenté un groupe de fonctions liées entre elles. Idem après avoir ajouté 200 lignes de code ou créé une nouvelle classe/un nouveau fichier. Et idem une fois que votre fonctionnalité sera effectivement implémentée dans son intégralité.

Après chacune de ces étapes, prenez le temps de regarder votre code et de voir si vous ne pouvez pas l’améliorer. Groupez vos fonctions entre elles : par exemple, mettre tous les getters et les setters (fonctions simples et « sans intelligence ») tout en haut de vos classes. Vérifiez que vous n’avez pas de code redondant. Supprimez votre code mort. Virez ces lignes de code commentées que vous gardez « au cas où ». Je sais, moi aussi ça me brise le cœur. C’est comme de me débarrasser de ce vieux truc à moitié cassé dont je n’ai pas eu besoin en 10 ans, mais « on ne sait jamais, peut être que ce presse-purée portatif à bretelles me sauvera la vie dans un futur proche ». Spoiler : ça ne sera pas le cas. Assurez-vous que vos fonctions et classes ont une taille « raisonnable » (non, une fonction n’est pas supposée faire 200 lignes et une classe n’est pas supposée en faire 1000).

Bref, prenez le temps de regarder votre code. Faites-le entre chacune de vos « micro-tâches » et si quelque chose peut être amélioré, alors améliorez-le. Ne remettez pas à plus tard. Faites les choses au fur et à mesure. Croyez-moi, vous ne voulez pas nettoyer cette montagne de code « sale » en une fois.

Il est souvent difficile de juger son propre travail. D’autant que nous n’avons pas tous la même notion de ce qu’est un code « propre » (utilisation d’espace ou de tabulation ? Combien de saut de ligne entre deux fonctions ? CamelCase ou underscore_case ?) et que les « Guide de développement » ont tendance à changer d’une société à l’autre. En outre, lorsque l’on travaille en entreprise, il arrivera généralement un moment ou quelqu’un d’autre que nous devra s’occuper du code que nous aurons créé. Dans ces conditions, il est particulièrement important que notre code soit effectivement « propre » et pas juste à nos yeux. Autrement, notre collègue pourrait trouver notre code difficile à comprendre et aura beaucoup de mal à le modifier pour lui apporter les améliorations voulues. Et c’est comme ça que l’on se retrouve à recoder toute une app alors que ça n’aurait pas dû être nécessaire.

Pour éviter ce genre de problèmes, il existe deux solutions simples :

En informatique, il y a ce que l’on appelle les « bonnes pratiques ». Ces bonnes pratiques peuvent notamment être liées à de l’indentation de code (pour sa bonne relecture suivant des conventions). Quoi qu’il en soit, suivre ces bonnes pratiques c’est rendre notre code plus compréhensible par les autres et donc plus « propre ».

Ainsi, je vous recommande fortement de vous assurer très régulièrement (par exemple à chaque commit, donc minimum une fois par jour) que votre code respecte ces bonnes pratiques. Généralement, votre IDE se chargera en partie de vérifier cela (notamment si vous ajoutez des plugins tel que SonarLint). Il existe également de nombreux outils pour aller encore plus loin dans l’analyse de votre code et s’assurer que « tout va bien ». Je pense notamment à CodeQuality ou encore au très connu SonarQube pour Java, c#, c++, JavaScript, php, Python et pleins d’autres langages (la liste complète est disponible ici : https://www.sonarqube.org/features/multi-languages/ ). Et, afin de vous simplifier la tâche, n’hésitez pas à intégrer ces outils dans votre chaine de CI/CD comme nous le faisons chez Ekwateur.

La deuxième solution pour s’assurer que votre code est bien « propre » est de, tout simplement, demander son avis à un-e collègue. Chez Ekwateur, nous avons un système de « revue par les paires » et, à chaque fois que l’on ajoute une nouvelle fonctionnalité, au moment de merger (càd : fusionner notre code avec le code déjà existant), une revue est effectuée par au minimum une autre personne. Cette personne a la charge de s’assurer qu’aucun cas d’utilisation n’a été oublié (ce qui pourrait entrainer un bug), que le code est bien lisible et qu’il respecte les bonnes pratiques. Ainsi, les revues permettent de profiter de l’expérience des collègues et d’un point de vue extérieur « neutre » sur ce que l’on a créé.

En conclusion

Au tout début du processus de création, ne vous prenez pas trop la tête avec la propreté. Le plus important c’est de vous lancer et de créer. Toutefois, avoir du code propre est important, alors faites le ménage régulièrement quand vous avez fini de créer quelque chose. Et pour vous assurer que votre code est bel et bien propre, demandez leur avis à vos collègues et utilisez des outils d’analyse statique du code.

Conseil de pro : pensez également à mettre des commentaires à des endroits clés de votre code. Ça peut se révéler très utile. 😉