Sallah KOKAINA Craftsmanship - fnac-static.com€¦ · L’art du code et de l’agilité technique en entreprise Au cours de ces dernières décennies, les pratiques et outils de

Soft

war

e C

raft

sman

ship

isbn

: 978

-2-4

09-0

2153

-4

Software Craftsmanship L’art du code et de l’agilité technique en entrepriseAu cours de ces dernières décennies, les pratiques et outils de développement se sont nettement transformés pour permettre à l’entreprise de livrer mieux et plus rapide-ment ses applications. Avec ces nouvelles pratiques, l’art de coder prend toute son importance. Qu’est-ce qui fait qu’un développeur est mieux formé qu’un autre ? Qu’une équipe utilise une librairie de code mieux qu’une autre ? Qu’une entreprise réalise un logiciel mieux qu’une autre ? : le Software Craftsmanship.

Rédigé comme le journal d’un aspirant à l’excellence technique, ce livre a pour ob-jectif d’initier avec consistance les développeurs ou professionnels IT aux pratiques du Software Craftsmanship qui, au-delà d’un manifeste d’excellence technique, est surtout un état d’esprit à adopter.

Agrémentée d’anecdotes, d’exercices, de convictions techniques et de restitutions diverses sur des principes clés du monde informatique, la lecture est rythmée par quatre parties qui stimulent le savoir-être, le savoir-faire, le savoir-structurer et le savoir-penser nécessaires pour une bonne conception logicielle.

Au fil des pages, le lecteur intègre ainsi la posture d’un artisan du code et découvre les compétences nécessaires pour agir en professionnel du code. Il apprend à utiliser à bon escient les outils et technologies logicielles en mode Agile, étu-die les principes de programmation clés pour créer des applications de qualité, comprend l’importance des tests dans la réalisation des projets, découvre les ingré-dients permettant de créer une architecture robuste et maintenable ou encore les réflexes à avoir pour maintenir la vitalité technique dans un modèle de déploiement continu.

Sallah KOKAINAIngénieur diplômé en informatique de l’Institut National des Sciences Appliquées de Lyon (INSA LYON), Sallah KOKAINA possède une expérience de plus de 10 ans en développement logiciel et en manage-ment de la qualité logicielle. Aujourd’hui Consultant et Expert Digital, il accompagne les entreprises dans leur transformation Agile, digitale et technique en Europe, aux USA et récemment en Afrique du Nord. En parallèle de ses activités professionnelles, il contribue au monde open source avec la création de Toast TK, un framework d’au-tomatisation de tests qui aide à améliorer la qualité des applications dans les projets Agiles, et fonde la communauté Moroccan Software Crafters qui regroupe des passion-nés du Software Craftsmanship désireux de partager leur connaissance et de contribuer à l’optimisation du niveau technique au Maroc.

Pour plus d’informations :

45 €

Sallah KOKAINA

L’art du code et de l’agilité technique en entreprise

Software Craftsmanship

+ QUIZ

1Table des matières

Avant-propos1. Remerciements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2. Avatars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Chapitre 1Savoir-être

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2. Manifeste de l'artisan codeur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.1 Élever le niveau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.2 Artisan et non pas héros. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.3 Solutions économiquement viables. . . . . . . . . . . . . . . . . . . . . . . 202.4 Savoir dire NON pour le bien de TOUS . . . . . . . . . . . . . . . . . . . 21

3. Éthique et attitude codeur responsable. . . . . . . . . . . . . . . . . . . . . . . . 223.1 Zéro Mythos - Dire ce qu’on fait, faire ce qu’on dit. . . . . . . . . . 25

3.1.1 Osez dire : « je ne sais pas ». Ça vous grandira ! . . . . . . . . 25
3.1.2 Définir ses priorités . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.1.3 Franchise et engagement . . . . . . . . . . . . . . . . . . . . . . . . . . 273.1.4 Communiquez, communiquez, communiquez . . . . . . . . 28
3.2 Respect – L’art et la manière de dire non au big boss. . . . . . . . . 293.3 Cavern – TDD face à la glace. . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.4 Le bon état d’esprit - Vous êtes une start-up . . . . . . . . . . . . . . . 35

