< /Craftsman, l’artisan du code>
Il est le compagnon du devoir des temps modernes, l’artisan du logiciel, le digne héritier des mouvements du compagnonnage, né à l’époque des grands chantiers du Moyen Âge, lorsque s’édifiaient les cathédrales…
Qui sont ces artisans du code? Quelles sont leurs valeurs? Quels bénéfices une entreprise peut-elle tirer de cette approche Crafstmanship?
Le Test-Driven Development, l'Agile Testing, les challenges du code legacy, BDD, TDD, l'attitude Clean Coder sonnent comme une douce mélodie à vos oreilles? Bienvenue dans l’approche Crafstman ou l’art de concevoir du code de qualité…
Le Crafstmanship software est apparu aux Etats-Unis à la fin des années 2000. Mais déjà dès le début des années 1990 Jack W. Reeves explique pourquoi le développement logiciel se rapproche plus d’un art que d'une discipline d'ingénierie dans What Is Software Design?
Sept ans plus tard dans The Pragmatic Programmer: From Journeyman to Master, Andy Hunt & David Thomas posent les concepts qui serviront de fondements au mouvement que l’on connait aujourd’hui et dont les principes sont énoncés dans le Manifesto for Software Craftsmanship.
A quoi ressemble un craftsman?
C’est avant tout un développeur très solide techniquement. C’est aussi quelqu’un de passionné par la programmation dont la curiosité et l’implication dépassent largement ses horaires de travail. Concrètement cela se traduit par une veille active, la lecture/participation aux blogs, forums, meetups, etc. Des rencontres au sein de la communauté des craftsmen pour échanger, partager, apprendre et du coup être force de proposition concernant des choix techniques ou des améliorations dans les méthodes de travail par exemple.
C’est en quelque sorte un amoureux du code comme l’explique Antoine Sauvinet, craftsman convaincu : «Mon code je le pense, je l’écris, je l’améliore, je le chéris je le façonne. Mes collègues sont contents, ils arrivent à l’exploiter, à se brancher dessus facilement tout est pensé en amont pour faciliter les améliorations potentielles à y apporter».
Un craftsman, c’est aussi un développeur pragmatique qui connait très bien les besoins métiers. Plus qu’un logiciel parfait, c’est avant tout un produit fonctionnel, simple et qui répond aux besoins clients que le craftsman essaie de livrer.
Plus qu’une technique, un état d’esprit?
A écouter ces artisans du code, il s’agit davantage d’un état d’esprit, d’une approche qui place la création au centre, que d’une technique particulière ou d’un outil précis.
«Adopter l’esprit craftsman c’est se sentir sûr de ce que l’on produit, connaître où l’on se situe, pourquoi fait-on ce que l’on fait, avoir une volonté de partage et d’entraide débordante, et ne jamais se sentir seul. En soi, être le maillon d’une équipe solide.», détaille Jean-Laurent de Morlhon, créateur du xebia studio.
Quelles sont donc les caractéristiques de ce mouvement?
Elles sont énoncées dans le Manifeste du Craftsman, une sorte de code de bonne conduite, auquel se conforme tout craftsman qui se respecte.
Principe 1: du code bien pensé et bien conçu «well-crafted software»
Il ne suffit pas qu’un logiciel fonctionne, il faut qu’il soit bien écrit, c’est-à-dire bien pensé et bien conçu pour lui permettre d’être amélioré si nécessaire. Le développement doit résoudre les besoins du client (tant d’un point de vue technique que fonctionnel) mais doit aussi être viable sur le long terme.
Principe 2: Créer de la valeur «steadling adding value»
Chaque ligne de code doit créer de la valeur ; il ne faut pas cesser d’ajouter de la valeur à un programme.
Principe 3: Une communauté de professionnels «a community of professionals»
C’est l’appartenance à une communauté de professionnels qui fait progresser.
Principe 4: Une relation productive avec le client «productive partnerships»
Ces quelques lignes, pleines de bon sens, apparaissent tout droit sorties d’un manuel d’éthique professionnelle du parfait développeur ! Comment ces principes se traduisent-ils concrètement?
Leur mise en œuvre nécessite l’utilisation de pratiques et méthodes de travail, comme par exemple le travail en équipe où chacun contribue aux diverses tâches – programmation, définition du design, des patterns, choix des méthodologies en équipe, etc.- et apprend des échanges avec ses pairs.
On parle ainsi de Pair programming quand deux développeurs travaillent ensemble sur un même poste de travail et de coding dojo quand plusieurs personnes travaillent collectivement sur la base du volontariat sur un même défi de programmation.
Plusieurs cerveaux bien câblés, qui réfléchissent ensemble à une même problématique, se révèlent souvent utiles lors de la résolution de tâches complexes… et de gagner du temps.
Le temps, justement, il faut savoir le prendre pour bien faire les choses, et cela commence en amont des projets en impliquant les développeurs, les responsables qualités, les intervenants non-techniques et les entreprises participant à un projet de logiciel pour détecter les problèmes le plus tôt possible et les résoudre. C’est ce que permet la méthode du Behavior Driven Development (BDD). Il s’agit de co-construire les spécifications ensemble à partir du besoin de l’utilisateur, écrit dans un langage compréhensible par le métier (le client).
Une autre méthode qui permet de détecter les problèmes très en amont est le Test-Driven Development (TDD) ou en français «développement piloté par les tests». De quoi s’agit-il? C’est une technique de développement logiciel qui préconise d'écrire les tests unitaires avant d'écrire le code source d'un logiciel, ce qui permet le gros avantage de «refactorer le code en continue et aussi d’analyser les metrics de réalisation comme la vélocité par exemple tout au long du cycle de vie du logiciel» Antoine Sauvinet. Pour vérifier le bon fonctionnement d'une partie précise d'un logiciel ou d'un programme et trouver les erreurs rapidement, sécuriser la maintenance et documenter le code.
Une autre bonne pratique dont l’objectif est d’améliorer la qualité et la sécurité d’un logiciel tout en détectant au plus tôt dans le cycle de vie, les anomalies et bugs potentiel, est la revue de code ou Code review, examen systématique du code source d'un logiciel.
Quels bénéfices une entreprise peut-elle tirer d’une approche craftsman?
A priori on pourrait croire que les logiques de Craftsmanship et de Time to market s’opposent car si pour l’une le temps est un allié pour l’autre il est souvent synonyme de coût supplémentaire.
C’est en partie vrai au tout début de la mise en œuvre des principes Craftsman car il faut sensibiliser à l’approche, former les équipes, accompagner le changement ce qui implique du temps consacré à l’implémentation de nouvelles méthodologies.
La dette technique d’un projet mal conçu va souvent être identifiée plus tard. «Le problème avec le "vite et sale", c'est que le "sale" demeure bien longtemps après que le "vite" ait été oublié.» explique Steve McConnell, CEO and Chief Software Engineer Construx Software dans Code complete. Ce que l’on gagne maintenant, on va le perdre au centuple plus tard. Or bien souvent les entreprises ne voient que le ROI à court terme.
Mais le coût se révèle vite un investissement.
Selon Morgan Richard, Lead Developpeur chez Betclic Everest group, il faut une prise de conscience de la part des dirigeants : «au début il va falloir accepter qu‘une partie de sa capacité à livrer sera diminuée mais qu’au final il n’y a que des bénéfices : les estimés sont plus précis, la dette technique diminue, la maintenabilité augmente, la pérennité…et même le time to market ! (le délai nécessaire pour le développement et la mise au point d'un projet ou d'un produit, avant qu'il puisse être lancé sur le marché.)» Ce qui est un atout stratégique majeur impactant directement la rentabilité et permettant à une entreprise de prendre un avantage concurrentiel décisif.
Quand je lui ai posé la question, Robert C.Martin, alias Uncle Bob pour les initiés, m’a répondu sans hésiter que les bénéfices étaient multiples. L’auteur de The Clean Coder, l’un des leaders du mouvement Craftsman est convaincu que ce cercle vertueux de bonnes pratiques améliore le Time to market, la qualité des produits et au final la satisfaction du client.
Anne-Caroline Lourmière est la fondatrice de Talentik, un cabinet de recrutement indépendant spécialisé dans les métiers du Digital. Basé entre Paris, Bordeaux et Montréal, elle est « expert » RH pour Frenchweb.fr. Pour suivre ses écrits et échanger avec elle :
Son compte LinkedIn
Son compte sur Twitter
Pour contacter la rédaction: redaction@frenchweb.fr
Pour plus d'informations sur nos abonnements, merci de nous contacter à abonnement@frenchweb.fr
Vous souhaitez contribuer régulièrement en tant qu'expert sur FRENCHWEB.FR, merci de nous contacter à redaction@frenchweb.fr
- Ask A VC : comment modéliser un compte de résultat — Partie 6/6 : analyse de sensitivité - 21/05/2024
- Ask A VC : comment modéliser un compte de résultat — Partie 3/6 : les Coûts Fixes - 16/01/2024
- Question à un VC : Pourquoi les marges unitaires sont-elles si importantes pour votre modèle d’affaires? - 13/11/2023
Merci pour cet article ! Ravi de voir que toutes ces initiatives remettant la qualité de code au centre des préoccupations ne sont plus le fait de « geeks illuminés » mais bien de managers conscients des retombées business :)