Un code c'est comme un fruit

Coder, ce n’est pas une science.

C’est plutôt comme un artisan qui fabrique des chaussures.

Il y a de la créativité, du savoir-faire pour que ce soit confortable et durable. Et surtout une bonne dose d'écoute et de compréhension du besoin de celui qui va porter les chaussures tous les jours.

Un code qui marche, c'est un début. Pas une fin.

On imagine que le boulot du développeur est de faire quelque chose qui fonctionne. Une fois ce but atteint, il faut passer à autre chose en laissant le code en l'état

Pourquoi y consacrerait-on davantage de temps et d'argent ? Puisque ça marche !

C'est en fait une sorte de suicide sur le long terme.

Car un code qui marche est souvent mal organisé. Il faut du temps pour le remettre en ordre. On parle de refactoring.

Quelle est la valeur du refactoring ? Combien rapporte un code de bonne qualité, comparé à un code qui se contente de faire le job ?

Le problème est que le mauvais code pourrit et fermente.

Petit à petit, il se transforme en un bourbier démoniaque dans lequel s'engluent les équipes. Il prend la main sur le projet. C'est lui qui décide des fonctions que l'on va faire et de celles auxquelles on renonce.

Pire : lorsque le code fermente, ses modules se contaminent. En modifiant un truc à un endroit, on provoque un problème ailleurs. Plus personne n'ose toucher à la bête à cause de ces dépendances enchevêtrées.

Qu'est-ce qu'un mauvais code ?

En discutant avec d'autres codeurs, c'est un débat toujours très passionné. D’ailleurs, un développeur trouve souvent que son code est meilleur que celui de son collègue.

Mais de quoi parle-t-on vraiment ? Je retiens en général 3 critères principaux :

• la lisibilité. A la lecture du code, on comprends comment il fonctionne.
• la modularité. Le code est découpé en modules indépendants qui n'assurent qu'une seule fonctionnalité.
• la simplicité.

Prenons un exemple.

On veut une fonction qui détermine le dernier jour du mois : 31 pour le mois n°1 (janvier), 28 pour le mois n°2 (février) ou 29 les années bissextiles, et ainsi de suite.

(alerte spoiler : vous pouvez continuez à lire même sans connaissance technique!)

Un exemple de code qui ne respecte aucun des 3 principes.

Aucun des 3 critères n’est vérifié dans ce code :

• Lisibilité : nulle. Enchevêtrement de conditions if/else à plat.
• Modularité : mauvaise. On ne comprends pas comment ça marche. C'est quoi cette fonction jourCompte ?
• Complexité. D'ailleurs, il y a un bug (le voyez-vous ? Sur les années bissextiles)

En plus, il fonctionne même lorsqu'on l'appelle avec le mois n°13 !

Un exemple de code refactoré

Même si vous ne savez pas coder, vous comprenez le code. Les fonctions et les variables ont des noms parlants. Ça en valait la peine, non ?

Comment se prémunir du pourrissement du code ?

“Il suffit d'embaucher de bons développeurs”.

Et bien non.

Ca ne suffit pas.

La qualité du code ne dépend pas seulement du développeur.

Elle dépend beaucoup de ceux qui l'entourent. Car on trouve toujours de bonnes raisons de sacrifier le refactoring :

• “On s'en fiche de la beauté de ton code. Il faut que ça fonctionne dans les délais".
• “C'est une première version. On raffinera plus tard”.
• “On a un fonctionnement itératif et agile. On mettra au propre au fur et à mesure que les bugs remonteront”.
• “On peut améliorer sans fin. Mais nous on est des pragmatiques, pas des perfectionnistes. Sinon, on ne met jamais rien en ligne”.

Bien sûr, on peut toujours nettoyer le code a posteriori. Mais c'est coûteux. Parce que c'est très compliqué de trouver et de casser les dépendances enchevêtrées.

Mieux vaut garder un code propre dès le début.

Si vous codez un bazar le matin, prenez l'après-midi pour le nettoyer. Encore mieux, si vous venez de passer 5 minutes à faire un code sale, nettoyez-le tout de suite.

Ne laissons jamais le pourrissement démarrer !