SOFTWARE

CRAFT

SOFTWARE

CRAFT

[nom]

et autres pratiques essentielles

[nom]

CTO et co-fondateur d’Arolla

Arnaud Thiéfaine

Développeur, coach craft et formateur chez Arolla

Dorra Bartaguiz

Développeuse, coach technique et formatrice chez Arolla

Fabien Hiegel

Développeur chez Shodo Nantes

Houssam Fakih

CTO de La Combe du Lion Vert

Illustration de couverture : Dhujmontra – Shutterstock

NOUS NOUS ENGAGEONS EN FAVEUR DE L’ENVIRONNEMENT :

Nos livres sont imprimés sur des papiers certifiés pour réduire notre impact sur l’environnement.

Le format de nos ouvrages est pensé afin d’optimiser l’utilisation du papier.

Depuis plus de 30 ans, nous imprimons 70 % de nos livres en France et 25 % en Europe et nous mettons tout en œuvre pour augmenter cet engagement auprès des imprimeurs français.

Nous limitons l’utilisation du plastique sur nos ouvrages (film sur les couvertures et les livres).

Dunod, 2025

[adresse]

[lien]

ISBN [téléphone]

TABLE DES MATIÈRES

Note sur la seconde edition ............................................................................................ IX

Avant-propos ................................................................................................................... XI

PARTIE 1

Les pratiques incontournables du craft

1 Le Développement Dirigé par les Tests (TDD) ......................................................... 2

• Une technique pour programmer efficacement des fonctionnalités complexes............................................................................ 2
• Les principes et les étapes du TDD..................................................................... 3
• Rigueur nécessaire à chaque étape..................................................................... 5
• Anatomie d’un test.............................................................................................. 6
• Autres conseils sur les tests................................................................................ 8
• TDD en pratique sur un kata très simple............................................................. 8
• Conclusion.......................................................................................................... 20 2 Techniques et principes de propreté de code (Clean Code) ................................ 22
• Programmer comme un exercice de communication........................................ 22
• L’importance d’être exemplaire......................................................................... 23
• Principes essentiels pour un code lisible et évolutif.......................................... 24
• Des commentaires à consommer avec modération.......................................... 34
• Ne pas se répéter (DRY).................................................................................... 37
• La propreté de code aussi pour les tests.......................................................... 38
• Conclusion.......................................................................................................... 39 3 Les spécifications agiles avec le développement dirigé par le comportement (BDD) ....................................................................................40
• Les 3 amigos (tres amigos)................................................................................ 41
• Des rôles complémentaires.............................................................................. 41
• 3+ amigos.......................................................................................................... 42
• Les ateliers de spécifications............................................................................ 42
• Exemples concrets............................................................................................ 43
• Des exemples exprimés dans le langage du métier.......................................... 43
• Après les ateliers de spécifications.................................................................... 46

VI · Table des matières

• Automatisation des scénarios............................................................................ 47
• Un effort, beaucoup de bénéfices..................................................................... 51
• Techniques complémentaires........................................................................... 52
• Démarrer BDD.................................................................................................. 54 4 Collaborer efficacement avec le pair & mob programming ................................ 56
• Le binômage (pair programming)....................................................................... 56
• Comment binômer ?.......................................................................................... 57
• Styles de binômage........................................................................................... 58
• Motivations pour choisir de binômer................................................................. 64
• La vie à deux...................................................................................................... 66
• Le mob programming (ou ensemble programming).......................................... 72 5 L’importance des techniques de refactoring ......................................................... 75
• Transformer le code pour l’améliorer.................................................................. 75
• Le code : une matière en perpétuelle transformation....................................... 76
• Le refactoring comme antidote de la dette technique....................................... 76
• Les freins au refactoring.................................................................................... 77
• Un principe fondateur : exprimer l’intention...................................................... 78
• Principes méthodologiques de refactoring........................................................ 78
• Patterns de refactoring : la boîte à outils............................................................ 79
• Refactoring vers des design patterns................................................................ 84
• Combinaison de patterns................................................................................... 85
• Situations nécessitant du refactoring............................................................... 86
• Situations impropres au refactoring.................................................................. 86
• Refactorer aussi le code de test...................................................................... 87
• Conclusion....................................................................................................... 88 6 Travailler avec du code legacy .............................................................................. 89
• L’enfer du legacy................................................................................................ 90
• Apprivoiser le code legacy................................................................................. 91
• Tester le code legacy......................................................................................... 94
• Rendre testable le code legacy....................................................................... 104
• Refactorer le code legacy.................................................................................110
• Pour aller plus loin : l’approche scratch refactoring...........................................113
• Pour aller plus loin : l’approche d’amélioration marginale..................................113
• Conclusion........................................................................................................114 7 Étude détaillée du kata Fraction ............................................................................115
• Pourquoi les fractions ?.....................................................................................115
• Présentation du kata Fraction...........................................................................116
• Premier exercice : implémentation sans contraintes.......................................116

Table des matières · VII

