Craftsmanship du code :

Salut toi ! Oui, toi qui viens de réussir à faire fonctionner ton code après 37 tentatives et qui t'apprêtes à pusher ce magnifique spaghetti en production. Poses ce clavier une seconde et parlons un peu de cette chose étrange appelée "craftsmanship" qui fait tant jaser dans les meetups et les conférences tech branchées.

"Ça marche, non ? Pourquoi se prendre la tête ?" Ah, la fameuse phrase ! Je l'entends au moins trois fois par semaine. Mais laisse-moi te poser une question : tu achèterais une voiture fabriquée par quelqu'un qui dit "ça roule, non ? Pourquoi se prendre la tête avec les freins ?"

Le craftsmanship, ou l'artisanat du code si tu préfères le français, c'est cette idée folle que programmer n'est pas juste aligner des caractères qui compilent, mais bien un métier qui mérite d'être exercé avec soin, précision et fierté.

Mais pourquoi tant d'efforts, me diras-tu ? Ton PM va te harceler pour la prochaine feature de toute façon, et personne ne va jamais relire ce code, pas vrai ?

FAUX. Et je vais te dire pourquoi.

Le code, ce cadeau empoisonné qui ne cesse de faire mal

Petit quiz rapide : qui va passer plus de temps à lire ton code qu'à l'écrire ?

1. Ton boss
2. Les utilisateurs
3. Toi-même et tes collègues développeurs
4. L'IA qui nous remplacera tous bientôt

Si tu as répondu 3, bravo ! Voici une vérité qui dérange : tu passes beaucoup plus de temps à lire du code qu'à en écrire. Et ça inclut ton propre code d'il y a 6 mois, que tu regarderas en te demandant quel idiot a bien pu écrire cette horreur... avant de réaliser que c'était toi.

