L’idée du Software Craftsmanship, telle qu’exprimée dans le Manifeste for Software Craftsmanship , est (en partie) d’encourager les développeurs de logiciel et d’application métier à viser l’excellence dans leurs travaux afin de créer des partenariats productifs avec les clients et d’ajouter de la valeur régulièrement pour ces clients. Software Craftsmanship met l’accent sur l’adoption systématique de bonnes pratiques techniques de développement. On vous en dit plus dans cet article.
L'idée du Software Craftsmanship est d'encourager les développeurs de logiciels/d'applications métiers à viser l'excellence dans leur travail et à ajouter de la valeur de manière constante. Une bonne application métier est un chef-d'œuvre développé par une combinaison parfaite d'informatique, de décisions de conception créatives et d'appels de jugement pragmatiques.
Le mouvement du Software Craftsmanship met en évidence le fait « qu'il ne suffit pas qu’un logiciel soit fonctionnel, il faut qu’il soit bien conçu ». Le Software Craftsmanship consiste donc à remettre en question certaines pratiques de développements. Notamment sur la fiabilité et la facilité de maintenance.
Ainsi, les développeurs de logiciels qui prennent une part active dans le mouvement du Software Craftsmanship améliorent toujours leur savoir-faire et placent les logiciels avec un code de qualité avant toute autre chose. Ces développeurs n'ont pas peur de proposer de nouvelles idées, de partager leurs expériences, de proposer de nouveaux produits logiciels, de révolutionner l'industrie. Ils transmettent leurs astuces, le raisonnement derrière leurs décisions.
L'idée derrière le Software Craftsmanship est très bien exposée dans son Manifeste :
"En tant qu'artisans logiciels en herbe, nous élevons la barre du développement logiciel professionnel en le pratiquant et en aidant les autres à apprendre le métier. Grâce à ce travail, nous avons acquis de la valeur.
Autrement dit, à la recherche des éléments de gauche, nous avons trouvé les éléments de droite indispensables."
Le Software Craftsmanship est un mouvement qui s’est inspiré des concepts développés dans le livre « The Pragmatic Programmer: From Journeyman to Master » de Andy Hunt et David Thomas.
Les auteurs du Manifeste du Software Craftsmanship sont issus du mouvement Agile, qui visait à réformer la gestion de projets logiciels dans les années 90. Agile a son propre Manifeste qui dit :
Mais à la fin des années 2000, les développeurs de logiciels craignaient que l'agilité ne se concentrait pas suffisamment sur la qualité. En 2008, Bob Martin, l'un des auteurs du Manifeste Agile, a proposé que « Craftsmanship over Crap » soit ajouté comme 5ème valeur à son Manifeste. Mais ça ne l'a jamais été. Et ces développeurs ont trouvé leurs discussions sur le sujet rejetées par la principale conférence agile.
« Agile était trop dans le processus et non dans le métier de la programmation lui-même », explique Paul Pagel, alors développeur de logiciels en formation sous Martin.
Ils ont décidé de tenir un sommet à Libertyville, dans l'Illinois, pour élaborer leur propre manifeste. En 2009, le Manifeste était en ligne. Et cette année-là, ses auteurs ont tenu la première conférence sur le Software Craftsmanship - en même temps et juste en face de la conférence agile (quelle audace !).
Selon les précurseurs du mouvement, il ne suffit pas qu’un logiciel fonctionne, il doit être bien conçu et s’avérer économique. Cela nécessite l’intervention de développeurs expérimentés et capables de prendre les décisions adaptées. Par conséquent, il faut que le développeur soit parfaitement formé. Il doit suivre une formation spécialisée (comme la formation de Human Coders 👋) afin de devenir apte à résoudre des problématiques qui peuvent être fonctionnelles, techniques et économiques.
En tant que développeur on ne cherche pas absolument la perfection, mais la conception de produits de qualité qui répondent au mieux à un besoin donné, le bon aboutissement des projets et un maintien de ces produits dans la durée. Il faut donc faire au mieux tout en tenant compte du contexte.
Pour cela, certaines pratiques sont utilisées, afin d’atteindre ce niveau de qualité ; comme l’application de standards de code propre, le Clean Code, ou encore le Behavior-Driven Development (BDD) ou encore le Test-Driven Development (TDD), etc.
Que les développeurs aient entendu parler du Software Craftsmanship ou non, ils ont forcément entendu parler des concepts que le mouvement a popularisés. Un exemple majeur est le développement piloté par les tests (TDD), dans lequel le développement logiciel commence par l'écriture de tests. Chaque test détermine automatiquement si un logiciel répond à certaines exigences.
Un autre exemple est le Pair Programming, dans laquelle les programmeurs travaillent ensemble par paires sur un seul poste de travail. Un codeur « conduit », tandis que l'autre examine le code et aide à détecter les erreurs et à signaler les problèmes.
Enfin, il y a le « Refactoring », le processus de raffinage du code existant. Le but est d'éditer le code pour qu'il soit plus facile à comprendre et moins sujet aux bugs.
On cherche en tout temps à apprendre, encore et encore, car le métier de développeur en perpétuelle évolution. Pour rester à jour et améliorer son savoir faire, on va : lire des livres, des blogs - s’entraîner, en essayant de nouveaux outils, des nouveaux langages, des nouvelles méthodes - rencontrer d’autres développeurs à des conférences, des meetups - ou encore en trouvant des mentors ou des lead tech pour nous accompagner.
Cependant, adopter la culture du Software Craftsmanship, à l'échelle individuelle, est un peu plus complexe. Effectivement, il y a des développeurs ne se sentent pas concerné. Malgré le fait de pratiquer le TDD ou aller à des meetups régulièrement, de nombreux développeurs se sentent seuls dans leur entreprise. Ils ont la sensation de ne pas partager les valeurs de certains collègues ou de se heurter à un mur lorsqu’ils parlent de ces valeurs avec le management.
L'état d'esprit et les fondements essentielles pour être un Software Craftsman sont définis par plusieurs valeurs, dont celles-ci :
On sait que la majorité des logiciels ou applications métiers sont réalisés en équipe. Toutes ces réalisations sont le fruit d'un travail collectif. Pour diffuser la culture de la qualité au sein de l’équipe et des projets, on peut s’appuyer sur plusieurs pratiques :
Prenons l'exemple de l'organisation de dojo. Un dojo de codage est un rassemblement de développeurs qui travaillent ensemble pour apprendre comment résoudre au mieux un problème. Le but d'un dojo n'est pas de produire un produit, mais plutôt d'apprendre à mieux écrire du code. Il est possible d'en savoir plus sur le site de Coding Dojo.
Les concepts de dojos et de katas sont tous deux issus du monde des arts martiaux. Les artistes martiaux fréquentent les dojos pour apprendre des maîtres. Les katas sont les mouvements répétitifs que les artistes martiaux mènent pour développer la mémoire musculaire. En appliquant le concept de mentorat et de pratique, nous avons constaté que cela constitue le moyen le plus efficace de partager les meilleures pratiques.
Les katas se concentrent sur le développement piloté par les tests (TDD) et la Pair Programming. Au début d'un dojo, un kata est introduit et tout le monde se divise en paires. Chaque paire utilise un seul ordinateur. Le premier développeur de la paire écrit un test d'échec simple, puis transmet l'ordinateur au deuxième développeur. Le deuxième développeur écrit juste assez de code pour réussir le test. Une fois le test réussi, le deuxième développeur écrit un test qui a échoué, puis renvoie l'ordinateur au premier développeur. Cette approche de va-et-vient de la programmation par paires est connue sous le nom de ping-pong .
Ces pratiques sont essentielles pour favoriser la culture de la qualité, l'amélioration continue, mais pour être mis en place, il est nécessaire de rompre avec certaines habitudes qui se sont ancrées dans l’entreprise. L’activité de développeur est encore trop souvent perçue comme une activité solitaire, ce qui provoque deux situations :
Favoriser la culture de la qualité à l’échelle de l’équipe n’est pas une chose aisée, c’est une véritable conduite du changement à mener. Une simple formation de quelques jours aux pratiques ne fera pas une équipe d’artisans aguerris. Cela prend du temps, et forcément, on ne peut pas forcer les gens à changer pour un artisanat logiciel.
Pour cela, il est utile de s’appuyer sur les personnes qui maîtrisent le mieux les pratiques, de s’appuyer sur un Tech Lead qui va aider l’équipe à progresser jusqu’à ce qu’elle devienne autonome. Et si cette personne n’est pas présente au sein de l’équipe, on peut faire appel à une personne extérieure à l’équipe, qui pourra la sensibiliser, la former, l’accompagner.
Le Clean Code ne repose pas sur des règles spécifiques à la langue. Au lieu de cela, il repose sur des principes indépendants du langage acceptés par la communauté des développeurs.
Favorisez la lisibilité. Ce n'est pas parce qu'une machine peut lire votre code qu'un autre humain le peut. En particulier, lorsque vous travaillez avec plusieurs personnes sur un projet, privilégiez toujours la lisibilité plutôt que la concision. Il ne sert à rien d'avoir un code concis si les gens ne le comprennent pas.
Cohérence de la pratique: c'est sans doute le principe fondamental de tous les principes de code propre. Si vous décidez de faire quelque chose d'une certaine manière, tenez-vous-y tout au long du projet. Si vous n'avez pas d'autre choix que de vous éloigner de votre choix initial, expliquez pourquoi dans les commentaires.
Le « développement piloté par les tests » fait référence à un style de programmation dans lequel trois activités sont étroitement imbriquées : le codage, les tests (sous forme d'écriture de tests unitaires) et la conception (sous forme de refactoring).
Il peut être décrit succinctement par l'ensemble de règles suivant :
Nous avons fait un article plus complet sur le TDD : Test Driven Development pour des applications web de qualité.
La programmation extrême est une approche systématique avec un ensemble de valeurs, de règles et de pratiques pour développer rapidement des logiciels de haute qualité qui offrent la plus grande valeur pour les clients. XP est plus qu'une simple série d'étapes pour gérer des projets : il suit un ensemble de valeurs qui aideront votre équipe à travailler plus rapidement et à collaborer plus efficacement.
Simplicité : Les équipes accomplissent ce qui a été demandé et rien de plus. XP décompose chaque étape d'un processus majeur en objectifs plus petits et réalisables que les membres de l'équipe doivent accomplir.
Communication simplifiée : Les équipes travaillent ensemble sur chaque partie du projet, de la collecte des exigences à la mise en œuvre du code, et participent à des réunions quotidiennes pour tenir tous les membres de l'équipe informés. Toutes les préoccupations ou problèmes sont traités immédiatement.
Rétroaction cohérente et constructive : Dans XP, les équipes adaptent leur processus aux besoins du projet et du client, et non l'inverse. L'équipe doit faire une démonstration précoce et fréquente de son logiciel afin de recueillir les commentaires du client et d'apporter les modifications nécessaires.
Le respect : La programmation extrême encourage une mentalité « tous pour un et un pour tous ». Chaque personne de l'équipe, quelle que soit sa hiérarchie, est respectée pour ses contributions. L'équipe respecte les opinions des clients et vice-versa.
Courage : Les membres de l'équipe s'adaptent aux changements à mesure qu'ils surviennent et assument la responsabilité de leur travail. Ils disent la vérité sur leurs progrès - il n'y a pas de « mensonges blancs » ou d'excuses pour ne pas aider les gens à se sentir mieux. Il n'y a aucune raison d'avoir peur car personne ne travaille jamais seul.
Les aspects les plus surprenants de la méthodologie de programmation extrême sont ses règles simples. Les règles peuvent sembler maladroites et peut-être même naïves au début, mais sont basées sur des valeurs et des principes solides.
Planification: au stade de la planification, des user stories sont rédigées. Les user stories sont utilisées pour créer des estimations de temps pour la réunion de planification des versions. À ce stade, les développeurs publient fréquemment de petites versions de versions itératives du système aux clients. Et le projet est divisé en itérations. Les itérations sont prévues pour une à trois semaines.
Gestion: Cette règle exige que l'espace de travail soit ouvert et que les barrières telles que les cabines qui séparent les personnes soient supprimées. Configurer le rythme, c'est avoir le logiciel le plus complet et le plus prêt pour la production à chaque itération. Cette règle nécessite également de déplacer les gens pour éviter de graves pertes de connaissances et de coder des goulots d'étranglement. la plupart des participants ne contribuent pas, mais assistent juste pour entendre le résultat. Une grande quantité de temps de développement est sacrifiée pour gagner une quantité insignifiante de communication.
Conception: Cette règle exige que la conception d'un modèle soit simple. Un modèle simple prend toujours moins pour finir qu'un modèle complexe. Cette règle exige des solutions Spike qui servent à trouver des réponses à des problèmes techniques et de conception difficiles. Une solution de pointe est un programme très simple pour explorer des solutions potentielles. Cette règle exige également que les fonctionnalités ne soient jamais ajoutées tôt puisque seulement 10% des éléments supplémentaires seront jamais utilisés.
Codage: Cette règle exige que le client soit toujours disponible, non seulement pour aider l'équipe de développement, mais aussi pour en faire partie. Cette règle exige également que le code soit écrit selon des normes convenues. Il est requis de la règle de codage de créer le test avant de créer le code car il sera beaucoup plus facile de créer le code plus tard. La propriété collective encourage chacun à apporter de nouvelles idées à tous les segments du projet.
Test: Tout le code doit subir des tests unitaires, les tests unitaires sont les pierres angulaires de l'Extreme Programming. Lorsqu'un bogue est détecté, des tests sont créés pour éviter qu'il ne revienne. Les tests d'acceptation sont créés à partir des user stories. Au cours de l'itération, les user stories sélectionnées lors de la réunion de planification de l'itération seront traduites en tests d'acceptation.
Les clients aiment être partenaires dans le processus logiciel, les développeurs contribuent activement quel que soit leur niveau d'expérience et les managers se concentrent sur la communication et les relations. Les activités improductives ont été réduites pour réduire les coûts et la frustration de toutes les personnes impliquées.
Une question, un doute, un retour d'expérience ou un simple "coucou", nous lisons et répondons à tous vos messages.