• Décomposition.................................................................................................118
• Exploration........................................................................................................119
• Découpage...................................................................................................... 120
• Second exercice : implémentation avec l’approche TDD.................................. 122
• Les quatre règles de design simple appliquées au kata.................................. 135

PARTIE 2

Techniques avancées et élargissements

8 Principes et outils pour tester efficacement ..................................................... 139

• Les caractéristiques des tests : les tests unitaires F.I.R.S.T............................. 139
• Doublures de tests (test double)..................................................................... 142
• Types de tests, au-delà des tests unitaires...................................................... 154
• Conclusion....................................................................................................... 162 9 Outils et techniques avancées de TDD ................................................................ 163
• Baby steps et ordonnancement des tests....................................................... 163
• Styles de TDD.................................................................................................. 165
• L’idée du TDD poussée au maximum : TDD as if you meant it.........................174 10 Techniques de conception ................................................................................. 180
• Principes essentiels de conception.................................................................. 180
• Le jeu de contraintes « Object Calisthenics »................................................. 185
• Principes de programmation fonctionnelle...................................................... 192
• Code smells courants...................................................................................... 193
• Design patterns classiques comme destinations de refactorings................... 203 11 Transformations de code à caractère architectural................................... 210
• Découpler un lien navigable par une méthode de recherche............................211
• Refactorer vers une architecture hexagonale................................................... 214
• Renommer une colonne de base de données, un champ d’une requête ou une réponse d’un service................................... 218
• Évoluer progressivement vers un style réactif orienté chorégraphie.............. 218
• Rendre un service stateless.......................................................................... 226
• Rendre un service idempotent naturellement................................................ 231

VIII · Table des matières

PARTIE 3

Craft et attitudes

12 Introduire le craft dans votre contexte ............................................................ 234

• Démarrer le craft à titre individuel ou entre collègues..................................... 234
• Introduire le craft dans une organisation......................................................... 236
• Les causes d’échec du craft............................................................................ 239 13 Au-delà des pratiques, un état d’esprit ............................................................ 241
• Développer son savoir-faire.............................................................................. 241
• Cultiver son savoir-être.................................................................................... 247
• Professionnalisme........................................................................................... 254 14 Craft 2.0 ............................................................................................................. 260
• Attitudes et aptitudes....................................................................................... 260
• Le craft en contexte (big) data......................................................................... 262
• Le craft en contexte DevOps........................................................................... 263
• Le craft en contexte machine learning............................................................. 263
• Le craft en contexte cloud & serverless.......................................................... 264
• Évolution et suite du craft................................................................................ 264 15 IA et Craft ............................................................................................................ 266
• Le raz de marée de l’IA générative.................................................................. 266
• Applications de l’IA générative pour le développement logiciel...................... 269
• Techniques de prompting pour le développement logiciel............................... 271
• IA et automatisation, au cœur de nombreux paradoxes.................................. 277
• IA et enjeux de société.................................................................................... 279 16 Craft, Conception et Domain-Driven Design (DDD) ......................................... 283
• L’impact de DDD sur le craft............................................................................ 283
• L’importance du langage.................................................................................. 284
• Modéliser en code........................................................................................... 285
• Des Bounded Contexts, avec chacun son modèle métier propre................... 286 Annexe 1 : Katalogue, les katas incontournables ...................................................... 289 Annexe 2 : La bibliothèque idéale des crafters ...................................................................291 Index .............................................................................................................................. 297

NOTE SUR LA SECONDE EDITION

La première édition de ce livre a reçu de nombreux retours positifs, ce qui nous a encouragés à conserver l’essentiel du texte et à limiter les modifications au strict nécessaire, c’est-à-dire aux corrections indispensables.

Cependant, le monde a déjà changé depuis la première édition. L’intelligence arti-ficielle (IA) est soudainement devenue un sujet incontournable, suscitant à la fois des inquiétudes et des fantasmes dans nos métiers du logiciel. Nous avons donc choisi d’ajouter un chapitre spécifiquement consacré au lien entre l’IA et le craft, le chapitre 15.

En réponse à la question « Pourquoi ce livre sur le craft ne parle-t-il pas de Domain- Driven Design ? », nous avons jugé utile d’y répondre brièvement dans un petit chapitre additionnel, le chapitre 16.

Mentionnons quelques évolutions dans le monde du software craft depuis la pre-mière édition. En ce qui concerne le TDD et la conception, le livre « Tidy First? » de Kent Beck est paru. Cet ouvrage est le fruit de plusieurs années de réflexion sur le métier de développeur, par l’auteur de « Extreme Programming ». À travers une quinzaine de patterns, sortes de mini-refactorings, Kent montre comment réaliser de petits nettoyages de code qui peuvent considérablement simplifier le travail quotidien.

Concernant le Mob-Programming, le terme de ‘Teaming’ ou ‘Ensemble

Programming’ a peu à peu gagné en usage comme alternative au terme de ‘mob’ et à ses connotations négatives. De plus, des retours d’expérience ont relevé des limites sur le plan de l’inclusivité du teaming ou mob-programming, qui n’est pas adapté à certaines situations de handicap, par exemple pour les personnes autistes ou sourdes et malentendantes.