Selon des études (oui, des vrais chercheurs s'intéressent à nos misères de dev), les programmeurs passent environ 70% de leur temps à lire et comprendre du code existant, et seulement 30% à en écrire du nouveau. Ça remet les choses en perspective, non ?

"Clean Code", ce bouquin que tout le monde cite mais que personne n'a lu jusqu'au bout

Robert C. Martin, alias Uncle Bob, a écrit un livre devenu culte : "Clean Code". Tout le monde en parle, beaucoup l'ont sur leur étagère, peu l'ont lu entièrement.

Si tu fais partie de ceux qui n'ont pas dépassé le chapitre 3, voici le TL;DR : ton code devrait se lire comme une histoire bien écrite, pas comme les conditions générales d'utilisation d'une appli.

La différence ? Le deuxième exemple se comprend immédiatement. Il raconte son intention, pas son implémentation.

Et avant que tu ne dises "mais ça prend plus de lignes !" - oui, parfois le code propre est plus verbeux. Mais rappelle-toi les 70% de temps passés à lire. Tu préfères économiser 2 minutes d'écriture ou 20 minutes de compréhension plus tard ?

Le mythe du "développeur 10x"

On a tous entendu parler de ce mythe : le développeur qui est 10 fois plus productif que les autres. Certains pensent que c'est une question de vitesse de frappe ou d'intelligence supérieure.

Conneries. Le vrai développeur 10x n'est pas celui qui code le plus vite, mais celui qui :

1. Ne crée pas de dette technique que quelqu'un devra rembourser plus tard
2. Écrit du code que les autres peuvent comprendre et modifier facilement
3. Teste son code pour éviter les régressions

En d'autres termes : un artisan.

J'ai vu des équipes entières paralysées par la peur de toucher au code d'un "génie" parti depuis longtemps. Ce type avait peut-être produit rapidement, mais il a laissé une bombe à retardement.

"Je n'ai pas le temps pour ça !" - Le plus grand mensonge qu'on se raconte

Ah, le manque de temps, cette excuse universelle ! Permets-moi d'être direct : c'est une illusion.

Tu n'as pas le temps de faire les choses correctement, mais tu auras magiquement le temps de corriger les bugs, refaire le travail, et expliquer à tes utilisateurs pourquoi l'application plante ?

Le craftsmanship n'est pas un luxe qu'on s'offre quand on a du temps. C'est une nécessité qui nous fait gagner du temps.

Un exemple concret : j'ai travaillé sur un projet où l'équipe précédente avait "gagné du temps" en négligeant les tests automatisés. Résultat ? Chaque déploiement était une roulette russe. Une simple modification prenait des jours car il fallait faire des tests manuels exhaustifs. Le "gain de temps" initial s'était transformé en cauchemar permanent.

Les piliers du craftsmanship (sans le jargon pompeux)

Si tu as survécu jusqu'ici, bravo ! Voici ce qui, selon moi, constitue vraiment le craftsmanship du code :

1. La lisibilité avant tout

Si ton code nécessite une explication orale, c'est qu'il y a un problème. Le code devrait s'expliquer lui-même.

2. Les tests ne sont pas optionnels

Ils sont ta police d'assurance contre toi-même et contre les autres. Et je ne parle pas seulement des tests unitaires, mais aussi des tests d'intégration, fonctionnels, etc.

3. La simplicité est sophistiquée

La solution la plus élégante est souvent la plus simple, pas celle qui utilise le dernier framework à la mode ou un pattern design super complexe.

4. Refactoriser régulièrement

Le code est comme un jardin : il faut régulièrement désherber. Le refactoring n'est pas "du temps perdu" mais un investissement sur l'avenir.

5. La collaboration, pas l'ego

Le vrai craftsmanship implique d'accepter les code reviews, de demander des conseils, et parfois d'admettre que quelqu'un d'autre a une meilleure idée.

Les bénéfices tangibles (ou "comment convaincre ton boss")

Tu es convaincu mais ton manager pense que le craftsmanship c'est juste une excuse pour coder plus lentement ? Voici des arguments chiffrés :

• Maintenance réduite : Selon des études IBM, chaque dollar investi dans la qualité du code en économise 4 à 8 en maintenance.
• Onboarding plus rapide : Une nouvelle personne devient productive en quelques jours sur du code propre, contre plusieurs semaines sur du code brouillon.
• Moins de bugs : Des études montrent que le code bien structuré et testé produit 50 à 80% moins de bugs.
• Innovation facilitée : Quand tu n'as pas peur de casser des choses, tu peux implémenter de nouvelles fonctionnalités plus rapidement.

Commencer sans révolutionner tout de suite

Je ne te demande pas de devenir un moine du code du jour au lendemain. Voici quelques étapes progressives :

1. La règle du boy-scout : Laisse chaque module que tu touches un peu plus propre que tu ne l'as trouvé.
2. Pair-programming : Code avec quelqu'un d'autre de temps en temps, rien qu'une heure par semaine.
3. Code reviews bienveillantes : Pas pour pointer du doigt, mais pour partager et apprendre.
4. Les tests d'abord pour les bugs : Avant de corriger un bug, écris un test qui le reproduit.
5. Noms significatifs : Prends 30 secondes de plus pour trouver un nom de variable ou de fonction qui a du sens.

Mon avis personnel

Après plus de 15 ans de développement, voici ma vérité : le craftsmanship n'est pas une question de perfection, c'est une question de respect.

Respect pour les utilisateurs qui dépendent de ton code. Respect pour tes collègues qui devront le maintenir. Et respect pour toi-même et ton métier.

Je ne dis pas que chaque ligne doit être un chef-d'œuvre. Je dis simplement que nous devrions aspirer à être fiers de ce que nous créons, même des parties que personne d'autre ne verra jamais.

Alors, craftsmanship : mode passagère ou nécessité ?

À toi de décider. Mais laisse-moi te dire ceci : j'ai vu des projets s'effondrer sous le poids de leur propre complexité. J'ai vu des startups prometteuses échouer parce qu'elles ne pouvaient plus évoluer rapidement. Et j'ai vu des développeurs brûler de fatigue à force de combattre un code hostile.

Je n'ai jamais vu, en revanche, une équipe se plaindre d'avoir un code trop propre, trop bien testé, ou trop facile à comprendre.

Le craftsmanship a un coût, c'est vrai. Mais son absence en a un bien plus grand.

Alors, la prochaine fois que tu t'apprêtes à commiter un "quick fix" avec le commentaire "// À refactoriser plus tard" (ce mensonge qu'on se raconte tous), demande-toi : est-ce que je traite mon code comme un produit dont je suis fier, ou comme une corvée dont je veux me débarrasser au plus vite ?

Et toi, qu'en penses-tu ? Le craftsmanship est-il un luxe, une nécessité, ou juste un concept à la mode que seuls les projets richement financés peuvent se permettre ? J'aimerais vraiment connaître ton point de vue.