Pratiques

Dédramatisation “Software Craftsmanship”, “Clean Code”, “SOLID”… Ces termes circulent partout dans notre écosystème, souvent accompagnés d’un sentiment d’intimidation. J’ai longtemps pensé que c’était réservé aux développeurs “experts”, à ceux qui écrivent des livres ou donnent des conférences. Erreur ! Le Software Craftsmanship, c’est avant tout une démarche progressive d’amélioration continue. Pas besoin d’être Robert C. Martin pour commencer. Il suffit de faire un pas, puis un autre. Le Software Craftsmanship n’est pas une destination, c’est un voyage. Chaque petit pas compte : un nom de variable plus clair, une fonction mieux découpée, un test ajouté. ...

Situation réelle “On va faire du pair programming systématique.” Six mois plus tard : équipe épuisée, vélocité divisée par deux, talents partent. Le pair programming imposé sans discernement peut détruire autant qu’il peut aider. Ce que j’ai observé : le pair programming est un outil puissant dans certains contextes, contre-productif dans d’autres. Le problème n’est pas l’outil, c’est l’usage dogmatique. Le faux problème Le faux problème serait de croire que pair programming = toujours mieux. En réalité, c’est un outil à utiliser dans des situations spécifiques, pas une religion. ...

Situation réelle Après avoir passé plusieurs années à accompagner des équipes dans leur transition vers l’open source, j’ai constaté une idée reçue persistante : “Il suffit de mettre son code sur GitHub pour faire de l’open source”. Cette vision simpliste cache une réalité bien plus complexe et passionnante. Ce que j’ai observé : la décision d’ouvrir son code n’est pas anodine et doit répondre à des objectifs clairs : partager votre expertise avec la communauté, bénéficier des contributions externes pour améliorer le projet, accroître la visibilité de votre entreprise dans l’écosystème tech, faciliter le recrutement de talents passionnés, améliorer la qualité du code grâce à l’examen public. ...

Situation réelle Commentaire sur une pull request : “Ça, c’est du code de junior. Refais tout.” Le développeur ne contribuera plus jamais avec la même confiance. La code review vient de passer d’outil de qualité à arme de destruction. Ce que j’ai observé : la code review est l’un des rituels les plus puissants pour la qualité ET la culture. Elle peut construire ou détruire. Rarement neutre. Le faux problème Le faux problème serait de croire que la code review sert uniquement à trouver des bugs. En réalité, elle sert à partager connaissance, aligner standards, et renforcer culture. ...

Situation réelle Imaginez cette situation : vous travaillez sur un projet interne, protégé par les murs invisibles de votre organisation. Les tests automatisés ? Une bonne intention, mais trop souvent reléguée au second plan. Un bout de code rapide et bancal ? Pourquoi pas, si ça “fait le job” pour la prochaine démo. Après tout, qui verra ces raccourcis ? Ce que j’ai observé : lorsqu’un projet est gardé dans un environnement fermé, il est tentant de sacrifier la qualité sur l’autel de la rapidité. Le “quick and dirty” devient une norme acceptable car les conséquences sont souvent invisibles à court terme. Mais cette approche peut rapidement dégénérer en une dette technique difficile à gérer. ...

Situation réelle Quand on parle d’impact carbone, on pense souvent à des problématiques industrielles ou aux transports. Pourtant, le numérique représente aujourd’hui près de 4% des émissions mondiales de gaz à effet de serre, un chiffre en constante augmentation. Ce que j’ai observé : chaque requête web, chaque octet transféré ou calcul exécuté contribue à ce bilan. En tant que développeurs, managers ou architectes, nous avons le pouvoir d’agir. Automatiser des tests pour évaluer et réduire l’impact carbone d’un projet est une démarche à la fois technique et porteuse de sens. ...

Situation réelle Incident majeur résolu. Maintenant vient le post-mortem. L’équipe est tendue, s’attend à être blâmée. Comment transformer cet échec en opportunité d’apprentissage plutôt qu’en séance de tribunal ? Ce que j’ai observé : les organisations qui punissent les erreurs créent une culture du silence. Celles qui apprennent des erreurs créent une culture de l’amélioration continue. Le faux problème Le faux problème serait de croire que “blameless” signifie “pas de responsabilité”. En réalité, blameless signifie “focus sur le système qui a permis l’erreur, pas sur la personne”. ...