Nous tenons à remercier tous nos lecteurs et lectrices qui nous ont fait confiance et qui ont régulièrement recommandé ce livre à leur entourage. Merci de nous avoir signalé les quelques coquilles cachées dans le livre, avec un immense merci à Matthieu Bonnot et à sa vigilance, qui a lui seul les a presque toutes trouvées.

Un merci tout particulier à celles et ceux qui ont partagé des appréciations en ligne et des retours qui nous ont fait chaud au cœur !

Avant-propos

Le Software Craft est une approche de développement logiciel qui connaît une certaine popularité depuis 2009 dans le monde entier. Cette approche, désormais revendiquée par de nombreux professionnels, s’inscrit dans le prolongement des approches agiles et les complète avec les aspects d’ingénierie.

„ L’essor du Software Craft dans le monde

Chaque année des milliers de développeurs et développeuses se retrouvent lors du Global Day of Code Retreat dans 250 villes du monde pour une journée de pra-tique intensive autour d’exercices de code en simultané, durant 24 heures au total 1 .

En outre, depuis 2011, des centaines de professionnels du développement logi-ciel se retrouvent durant trois jours dans un lieu tranquille pour échanger leurs expériences en pratiquant ensemble. Les plus connues de ces conférences sans programme pré-établi, qu’on appelle ainsi des « non-conférences », sont les événe-ments SoCraTES (International Conference of Software Craft & TESting) qui existent désormais dans de nombreux pays, dont bien entendu la France 2 à l’initiative de Houssam Fakih (un des co-auteurs de ce livre). À Paris, la communauté Software

Crafters 3 créée par Cyrille Martraire (également co-auteur de ce livre) fin 2011 comp-tait en 2020 plus de 4 200 membres, dont environ 60 d’entre eux se retrouvent une soirée chaque mois pour échanger et pratiquer.

Les entreprises suivent et cherchent à adopter ces pratiques, dans une optique d’amélioration de leur processus de développement. Les compétences de Software

Craft deviennent désirables voire requises sur les CV des candidats. Les entreprises veulent sponsoriser les communautés Software Crafters. Les entreprises de ser-vices se positionnent en réponse à la demande croissante de leurs clients. L’offre commerciale est aujourd’hui bien développée avec des formations, des formules d’accompagnement en coaching ou avec des « coachs craft embarqués », avec des personnes rompues au Software Craft qui intègrent une équipe pour lui transmettre les pratiques et techniques de l’intérieur.

Même si ce livre peut sembler tardif sur ce sujet, il reste pourtant absolument d’ac-tualité, ce qui est étonnant dans une industrie où une technologie est souvent caduque après dix ans. Mais le Software Craft n’est pas une technologie de plus qu’on télé-charge, qu’on installe et qu’on apprend avec un tutoriel avant de l’abandonner au profit

• Pour en savoir plus sur cet événement annuel, rendez-vous sur le site [lien]
• Toutes les informations sur l’événement SoCraTES sont disponibles ici : [lien]
• Le site officiel de la communauté Software Crafters Paris se situe à l’adresse suivante : [lien] com/fr-FR/paris-software-craftsmanship

XII · Avant-propos

d’une autre ; c’est un ensemble d’attitudes qu’on apprend à adopter pour être plus effi-cace sur la façon d’utiliser les technologies, quelles qu’elles soient. Il s’agit d’acquérir de nouveaux réflexes, de faire le deuil de certaines illusions, de prêter attention à des enjeux qu’on ignorait ou négligeait auparavant. Il s’agit surtout de redéfinir ce qu’on appelle un « bon » logiciel. Et ce qui est remarquable avec les attitudes est qu’elles sont bien plus pérennes que les technologies sur lesquelles on les applique.

Changer sa vision du monde et sa façon de se comporter demande du temps, des efforts et un peu d’inconfort temporaire ; il faut considérer cela comme un investisse-ment avec des bénéfices persistants sur une longue période. Apprendre le Test-Driven

Développement (TDD) en Java, C#, Typescript ou dans tout autre langage consiste avant tout à adopter un état d’esprit porteur d’attitudes fondamentales et essentielles qui seront tout aussi utiles dans n’importe quel autre langage existant ou encore à inventer. Une fois les attitudes acquises, vous les appliquerez avec profit dans n’im-porte quel univers ; par exemple, vous voudrez probablement utiliser une approche similaire au TDD même sur des configurations d’infrastructures, des bases de données ou du cloud, et même dans des environnements orientés data ou machine learning.

Votre parcours vers le Software Craft consiste donc à pratiquer des techniques sélectionnées, idéalement en compagnie d’autres praticiens, en vue d’adopter de nouvelles attitudes. Pour cela, préparez-vous à être surpris !

„ Les enjeux du développement logiciel remis en question

Votre voyage dans le Software Craft commence par changer ce qui vous paraît le plus important, en prenant conscience du fait que les enjeux suivants sont parmi les plus importants aujourd’hui :

Réussir à faire fonctionner le logiciel n’est que la première étape

Working code is a low bar.