4. Agile, feedback en continu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364.1 Rituels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.1.1 TDD, BDD, ATDD, CTDD. . . . . . . . . . . . . . . . . . . . . . . . 384.1.2 Daily Stand Up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384.1.3 Réunions rétrospectives . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.2 Réflexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394.2.1 Releases périodiques et fréquentes . . . . . . . . . . . . . . . . . . 394.2.2 Vision Client : Products Owners et utilisateurs . . . . . . . . 404.2.3 Performances en préproduction. . . . . . . . . . . . . . . . . . . . . 40

lcroise

Tampon

2
L'art du code et de l'agilité technique en entreprise

4.3 Automatisation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414.3.1 Pull Requests et revue de code . . . . . . . . . . . . . . . . . . . . . . 414.3.2 Intégration et déploiement continu . . . . . . . . . . . . . . . . . 42

4.4 Outils. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424.4.1 Debug et profiling de Code . . . . . . . . . . . . . . . . . . . . . . . . 424.4.2 Sondes à l’expérience utilisateur . . . . . . . . . . . . . . . . . . . . 42

5. Outillage Craft et DX. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435.1 IDE - Environnement de développement intégré . . . . . . . . . . . . 455.2 Encore plus d’outils . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 595.3 Bonnes pratiques pro-DX. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

6. Synthèse et exercices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 646.1 Takeaways . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 646.2 Actions et exercices pratiques . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Chapitre 2Savoir-faire

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

2. TDD, au-delà du DD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 702.1 Un cycle vertueux. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 722.2 TU et l’ironie du coût. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 752.3 Legacy : Refuse, Resist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 772.4 Chacun sa bible. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 792.5 Bonnes pratiques et anti-patterns . . . . . . . . . . . . . . . . . . . . . . . . 80

3. BDD, encore du DD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 813.1 Les origines [source] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 823.2 Communication, collaboration, documentation . . . . . . . . . . . . 843.3 Ubiquitous Language, approche outillée. . . . . . . . . . . . . . . . . . . 87

3.3.1 Cucumber - Aslak Hellesøy . . . . . . . . . . . . . . . . . . . . . . . . 883.3.2 Jasmine - Pivotal Software. . . . . . . . . . . . . . . . . . . . . . . . . 893.3.3 Robot framework - Pekka Klärck, Janne Härkönen . . . . . 90

3.4 Quelques bons réflexes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91


4. Agile Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 944.1 Agile Testing Manifesto. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 964.2 Test en Agile, de la phase à l’activité. . . . . . . . . . . . . . . . . . . . . . 974.3 Toast TK - Cultiver son ADN . . . . . . . . . . . . . . . . . . . . . . . . . . 1024.4 Quelques bons réflexes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

5. Performance et sécurité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1075.1 Security by design et by mindset . . . . . . . . . . . . . . . . . . . . . . . 1095.2 Cybersécurité - Piratage éthique . . . . . . . . . . . . . . . . . . . . . . . . 1125.3 Performances. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

5.3.1 Complexité algorithmique . . . . . . . . . . . . . . . . . . . . . . . . 1165.3.2 Gestion de mémoire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1185.3.3 Performances en JavaScript . . . . . . . . . . . . . . . . . . . . . . . 119

5.4 Performance orientée Monitoring et Programming patterns . 1235.5 Quinze healthy checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

6. Synthèse et exercices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1286.1 Takeaways . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1286.2 Actions et exercices pratiques . . . . . . . . . . . . . . . . . . . . . . . . . . 131

Chapitre 3Savoir structurer

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

2. Gestion de la dette technique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1352.1 Codes smells les plus populaires - [wikipedia] . . . . . . . . . . . . . 1372.2 Une affaire personnelle : c’est mieux quand ça sent bon !. . . . 1392.3 Une affaire d’équipe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1422.4 La quête aux KPI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144

3. Initiation au DDD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1473.1 Un jargon commun . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1493.2 Model - La base, le squelette, l’essence même. . . . . . . . . . . . . . 151

4

3.3 Instance - Donner vie au model. . . . . . . . . . . . . . . . . . . . . . . . . 1533.3.1 Langage omniprésent (Ubiquitous Language) . . . . . . . . 1543.3.2 Continuous Integration . . . . . . . . . . . . . . . . . . . . . . . . . . 156

3.4 Layer - Séparer pour mieux régner. . . . . . . . . . . . . . . . . . . . . . . 1563.4.1 Bounded context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1573.4.2 Modules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1573.4.3 Context map. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1583.4.4 Shared kernel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1593.4.5 Anti-corruption layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1593.4.6 Big Ball of Mud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160

