Un code c'est comme un fruit

Hervé Rincent

Hervé Rincent

1 déc. 2020

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 :

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.

Messy code

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

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 :

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 !


Continuer la lecture

Vers une tech plus simple, sobre, et légère

8 déc. 2020

4 min read

Vers une tech plus simple, sobre, et légère

Lire l'article
Le biais du survivant

24 nov. 2020

3 min read

Le biais du survivant

Lire l'article
Inscription à la newsletter

Recevez chaque semaine un article pour réfléchir à votre prochain projet tech/data

gratuit, sans spam, désinscription en 1 clic

Merci ! Regardez dans botre boite mail. Un lien de confirmation n'attend plus que votre clic.
Arghh il semble compliqué de vous ajouter à la liste de diffusion. Et si vous m'envoyiez un mail directement à contact@camilab.co ?