Autrement dit, un logiciel qui fonctionne, ce n’est que le strict minimum. Le vrai enjeu du développement logiciel est de rester évolutif dans la durée, c’est-à-dire per-mettre d’ajouter facilement des fonctionnalités, et de rester maintenable, c’est-à-dire permettre de changer facilement des fonctionnalités existantes.

Un logiciel n’est jamais fini et change en permanence

Un logiciel, ça change tout le temps. Si le logiciel lui-même ne s’use pas, son utilité dépend en revanche de son adéquation au besoin, et ce besoin change régulièrement.

Un logiciel n’est donc jamais fini, sauf lorsqu’il est mis à la poubelle en fin de vie.

En anglais le mot correspondant à « logiciel » est software et désigne ce qui est facile à changer, par opposition au hardware, le matériel. Pourtant, sans soin particu-lier, le code devient rapidement difficile à changer, jusqu’à parfois devenir totalement impossible à faire évoluer. C’est fâcheux et il faut alors envisager de le réécrire, ce qui est à la fois très coûteux et très risqué.

Avant-propos · XIII

Développer c’est lire et comprendre le code au moins autant que l’écrire

Conséquence du point précédent, changer du code nécessite de le lire au préalable afin de le comprendre. Dans nos métiers, le code est bien plus souvent lu et relu qu’écrit (ou réécrit), et il convient donc d’en tirer les conséquences en termes de facilité de lecture.

Définir le besoin est au moins aussi difficile que d’écrire le code correspondant

Les développeurs ont l’habitude d’attendre une expression de besoin parfaitement définie dans chaque détail. Plus précisément, ils ou elles ont l’habitude de se plaindre de ne pas avoir une telle qualité de définition du besoin, reproches adressés aux ana-lystes ou Product Owners.

Le Software Craft accepte l’idée que définir le besoin est éminemment difficile, avec comme conséquences, d’une part, que c’est un processus de découverte pro-gressive, souvent même en cours d’écriture du code, et d’autre part que c’est une démarche collective incluant ceux et celles qui écrivent le code, au côté des futurs utilisateurs et des experts du domaine.

Pas de hacker ni de virtuose

Dans les communautés Software Craft, les termes hacker et recherche de virtuosité ne sont pas en vogue. Il ne s’agit pas d’impressionner par des astuces originales que seul leur auteur comprend. Il ne s’agit pas de taper le plus vite possible au clavier. Tout au contraire, c’est la réflexion sur l’opportunité même d’écrire ou non du code, puis de choi-sir parmi les alternatives possibles qui importent et qui méritent de prendre du temps.

Il ne s’agit pas de connaître par cœur des listes entières de commandes, alors que comprendre le métier et l’avoir en tête serait nettement plus utile. Il ne s’agit pas de faire du code qui prévoit tous les cas futurs, quand on a accepté que le futur sera tou-jours plein d’imprévus et qu’on préfère la simplicité et la capacité de changer facilement.

Il ne s’agit pas de trouver, dans son coin, une solution complète et qui fonctionne du premier coup au prix d’un énorme effort cérébral, alors que le travail se fait en équipe et que les problèmes vraiment intéressants sont trop complexes pour « tenir dans une seule tête ».

„ Retour historique sur une cascade de réactions dans l’industrie logicielle

Pour bien comprendre Software Craft, il faut rappeler le contexte historique dans lequel il est apparu, à commencer par le Manifeste agile publié en 2001. Durant les années précédant ce manifeste, nombre de praticiens avaient proposé des approches ou méthodes de développement itératives, à cycle court, en accordant de l’importance à la communication entre les personnes impliquées et aux boucles de rétroaction.

XIV · Avant-propos

Si la méthode Scrum est devenue depuis la plus populaire, l’approche Extreme

Programming (XP) était la plus complète, combinant les pratiques d’organisation du travail et d’ingénierie de code dans un tout cohérent. Extreme Programming, portant en substance les germes du craft, a connu au départ un succès d’estime et continue d’avoir une grande influence.

À partir de 2001, l’agilité, principalement avec Scrum, a connu un formidable essor jusqu’à devenir l’approche de référence de l’industrie du développement logiciel. La dynamique agile était une réaction au cycle en V de moins en moins adapté face à la complexité croissante des logiciels.

À peine dix ans plus tard, l’agilité avait remplacé progressivement le cycle en V dans la gestion du cycle de développement, mais trop souvent les pratiques d’ingénierie de code avaient été négligées. Les équipes ont gagné en efficacité de production du code, mais, à défaut de techniques d’ingénierie, elles empilent du code sur du code, et cette accumulation entraîne de la souffrance car elle devient de plus en plus difficile à entretenir. Des équipes ressentent alors ce que Sandro Mancuso appelle la « gueule de bois agile » (the Agile hangover).

Certaines figures connues du développement logiciel s’en émeuvent et réagissent.

Robert C. Martin reprend le terme « Software Craftsmanship » issu du livre Software craftsmanship: the new imperative (2001, Addison-Wesley) et en fait un manifeste destiné à compléter le Manifeste agile ([lien]) :

