00 - Pourquoi le clean code est un investissement, pas un luxe

Ce que tu vas apprendre

• Pourquoi le code sale coûte cher (avec des chiffres)
• Pourquoi "on corrigera plus tard" est un mensonge
• Ce que le clean code est (et ce qu'il n'est pas)
• Le pragmatisme avant le dogmatisme
• Ce que cette serie de 23 articles couvre

Prerequisites

Aucun. C'est le point de depart de la serie.

En 2021, j'ai rejoint une équipe qui bossait sur une application de gestion d'inventaire. Le projet avait trois ans. Le premier jour, j'ai ouvert le fichier principal du backend. 4 200 lignes. Un seul fichier. Des variables nommees x, tmp, data2. Des fonctions de 300 lignes avec 12 paramètres. Des commentaires du type // TODO: fix this later dates de 2019.

J'ai demande a l'équipe combien de temps il fallait pour ajouter un nouveau champ a un produit. La réponse : deux semaines. Pour un champ. Le projet etait devenu un cauchemar ou chaque modification provoquait des regressions en cascade.

Ce n'etait pas un problème de technologie. C'etait un problème de code sale accumule pendant trois ans.

Le coût réel du code sale

Les chiffres sont sans appel. Selon une etude de Stripe publiee en 2018, les développeurs passent en moyenne 42% de leur temps a gerer de la dette technique et du code de mauvaise qualité. A l'échelle mondiale, ca represente 85 milliards de dollars par an en productivité perdue.

Le rapport CISQ (Consortium for Information and Software Quality) de 2022 estime le coût de la mauvaise qualité logicielle aux États-Unis a 2 170 milliards de dollars. Ce chiffre inclut les defaillances operationnelles, les projets echoues et la dette technique.

Ca fait mal. Et ca ne concerne pas que les grosses entreprises. Meme sur un projet perso ou une startup, le code sale ralentit. D'abord un peu. Puis beaucoup. Puis complètement.

"On corrigera plus tard" : le plus gros mensonge du dev

Tu l'as dit. Je l'ai dit. On l'a tous dit. "On livre ca comme ca, on refactorisera dans le prochain sprint." Ce sprint n'arrive jamais. Le backlog de dette technique grossit. Les nouveaux devs arrivent, voient le code existant, et reproduisent les memes patterns parce que "c'est comme ca qu'on fait ici".

Le code sale engendre du code sale. C'est la theorie de la vitre brisee appliquee au logiciel : si le code autour est degueulasse, tu n'as aucune motivation pour écrire du code propre. A quoi bon ?

Le moment le moins cher pour écrire du code propre, c'est maintenant. Pas demain. Pas au prochain sprint. Maintenant.

Ce que le clean code est (et ce qu'il n'est pas)

Le clean code, ce n'est pas :

• Écrire du code "beau" ou "elegant"
• Suivre aveuglément toutes les regles d'un livre
• Passer trois heures a nommer une variable
• Atteindre 100% de couverture de tests
• Refactoriser du code qui marche sans raison

Le clean code, c'est :

• Du code que ton collegue (ou toi dans 6 mois) peut lire et comprendre rapidement
• Du code ou les bugs sont faciles a localiser
• Du code ou ajouter une feature ne casse pas trois features existantes
• Du code ou les tests sont possibles sans acrobaties

Robert C. Martin le résumé bien : "Clean code is code that has been taken care of." C'est du code dont quelqu'un s'est occupe. Pas du code parfait. Du code soigne.

Pragmatisme avant dogmatisme

Je vais etre direct : cette serie ne sera pas un catechisme. Je ne vais pas te dire "toute fonction doit faire moins de 5 lignes" ou "il ne faut jamais utiliser de commentaires". Ce genre de regle absolue, c'est confortable mais c'est faux.

Le contexte compte. Un script de migration jetable n'a pas besoin du meme niveau de soin qu'une librairie open-source. Un prototype pour valider une idee n'a pas besoin d'une architecture hexagonale. Si tu veux approfondir les questions d'architecture, j'ai écrit une serie dédiée sur paltemps.fr.

Ce qui compte, c'est de savoir faire la différence entre "ce code est temporaire" et "ce code va vivre 5 ans". Et d'ajuster son effort en consequence.

Ce que cette serie couvre

Voici les 23 articles de la serie, regroupes par theme :

Les fondamentaux (00-07)

Les principes (08-12)

Le refactoring (13-18)

En pratique (19-22)

Pour qui ?

Cette serie est pour les devs qui ecrivent du TypeScript ou du JavaScript au quotidien. Les exemples sont en TypeScript, mais les principes s'appliquent a n'importe quel langage. Si tu debutes, tu vas apprendre les bonnes habitudes tot (c'est un avantage énorme). Si tu as de l'experience, tu vas mettre des mots sur des intuitions que tu as deja.

Tu n'as pas besoin de lire les articles dans l'ordre, mais les 8 premiers forment une base solide. Je te recommande de commencer par la.

Résumé

• Le code sale coûte des milliards chaque annee en productivité perdue
• "On corrigera plus tard" ne marche jamais en pratique
• Le clean code, c'est du code soigne, pas du code parfait
• Le pragmatisme bat le dogmatisme : adapte ton effort au contexte
• Cette serie couvre 23 articles, des fondamentaux au refactoring en équipe

Article suivant : 01 - Nommage

Sources

• Stripe, "The Developer Coefficient" (2018) - https://stripe.com/reports/developer-coefficient-2018
• CISQ, "The Cost of Poor Software Quality in the US" (2022) - https://www.it-cisq.org/the-cost-of-poor-quality-software-in-the-us-a-2022-report/
• Robert C. Martin, "Clean Code: A Handbook of Agile Software Craftsmanship" (2008) - https://www.oreilly.com/library/view/clean-code-a/9780136083238/