Le Software Craftsmanship : une philosophie au service de la qualité de vos Application web

Conseil et stratégie

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.

 

Merwan El Attar

Édité le 3 mai 2021

Les raisons de privilégier le Software Craftsmanship pour vos applications web

Qu’est-ce que le concept de Software Craftsmanship ?

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.

  • Non seulement un logiciel de travail, mais aussi des logiciels bien conçus
  • Non seulement répondre au changement, mais aussi une valeur ajoutée constante
  • Pas seulement les individus et les interactions, mais aussi une communauté de professionnels
  • Pas seulement la collaboration client, mais aussi des partenariats productifs

Autrement dit, à la recherche des éléments de gauche, nous avons trouvé les éléments de droite indispensables. »

Son histoire

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 :

  • Les individus et leurs interactions plus que les processus et les outils
  • Des logiciels opérationnels plus qu’une documentation exhaustive
  • La collaboration avec les clients plus que la négociation contractuelle
  • L’adaptation au changement plus que le suivi d’un plan

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.

Comment ce concept s’est popularisé ?

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.

Comment appliquer le concept de Software Craftsmanship ?

Les fondements du Software Craftsmanship

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 :

  • Qualité (un logiciel conçu « simplement »)
  • Humilité (en apprendre toujours plus)
  • Partage (la notion de communauté)
  • Pragmatisme (être flexible et s’adapter)
  • Professionnalisme (considérer le client comme un collaborateur)

Les bonnes pratiques avec un exemple

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 :

  • Apprendre et transmettre les pratiques de développement via le binômage, l’organisation de dojos.
  • Garantir une propriété collective du code en organisant des revues de code par paires ou collectivement, mais aussi en évitant que chaque développeur travaille seul sur son périmètre.
  • Établir ensemble des standards de développement et les faire vivre.
  • S’appuyer sur les outils de l’intégration continue pour réduire la boucle de feedback.

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 .

Comment intégrer ces bonnes pratiques ?

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 :

  • les pratiques de développement collectives comme le binômage peuvent être perçues par les acteurs non-techniques des projets comme un surcoût conséquent alors que certaines études tendent à prouver le contraire.
  • les développeurs qui ont été habitués à travailler seuls peuvent avoir des difficultés à travailler à plusieurs, ne serait-ce que montrer leur code ou en parler. Sur cet aspect, il est nécessaire d’adopter une posture positive, d’apprendre à donner et recevoir du feedback sans pointer les autres du doigt.

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.

Les méthodes pour un code durable

Le Clean Code

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. 

  • KISS : Keep It Simple Stupid. Un principe de conception issu de l’US Navy qui remonte déjà à 1960. Il stipule que la plupart des systèmes doivent être aussi simples que possible (mais pas plus simples, comme l’aurait dit Einstein). La complexité inutile doit être évitée. La question à se poser lorsque vous écrivez du code est « cela peut-il être écrit de manière plus simple ? »
  • DRY : Ne vous répétez pas. Étroitement lié à KISS et à la philosophie du design minimaliste. Il stipule que chaque élément de connaissance (code, dans ce cas) doit avoir une représentation unique, sans ambiguïté et faisant autorité dans un système (base de code). Les violations de DRY sont appelées WET : nous aimons taper, tout écrire deux fois, gaspiller le temps de tout le monde.
  • YAGNI : Vous n’en aurez pas besoin. Un développeur ne doit pas ajouter de fonctionnalités à moins que cela ne soit jugé nécessaire. YAGNI fait partie de la méthodologie Extreme Programming (XP), qui veut améliorer la qualité des logiciels et augmenter la réactivité aux exigences des clients. YAGNI doit être utilisé en conjonction avec la refactorisation continue, les tests unitaires et l’intégration.
  • La composition plutôt que l’héritage : ce n’est malheureusement pas un acronyme. C’est un principe selon lequel vous concevez vos types sur ce qu’ils font plutôt que sur ce qu’ils sont. 

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.

Test Driven Development

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 :

  • écrire un test unitaire « unique » décrivant un aspect du programme
  • exécuter le test, qui devrait échouer, car le programme ne dispose pas de cette fonctionnalité
  • écrire du code «juste assez», le plus simple possible, pour que le test réussisse
  • « Refactoriser » le code jusqu’à ce qu’il soit conforme aux critères de simplicité
  • répéter, « accumuler » les tests unitaires au fil du temps

Nous avons fait un article plus complet sur le TDD : Test Driven Development pour des applications web de qualité.

Extreme Programming (XP)

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.

Découvrez ci-dessous le replay de notre live sur le X’Trem Programming.

Les valeurs de l’Extreme Programming

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.

La méthodologie des règles de programmation extrême

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.

Nos derniers articles

Test Driven Development pour des applications web de qualité

Écrit le 3 mars 2021 par Merwan El Attar

La phase de tests est l'une des étapes les plus importantes de tout projet de développement. Le Test Driven ...
Conseil et stratégie

Agence web : comment bien la choisir pour ses projets ?

Écrit le 19 novembre 2020 par Merwan El Attar

Choisir une agence web n’est pas toujours simple. Les principaux critères de choix sont : La compétence ...
Conseil et stratégie

Application métier : levier d’une transformation digitale efficace

Écrit le 16 décembre 2020 par Merwan El Attar

L'émergence des applications métiers n'est pas anodine. Dans une ère digitale, comment simplifie t-elle vos ...
Conseil et stratégie