« We have come to value:

Not only working software, but also well-crafted software

Not only responding to change, but also steadily adding value

Not only individuals and interactions, but also a community of professionals

Not only customer collaboration, but also productive partnerships

That is, in pursuit of the items on the left we have found the items on the right to be indispensable. »

En initiant la dynamique Software Craftsmanship, l’idée est de rappeler l’importance des pratiques de code, souvent négligées depuis des années. Ces pratiques et tech-niques sont celles qui permettent qu’un logiciel évolue dans la durée sans se dégrader trop vite. Pour une large part, il s’agit de redonner une seconde vie à des éléments issus de l’Extreme Programming pour compléter Scrum. De façon caricaturale, on pourrait être tenté d’affirmer que le Software Craft apporte ce qui manque à Scrum pour reconstituer un semblant de Extreme Programming. Toute inexacte et grossière que soit cette affirmation, si vous connaissez ou apprenez Extreme Programming, vous avez, de fait, déjà un engagement significatif dans le Software Craft.

On a vu que l’agilité était une réaction au cycle en V et à la rigidité des processus de développement logiciel à la fin des années 1990 ; le Software Craft est à son tour

Avant-propos · XV

une réaction à la dérive de l’agilité qui a oublié ou négligé ses racines techniques.

Ironiquement c’est donc une réaction à une réaction. À ce titre, le Software Craft est aussi affaire de marketing, avec un terme qui devient populaire pour passer des idées et donner envie de changer son comportement. Ce n’est pas honteux, c’est même utile.

„ Une communauté bienveillante et soucieuse de la transmission des savoir-faire

Notre expérience après dix ans dans des communautés Software Craft dans toute l’Europe et au-delà est de croiser des personnes ouvertes d’esprit et avec beaucoup de bienveillance. Ça fait très bisounours mais les exceptions sont rares. Lorsqu’il a été constaté que le nom même de « Software Craftsmanship » était genré au mascu-lin, la décision de renommer en a été immédiate dans la plupart des communautés.

La communauté de Paris s’est ainsi renommée en Software Crafters Paris.

En insistant sur l’excellence technique, le risque est de dériver vers l’élitisme, mais le Software Craft inclut un antidote qui est l’importance de la transmission des savoir-faire. Il s’agit non seulement de progresser soi-même vers l’excellence technique, mais d’aider d’autres, de tout niveau, à progresser aussi. Et bien entendu les deux objectifs se renforcent plus qu’ils ne s’opposent.

„ Une boîte à outils de techniques

Le Software Craft comprend bien entendu une sélection de techniques formant une boîte à outils à bien connaître et à perfectionner sans cesse. Les techniques majeures sont :

9 TDD (Test-Driven Development) ou « développement dirigé par les tests », qui n’est pas une technique de test mais bien une technique de développement et de conception, avec tous les refactorings.

9 BDD (Behavior-Driven Development) ou « développement dirigé par le comporte-ment », issu de TDD mais qui a développé un état de l’art propre, en particulier autour de l’expression du besoin.

9 Techniques dites de propreté de code (Clean Code), qui rassemblent les pra-tiques-clés pour écrire du code propre à l’échelle de la ligne de code.

9 Domain-Driven Design (conception dirigée par le métier), pour guider la concep-tion avancée et l’architecture jusqu’à l’échelle du système d’information.

9 Techniques spécifiques de « Legacy Remediation » (remaniement de code hérité), pour reprendre le contrôle, mettre sous tests et réparer du code ancien et mal entretenu.

9 Techniques de conception orientée objet (OO) et style de programmation fonc-tionnelle (FP), principes de conception SOLID, etc.

XVI · Avant-propos

9 Techniques de collaboration, en particulier le binômage (pair programming) jusqu’au mob programming (programmation en groupe), car collaborer efficace-ment cela s’apprend et se travaille.

9 Enfin, le Software Craft comprend aussi l’application et l’adaptation de tout ce qui précède pour les technologies comme le cloud, le machine learning, et les infrastructures data, qui sont plus récentes et par conséquent moins matures en termes de pratiques que la programmation généraliste traditionnelle.

Ces techniques sont décrites en détail dans les différents chapitres de ce livre, avec des exemples et exercices pour apprendre à les appliquer.

„ Comment lire ce livre

Cet ouvrage peut être lu d’un bout à l’autre comme un parcours pédagogique pro-gressif, ordonné par difficulté croissante et en commençant par les prérequis. Une approche conseillée serait de consacrer par exemple une semaine par chapitre, pour lire puis pratiquer le sujet avec les exercices proposés.

Ce parcours pédagogique reprend le contenu et la progression qui ont fait le succès du programme d’apprentissage de plus de 100 recrues de la société La Combe du Lion

Vert, créée par les mêmes dirigeants que la société Arolla où se sont connus les auteurs.

Les exemples sont donnés en utilisant un des langages de programmation les plus populaires aujourd’hui, à savoir Java, JavaScript, C# ou Typescript. Les lecteurs et les lectrices pourront extrapoler les recommandations à leur langage habituel, ce qui ne doit pas poser de problème, le Software Craft étant largement agnostique aux détails de chaque langage.