3.5 DDD à bon escient . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161

4. Architecture propre et solide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1624.1 Principes SOLID - Martin Fowler et Robert C. Martin . . . . . . 1644.2 clean architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1724.3 Architecture Cloud : 12 facteurs de succès . . . . . . . . . . . . . . . . 1784.4 Architecture émergente : JiT, Dry, Yagni et Kiss . . . . . . . . . . . 182

5. Gestion du Legacy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1875.1 Les origines du mal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
5.2 La métaphore du toréador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1945.3 Avoir un plan et des roues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1965.4 Une histoire de trou noir . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2005.5 Bonnes pratiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202


Chapitre 4Savoir penser

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207

2. Veille techno. et non Vieille techno. . . . . . . . . . . . . . . . . . . . . . . . . . 2082.1 Veille active : open source, ami du craft . . . . . . . . . . . . . . . . . . 2102.2 Veille passive : à flux détendu . . . . . . . . . . . . . . . . . . . . . . . . . . 2122.3 Veille hybride : savoir s’entourer . . . . . . . . . . . . . . . . . . . . . . . . 214

2.3.1 Où sont les experts ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2142.3.2 Médias sociaux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2142.3.3 Meetups et conférences . . . . . . . . . . . . . . . . . . . . . . . . . . 215

2.4 Un brin d’organisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216

3. Qui est Martin Fowler ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2173.1 Jeff Bezos - Two-Pizzas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2193.2 Chris Richardson - MicroServices.io . . . . . . . . . . . . . . . . . . . . . 2203.3 Greg Young - Event Sourcing & CQRS. . . . . . . . . . . . . . . . . . . 2223.4 Michael Geers - Micro Frontends . . . . . . . . . . . . . . . . . . . . . . . 2243.5 Martin Odersky - Scala . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
3.6 Andrew Ng - Coursera & IA . . . . . . . . . . . . . . . . . . . . . . . . . . . 2263.7 Martin Fowler - MartinFowler.com . . . . . . . . . . . . . . . . . . . . . 2273.8 Ainsi que… . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
4. Craftsmanship Thinking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2294.1 Design Thinking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2314.2 MVP - Minimum Viable Product. . . . . . . . . . . . . . . . . . . . . . . . 2374.3 MVP et DX - Developer Experience . . . . . . . . . . . . . . . . . . . . . 2394.4 Pragmatisme et concentration - Keep Focus. . . . . . . . . . . . . . . 241

5. Think First, Act Last. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2435.1 Une histoire de dette technique. . . . . . . . . . . . . . . . . . . . . . . . . 2455.2 Une histoire d’APIfication du legacy. . . . . . . . . . . . . . . . . . . . . 2485.3 Une histoire de MVP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2505.4 Une histoire de reconnaissance d’image . . . . . . . . . . . . . . . . . . 251

6


7. Bonus - Craft appliqué au Machine Learning . . . . . . . . . . . . . . . . . . 2557.1 Réglage de classificateur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256

7.1.1 Métriques d’évaluation de classificateurs . . . . . . . . . . . . 2577.1.2 Gestion des collections . . . . . . . . . . . . . . . . . . . . . . . . . . . 258

7.2 Analyses difformes et classifications. . . . . . . . . . . . . . . . . . . . . 2627.3 Distributions non uniformes . . . . . . . . . . . . . . . . . . . . . . . . . . . 2637.4 Modes d’apprentissage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271

9
6
Chapitre 2Savoir-faire

Savoir-faire1. Introduction« The problem is not the amount of unexpected changes in a software project; the pro-blem is our inability to cope with them. » - The software craftsman

Bienvenue dans la deuxième partie. Vous entrez dans le second tunnel del’aventure, pour vous initier à différentes techniques d’assurance qualité, qui
vous aideront à maîtriser les besoins d’évolution logicielle. Et cela en complé-mentarité avec les boucles de feedback identifiées en première partie. Derrièreces techniques existent les éléments nécessaires pour produire du code et duproduit de qualité.
Nous mettrons ainsi l’accent sur l’importance des tests dans la réalisation dessolutions. La différence entre un produit A et un produit B, à fonctionnalitéségales, est la qualité, tant perceptible que non perceptible par le client final.