Ce livre peut aussi se consulter comme un guide de référence, organisé par chapitres thématiques, pour répondre aux interrogations et hésitations que vous ren-contrez dans votre pratique.

Chaque chapitre référence les ouvrages ou liens, le plus souvent en langue anglaise, qui seront utiles pour approfondir chaque sujet. Ce livre peut donc être vu comme une porte d’entrée vers un vaste univers, avec les conseils des auteurs pour se repérer et trouver plus vite les sources les plus inspirantes et les plus pertinentes.

„ À propos des auteurs

Cyrille Martraire

Cyrille est CTO co-fondateur d’Arolla, une société qui rassemble plus de 100 enthou-siastes du software craft. Il est aussi le fondateur de la communauté Paris Software

Crafters, qui compte aujourd’hui plus de 5000 membres, et est l’auteur du livre

Living Documentation chez Addison-Wesley. Cyrille est orateur régulier dans des conférences en Europe et au-delà.

Avant-propos · XVII

Avec plus de 25 ans d’expérience, Cyrille intervient toujours en conseil en archi-tecture et en conception, avec l’aide de Domain-Driven Design et avec une vraie curiosité pour tous les métiers, de la finance à la logistique ou au médical.

Arnaud Thiéfaine

À travers les rôles de développeur, leader technique, coach craft et formateur, Arnaud accompagne startups et grandes entreprises dans l’adoption des pratiques du software craft, en les aidant à améliorer leur code au quotidien grâce à des ateliers et un accompagnement sur mesure.

Passionné de Domain-Driven Design, il aime explorer de nouveaux métiers et comprendre leurs enjeux pour mieux aligner le code avec la réalité du terrain. Cette curiosité l’a amené à intervenir dans des secteurs variés tels que l’énergie, la réassu-rance, la finance de marché ou encore le luxe.

Engagé dans la transmission des savoirs, il partage régulièrement son expérience à travers conférences, meetups, podcasts et formations, ainsi que par la publication de ressources accessibles à la communauté. Toujours en quête d’amélioration, il s’efforce d’aider les équipes à construire un logiciel plus durable et centré sur la valeur métier.

Dorra Bartaguiz

Dorra est développeuse depuis 2007, coach technique, formatrice et actuellement

CTO d’Arolla. Elle a aussi enseigné dans une école d’ingénieurs à Paris pendant des années. Elle partage son savoir-faire en publiant des articles et en animant des confé-rences et meetups.

Au fil de son expérience, elle a acquis des valeurs autour du clean code, du craft et de l’agilité qu’elle adore partager en accompagnant des clients à travers du coaching ou des formations pour aider les équipes à mieux apporter de la valeur.

Fabien Hiegel

Fabien est un développeur passionné ; quel que soit le langage de programmation, tout est prétexte à créer et à y prendre du plaisir. Par ses diverses expériences, il a découvert et aiguisé ses pratiques du craft, notamment par des ateliers de partage et de veille collective.

En animant des communautés de pratiques, en facilitant l’internalisation de forma-tions ou encore, en ludifiant des ateliers de pratique, il espère pouvoir transmettre cette passion aux personnes qui l’entourent et les aider à apprendre les compé-tences techniques qui les font rêver.

Houssam Fakih

Houssam Fakih est un expert du développement logiciel, cumulant les rôles de CTO, organisateur de conférences, agent de carrières, coach technique, facilitateur et formateur.

XVIII · Avant-propos

Il a conçu plusieurs programmes de formations pratiques axées sur l’amélioration des compétences craft et XP.

Ces cursus intensifs sont de véritables accélérateurs de carrières pour les déve-loppeurs juniors ou en reconversion professionnelle.

Organisateur de SoCraTes-France (conférence au format forum ouvert) depuis

2015, il a également contribué au lancement de l’événement dans d’autres pays et a facilité les premières éditions au Maroc.

Conférencier, il intervient dans plusieurs conférences sur des thèmes liés à l’agilité et au craft.

„ À propos des illustrations

Les illustrations de ce livre sont réalisées par notre co-auteure Dorra Bartaguiz, ins-pirée par les idées et les échanges avec tous les auteurs.

„ Remerciements

Les auteurs se remercient mutuellement pour l’opportunité de collaborer sur cet ouvrage dans la durée, et ce dans une atmosphère amicale. Ils tiennent à remercier profondément Jean-Luc Blanc, les éditions Dunod, pour son soutien et ses encoura-gements du projet initial jusqu’au manuscript final. Leurs remerciements vont aussi à Brice Martin, pour sa relecture.

Arnaud Thiéfaine

Arnaud remercie son épouse Delphine et ses enfants Anaïs et Noémie qui ont dû porter une part des sacrifices nécessaires à l’activité d’écriture. Elles ont su être dis-crètes pendant les phases demandant beaucoup d’attention et apporter leur soutien dans les moments les plus difficiles.

Arnaud tient également à exprimer sa gratitude envers Bruno Boucard et Thomas

Pierrain pour lui avoir transmis la passion du craft en lui montrant qu’en matière de développement logiciel, une voie beaucoup plus vertueuse était possible.

Dorra Bartaguiz

Avec un bébé, l’aventure pouvait être compromise mais c’était sans compter sur le soutien et la patience de son chéri. Donc merci à lui pour tout.

Cyrille Martraire

Cyrille remercie particulièrement Yunshan son épouse, ainsi que Norbert et Gustave, qui, en plus d’être compréhensifs pour les moments où papa ne jouait pas avec eux, ont même pris goût à participer aux points de suivi vidéo avec Monsieur Blanc.

Avant-propos · XIX

Fabien Hiegel

À Houssam qui, en plus d’avoir été un binôme enrichissant, m’a inclus et retenu dans cette aventure.

Houssam Fakih

Houssam remercie J. B. Rainsberger, ses anciens collègues à la Combe du Lion

Vert et chez BISAM. Il remercie également Hadrien Mens-Pellens, Thomas Carpaye et Thomas Ployon.

Ce livre a été conçu avec la préoccupation permanente de rester accessible aux novices du craft. Nous n’avons pas l’ambition de proposer une bible exhaustive faisant référence sur le craft.

Ainsi, si vous déjà une bonne maîtrise du sujet, il se peut que vous trouviez des motifs d’insatisfaction dans nos choix de présentation.

Nous sommes conscients des multiples façons d’aborder chaque thème, même si nous n’en avons retenu qu’une, qui n’est peut-être pas votre façon privilégiée. Enfin, pour garder le texte accessible, nous avons évité de mentionner tout ce qu’il aurait été possible de mentionner pour chaque sujet, mettant parfois de côté certaines des références les plus avancées.

Même lorsque le masculin est employé, on parle de personnes indépendamment du genre. Il peut arriver que certaines formula-tions aient échappé à notre vigilance : que cela ne soit en aucun cas considéré comme une volonté de discriminer.

PARTIE 1

Les pratiques

incontournables

du craft

1 · Le Développement Dirigé

par les Tests (TDD)

Le développement dirigé par les tests (TDD), proposé par Kent Beck à la fin des années 1990, est une technique de développement au sens large, dans la mesure où son impact ne se limite pas qu’aux tests. Cette technique incontournable et cen-trale constitue un des piliers de l’Extreme Programming (XP) et du craft.

• UNE TECHNIQUE POUR PROGRAMMER EFFICACEMENT

DES FONCTIONNALITÉS COMPLEXES

Pour comprendre tout l’intérêt de cette technique, il est utile de préciser son ori-gine. Traditionnellement, lorsqu’on apprend le développement logiciel, le focus est tout naturellement en premier lieu sur l’apprentissage du langage et de sa syntaxe, avec la satisfaction de réussir à faire fonctionner le code comme désiré. Puis, petit à petit, on écrit des applications plus complexes qui nécessitent davantage de réflexion.

L’accroissement du nombre de règles de gestion à prendre en compte oblige à bien organiser un nombre élevé d’étapes de traitements. Dans de nombreux cas, on parvient à le faire mentalement, mais, lorsque le problème à résoudre dépasse les capacités de notre cerveau, il devient nécessaire de s’aider d’un bloc-notes.

Le Développement Dirigé par les Tests (TDD) · Chapitre 1 · 3

Réaliser une fonctionnalité sous forme de code consiste à en concevoir l’algorithme et imbriquer des while, des if, ajouter une clause else nécessaire pour gérer une alternative, stocker les états intermédiaires dans des variables, avant de prendre soin de vérifier les paramètres passés, sans oublier de gérer les exceptions… La multipli-cation de ces imbrications nous fait ressentir certaines inquiétudes :

9 Comment démarrer, par quel côté démarrer les développements (ou comment éviter le syndrome de la page blanche) ?

9 Comment s’assurer de ne pas oublier des détails essentiels lors du développe-ment d’une fonctionnalité ?

9 Comment savoir précisément que le développement d’une fonctionnalité est vrai-ment terminé ?

9 Comment rester concentré sur le problème à résoudre, sans se laisser distraire par des détails non nécessaires ?

Dans son livre Test Driven Development: By Example 1 , Kent Beck explique que le fait d’avoir peur est légitime quand on fait du développement. Attention, il ne s’agit pas de la peur dans le sens négatif, celle qui nous empêche d’avancer. Il s’agit plutôt de la peur qui fait réfléchir, de la peur de ne pas voir le bout de la problématique. Cette peur nous pousse à essayer diverses solutions pour découvrir laquelle est la mieux adaptée. Cette peur peut se montrer négative dans la mesure où elle risque aussi de nous empêcher de communiquer et de rechercher un feedback puisqu’on n’est pas certain du résultat. Pire encore, elle peut nous empêcher de démarrer.

Le TDD, par son aspect très encadré, se propose de réduire les peurs et frustrations.

• LES PRINCIPES ET LES ÉTAPES DU TDD

Le développement dirigé par les tests se caractérise essentiellement par le fait d’écrire le code de test avant le code de production. L’idée est de fixer l’objectif du besoin et de définir à l’avance le comportement attendu.