Ce principe se retrouve chez les artisans horlogers. Deux montres, d’appa-rences identiques, n’auraient pas forcément le même prix. En effet, elles ne se-raient pas architecturées, montées et testées de la même façon. Endéveloppement informatique, le Test avec un grand T est le garant d’un pro-duit de qualité.

Découvrons-les !

lcroise

Tampon

70L'art du code et de l'agilité technique en entreprise


Tant qu’à faire quelque chose, autant le faire bien !

2. TDD, au-delà du DD« Quality is not expensive. The lack of skills is what makes well-crafted software ex-pensive. TDD doesn’t slow developers down. Typing is not a bottleneck. Learning andmastering a new skill, practice, or technology is. » - Sandro Mancuso (The Software

© E

diti

ons

ENI -

All

righ

ts r

eser

ved

Craftsman: Professionalism, Pragmatism, Pride - série Uncle Bob)

Le TDD (Test Driven Development, développement et documentation par lestests) est une technique de développement où les tests sont moteurs du designapplicatif. Contrairement à ce que l’on peut parfois entendre, il ne se résumepas à la réalisation de tests unitaires ou à l’utilisation de JUnit dans le cadre deprojets Java. Mais en quoi cette distinction nous intéresse-t-elle en tant qu’as-pirants craft ?

Rappelons-nous quelques valeurs du manifeste, à savoir la capacité à réaliserdes logiciels bien conçus et l’apport constant de valeur. Ces deux aspects seplacent sous couvert d’un apport constant de qualité en matière de design eten matière de valeur produit, afin de répondre pertinemment aux attentes desutilisateurs. Le TDD y contribue !

1
7Savoir-faireChapitre 2
Avant de plonger dans différents étonnements structurant le sujet, il est op-portun de parcourir les invariants et principes clés du TDD.

– Test First : on rencontre souvent des équipes ou des entreprises qui sevantent de faire du TDD. Les tests y sont souvent rédigés, dans le cadre desprojets, pour valider du code déjà produit et non pour produire du code.Soyons justes, quand on fait du TDD, on écrit le test en premier, en phaseavec une attente produit, et ce n’est qu’ensuite que l’on écrit l’algorithmepermettant d’y répondre. L’un des bénéfices du Test First, c’est qu’il aide àaméliorer et approfondir en amont notre compréhension du besoin métieren traduisant celui-ci par des intentions de test.

– KISS and YAGNI (YAGNI – You Are not Gonna Need It, évitez l’over-archi-tecture et l’utilisation de concepts et de code dont vous n’aurez pas forcé-ment besoin) : d’un côté, la simplicité est l’un des facteurs clés du TDD. Plusnotre code est simple, plus il sera maintenable, car découpé en unitéssimples, lisibles et facilement testables. De l’autre côté, nous avons ten-dance, pour de bonnes ou de mauvaises raisons, à vouloir être proactif et uti-liser des concepts avancés en faisant appel à certains patrons de conceptiontrop tôt dans le cycle de notre logiciel. Nous utilisons alors des pratiques quin’ont pas de valeur ajoutée à ce moment. L’une des mauvaises conséquences
est l’ajout de complexité inutile. Nous introduisons prématurément unestructure technique sans valeur ajoutée pour le besoin métier exprimé.
– Refactor : sans refactor, on ne peut parler de TDD. Le refactor est souventpensé à tort dans les esprits comme étant une fonctionnalité d’Eclipse, voirIntellij pour les initiés, mais ce n’est pas cela dont on parle ici. Le refactorvient donner un sens au TDD et à l’amélioration continue de notre code,dans la mesure où cette démarche vise à modifier la forme d’un code sans enchanger le fond. Le refactor permet de changer la structure d’un logiciel pourrépondre à des exigences techniques (patterns, conventions de nommage,performance, code smells...) sans en altérer le comportement capturé pardes tests préalablement décrits.

Dans ce chapitre, nous allons voir en quoi le TDD est indispensable pour toutcraft aspirant à créer des logiciels bien conçus et à valeur ajoutée. Nous allonsdécrire le cycle type de cette méthodologie et voir en quoi il est vertueux. Onparle souvent du coût de test. Cela serait ainsi le bon moment d’apprécier ladistinction entre coûts préventifs et coûts correctifs.