Dans le cercle des développeuses et développeurs, on dit souvent qu’un bon déve-loppeur est un développeur « fainéant ». Cette citation est applicable aussi à une développeuse. Le TDD vient renforcer cette idée. En effet, en appliquant le TDD, le but est d’écrire le moins de code possible tout en satisfaisant la fonctionnalité attendue.

Robert C. Martin (surnommé « Uncle Bob ») évoque ainsi les trois règles du TDD dans son blog 2 :

9 You must write a failing test before you write any production code.

9 You must not write more of a test than is sufficient to fail, or fail to compile.

• Beck, K. Test Driven Development: By Example, Addison-Wesley Professional, 2002.
• [lien]

4 · Chapitre 1 · Le Développement Dirigé par les Tests (TDD)

9 You must not write more production code than is sufficient to make the currently failing test pass.

En français, cela donne :

9 On doit écrire un test qui échoue avant d’écrire n’importe quel code de production.

9 On ne doit pas écrire plus de tests que ce qui est nécessaire pour échouer ou ne pas compiler.

9 On ne doit écrire que le code suffisant pour que le test actuellement en échec réussisse.

Le développement se fait en plusieurs itérations et chacune de ces itérations se décline en trois étapes : l’étape rouge, l’étape verte et l’étape de refactoring (en anglais : red / green / refactor). À chaque étape de l’itération, on va écrire le minimum de code pour satisfaire le besoin.

2.1 Étape rouge (red)

Lorsqu’on entreprend une nouvelle fonctionnalité en approche TDD, on écrit tout d’abord un test qui correspond au comportement attendu. Cette étape correspond à l’étape rouge, en référence à la convention employée par les IDE (pour Integrated

Development Environment) pour signifier l’échec d’un test.

À ce stade, le code de production permettant de réaliser la fonctionnalité n’est pas encore développé. Par conséquent, le test n’est pas supposé réussir. En écrivant le test avant l’implémentation, on s’assure de cadrer et diriger l’effort de développement et ne pas se disperser. Il est donc très important de vérifier que le test échoue pour les bonnes raisons en s’assurant que les données d’entrée et le résultat attendu de notre test sont pertinents et correspondent bien au besoin attendu. En cas de doute, il est souhaitable de s’en assurer avec le métier (la ou les personnes qui ont exprimé le besoin).

Le Développement Dirigé par les Tests (TDD) · Chapitre 1 · 5

Et si le résultat initial de mon test est vert ?

Il arrive parfois que le test nouvellement ajouté réussisse immédiatement, sans même nécessiter l’ajout ou la modification de code de production. En approche TDD, ce n’est pas bon signe et cela peut être dû à une des raisons suivantes :

9 le test peut être erroné : les valeurs du résultat attendu ou les données d’entrée sont fausses ;

9 le comportement attendu a déjà été développé par accident lors d’une précé-dente itération.

2.2 Étape verte (green)

Une fois que le test est écrit, nous pouvons entrer dans la deuxième étape de chaque itération du TDD, l’étape verte (ici aussi, c’est la couleur adoptée par les IDE pour indiquer que les tests ont réussi). L’idée principale de cette phase est de faire passer le test le plus rapidement possible, avec un minimum d’effort, et le minimum de code pour répondre au besoin. Bien souvent, l’implémentation est très naïve et se limite à retourner une valeur en dur.

On évite ainsi de trop réfléchir, à contre-courant de l’approche habituelle consistant à passer du temps en amont pour faire une belle conception, avant de produire un code élégant et sophistiqué. Au contraire, nous cherchons à garder un code suffisamment simple et qui apporte immédiatement de la valeur en supportant un nouveau cas métier.

2.3 Étape de refactoring (refactor)

Lors de la dernière phase de l’itération, on cherche à améliorer le code pour une meilleure lisibilité. Il peut s’agir d’un renommage de variable. Ou encore de l’extrac-tion d’un bloc de code vers une nouvelle méthode, ou bien de la création d’une nouvelle classe 1 . L’idée est d’utiliser au maximum l’environnement de développe-ment pour faire les actions de refactoring 2 , pour se prémunir des erreurs humaines et surtout éviter l’ajout d’un nouveau comportement non couvert par les tests.

• RIGUEUR NÉCESSAIRE À CHAQUE ÉTAPE

Pour chaque itération du TDD, la rigueur est de mise. Pour l’écriture du test, on s’assure de n’utiliser que les variables nécessaires. On n’initialise que des variables qui seront utilisées comme données d’entrée de notre fonctionnalité à tester. Pour la phase verte, il faut se contraindre à écrire le minimum de code. Quand on écrit une deuxième ligne de code ou rajoute une condition (un if par exemple), c’est le moment de se demander si on ne peut pas écrire moins de code.

• Il existe beaucoup d’autres techniques de refactoring, décrites en détail dans le chapitre 5, dédié à ce sujet.
• On pourrait le traduire en « refactorisation » mais le terme « refactoring » reste couramment utilisé en français.