Nous verrons par ailleurs en quoi cela représente la meilleure documentationpour une équipe de développement et en quoi il nous aide, en tant qu’indivi-dus et équipes de développement, à être confiants vis-à-vis de modifications.Nous finirons par identifier quelques bonnes pratiques et anti-patterns, his-toire de tirer profit de quelques bonnes bases.

2.1 Un cycle vertueux

« Refactoring is a change made to the internal structure of software to make it easierto understand and cheaper to modify. » - MartinFowler

Le Test Driven Development est une pratique de développement qui vientavec son lot de règles, articulées autour d’un cycle bien défini : on commencepar créer un test, on le fait échouer, on écrit le minimum de code pour qu’ilpasse. Ensuite, on rentre dans la boucle de refactoring.

[Add test > Run and Fail new tests > Write code > Run tests > Refactor]* - Wikipedia

© E

diti

ons

ENI -

All

righ

ts r

eser

ved

Un cycle bien rodé - Xavier Pigeon

3
7Savoir-faireChapitre 2
Le but du refactoring n’est pas d’écrire le code pour faire réussir un test ni derajouter du code issu d’une demande d’évolution ; c’est tout sauf cela. Le re-factoring vise à améliorer le design d’un code déjà couvert à l’aide d’au moinsun test unitaire, afin de le rendre plus aisé et moins coûteux à modifier. Enoutre, il permet de supprimer des codes smells (voir section Gestion de la dettetechnique au chapitre Savoir structurer), de réduire la dette technique, tout enbénéficiant de la protection du harnais de test. Les tests permettent de devenirplus confiant pour faire évoluer la base de code.

« American software engineer Kent Beck, who is credited with having developed or“rediscovered” the technique, stated in 2003 that TDD encourages simple designs andinspires confidence » - Wikipedia (https://en.wikipedia.org/wiki/Test-driven_deve-lopment)

Avec le TDD, c’est l’expérience de développement qui est au centre du sujet,bien plus que la qualité intrinsèque du code. On parle souvent d’expérienceutilisateur (UX), mais qu’en est-il de l’expérience de réalisation (DX) ? Pournous accompagner dans ce cycle, cette journey du TDD, il existe de nom-breuses librairies de code (frameworks), patterns et outils. Le sujet est en effettellement crucial que, à l’image du pionnier, Kent Benck (informaticien amé-ricain, inventeur de l’eXtreme Programming (XP) et auteur des livres de réfé-
rence sur la méthode. C’est un des signataires du manifeste Agile), avec JUnit,de nombreux développeurs et entreprises ont créé des frameworks autantpour la couche backend (ex. : TestNG), pour la couche d’accès aux données(ex. : DBUnit), que pour la couche frontend (ex. : JSUnit). Les IDE (IntegratedDevelopment Environment) sont aussi enrichis avec des plugins, ce qui améliorela productivité et rend l’expérience plus agréable.



Ainsi, histoire de rester dans les rails et dans la vertu du cycle, des patterns ontété popularisés. Kent Beck parle dans son livre, TDD by Example, de trois GreenBar Patterns (http://blog.baudson.de/blog/test-driven-development-green-bar-patterns).

© E

diti

ons

ENI -

All

righ

ts r

eser

ved

– Obvious Implementation : commencer par la solution la plus évidente.

– Fake It (till you make it) : faire passer le test le plus tôt possible même siça revient à renvoyer une simple valeur statique par l’unité à tester (UUT :Unit Under Test, le système, l’application, le module, le bloc de code ciblé pardes tests), puis avancer par petits incréments. Cette approche est générale-ment utilisée quand on a une bonne idée de l’algorithme qui sera implémen-té.

– Triangulation : confronter plusieurs cas de tests pour l’UUT. Cette ap-proche apporte du contraste et la sécurité nécessaire quand la solution àmettre en place n’est pas maîtrisée.

Puis, cerise sur le gâteau, arrive le TDD Mantra. On remarque l’utilisation dumot mantra, un terme fort pris au bouddhisme et qui place la pratique au ni-veau du culte et de la méditation continue. On a pu parler de boucle TDD etde boucle de refactoring, dont la combinaison représente une boucle de main-tenance.

Documents

Sallah KOKAINA Craftsmanship - fnac-static.com€¦ · L’art du code et de l’agilité technique en entreprise Au cours de ces dernières décennies, les pratiques et outils de