Road to Senior

Techniques & Méthodologies pour progresser dans l’IT

Anthony Cyrille
This book is for sale at http://leanpub.com/roadtosenior-fr

This version was published on 2023-06-11

This is a Leanpub book. Leanpub empowers authors and publishers with the Lean Publishing
process. Lean Publishing is the act of publishing an in-progress ebook using lightweight tools and
many iterations to get reader feedback, pivot until you have the right book and build traction once
you do.

© 2023 Anthony Cyrille

Contents

1 Road to Senior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Attention . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

2 Algorithmes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.3 Sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

3 Clean Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.3 Sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

4 Refactoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.3 Sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

5 Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.3 Sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

6 Tests Automatisés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.3 Sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

7 Test-Driven Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.3 Sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

8 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
CONTENTS

8.2 Motivations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.3 Sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

9 Domain-Driven Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.3 Sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

10 Agile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.3 Sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

11 Craftsmanship . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
11.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
11.2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
11.3 Mots Clés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
11.4 Sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

12 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
12.1 Aller plus loin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
12.2 Liens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1 Road to Senior
1.1 Introduction
Ce document recense une liste de sujets sur lesquels travailler afin de construire son chemin vers
la séniorité. Ils représentent mon propre parcours, mes propres lectures et mon propre ressenti du
marché, et sont donc un avis purement subjectif. Mais mon expérience des entreprises françaises
(et également internationales) me conforte dans l’idée que si aujourd’hui, il est facile pour moi de
trouver du travail et des missions, ce n’est certainement pas grâce aux technologies que je maîtrise
mais grâce à mes acquis fondamentaux.
En effet, si on résume mes compétences de surface :

• Je sais bidouiller en C et en C++

• Je peux faire un peu de Java, notamment sur Android
• J’ai une très bonne expérience en JavaScript & TypeScript, mais je ne connais que React &
React-Native
• J’ai fait quelques années de PHP, surtout du Symfony

Je connais très peu de frameworks. De nom, je peux citer Rails, Django, Spring Boot et .NET, mais
je n’ai d’expérience dans aucun d’entre eux.
Malgré mon expérience limitée, on me propose des missions et des offres. Car lors de l’entretien,
la discussion me permet de mettre en avant ma maturité technique et ma connaissance de tous les
concepts que j’aborde dans cet e-book :

• Le Clean Code
• Le Refactoring
• Les Patterns
• Les Tests Automatisés
• Le Test-Driven Development
• L’architecture logicielle
• Le Domain-Driven Design
• Le DevOps

S’il existe beaucoup d’autres sujets et de techniques intéressantes, c’est souvent autour de ces
principes là que tourne la grande partie des discussions techniques.
Road to Senior 2

1.2 Attention
Il y a beaucoup de références, de livres, de concepts et de principes. De quoi intimider un développeur
qui n’a jamais entendu parler de tous ces termes.
Il n’y a aucune obligation à les connaître tous ni à maîtriser chacun de ces principes. Dans de
bonnes conditions, tous se développent naturellement au fil des années. Il y a dans cet e-book des
connaissances que j’ai accumulées en pas moins de 5 ans de recherche et de curiosité personnelle,
car très peu d’entreprises pratiquent ne serait-ce qu’un dixième de ces principes.
Aujourd’hui, ma mission est de faciliter la transmission de ces connaissances et d’en banaliser l’usage
au sein des entreprises à l’intérieur de laquelle la technologie représente une part significative.
2 Algorithmes
2.1 Introduction
Les algorithmes nous viennent des mathématiques, et ce sont les algorithmes qui sont à l’origine
même de l’informatique que nous connaissons aujourd’hui. L’algorithmie est la science de la
résolution de problèmes et de l’élaboration de processus qui permettent d’arriver à un résultat.
On les retrouve partout :

• Trouver le chemin le plus rapide entre votre maison et votre lieu de travail
• Décider de quelles publications afficher sur votre fil d’actualité
• Récupérer uniquement les utilisateurs inscrits après une date fixe
• Trier un inventaire d’objets selon la masse des éléments
• Afficher des produits similaires à un produit pour faire du cross-sell

La bonne nouvelle, c’est que les fondamentaux algorithmiques n’ont pas bougé depuis plus de 60
ans.
On utilise aujourd’hui encore et toujours les mêmes structures de données et les mêmes algorithmes
au quotidien :

• Les Tableaux (Arrays)

• Les Listes Chaînées (Linked Lists)
• Les Piles et les Files (Stacks & Queues)
• Les Graphes
• Les Arbres Binaires (Binary Trees)
• Les Tas (Heap)
• Les Algorithmes de Tri
• Les Algorithmes de Recherche
• Les Algorithmes de Transformation

Et d’autres encore.
Algorithmes 4

2.2 Motivation
Peu importe votre métier, du moment que vous êtes lié de près ou de loin à l’IT, vous serez confronté
aux algorithmes. Si vous êtes développeurs, vous serez vous-même créateurs d’algorithmes.
Et la différence entre un algorithme et un autre peut représenter des millions d’euros d’économies à
une Entreprise.
Plus encore, étudier les algorithmes développe en vous une autre vision des choses, beaucoup plus
large et plus profondes. Cela vous permet de concevoir des solutions mieux architecturées et plus
flexibles sur des problèmes du quotidien.
Les Files sont souvent utilisés dans le cadre de JobQueues dans lesquels on planifie des tâches à faire
dans un autre Thread, ce qui permet de réduire le temps de réponse d’une requête et d’avoir un
contrôle plus granulaire d’une tâche en particulier.
Les Graphes sont très pratiques pour modéliser des relations entre des personnes ou entre des
produits afin de faire des suggestions à l’utilisateur en un temps très réduit.
Connaître et comprendre ces algorithmes vous permettront de les implémenter, de les optimiser ou
simplement d’utiliser des implémentations déjà prêtes à l’emploi.
L’avantage, c’est que les Algorithmes & les Structures de Données sont les sujets les mieux
documentés et référencés sur Internet. Des milliers de vidéos, d’articles et de repositories sont
disponibles gratuitement, ainsi que des centaines de sites de compétitions et des forums d’entraides
avec une communauté souvent très active.

2.3 Sources
• A Common-Sense Guide to Data-Structures & Algorithmes, Jay Wengrow
• Cracking the Coding Interview, Gayle Laakmann McDowell
• LeetCode
• NeetCode
3 Clean Code
3.1 Introduction
Coder proprement, c’est tout un art. Rien n’est plus essentiel que d’avoir un code qui soit structuré,
agréable à lire et facile à modifier, car le but d’un programme est avant tout d’être lisible par les
autres, et dans un second temps d’être modifiable.
Même si la communauté est fragmentée sur le sujet (sur quel sujet ne l’est-elle pas ?), il existe un
grand nombre de règles que les “pères fondateurs” de l’ingénierie logicielle appliquent et défendent,
notamment sur :

• Les conventions de nommage

• La responsabilité des fonctions
• La taille des classes et des fichiers
• Les commentaires
• Les tests
• etc

3.2 Motivation
Beaucoup de développeurs pensent coder proprement. D’autres encore ne voient pas l’intérêt
d’écrire du code propre car, tant que ça marche, pourquoi s’embêter ?
Pourtant de plus en plus d’entreprises veillent à avoir des développeurs capables d’écrire du code
qui permettra à l’entreprise de continuer à évoluer et de maintenir sa productivité sur le long terme.
Car le code sale est l’une des raisons principales qui mènent à des refontes et à de longs freeze qui
font perdre beaucoup aux business.
Les recruteurs techniques sont très regardants de la façon de coder, c’est donc un fondamental à
acquérir au plus tôt.

3.3 Sources
• Clean Code, Robert C. Martin
• Code Complete, Steve McConnel
• A Philosophy of Software Design, John Ousterhout
• Summary of Clean Code 1
1 https://gist.github.com/wojteklu/73c6914cc446146b8b533c0988cf8d29
4 Refactoring
4.1 Introduction
La refactorisation, c’est changer le code sans en changer le comportement observable. La fonction
et le résultat restent le même, seule la structure du code a évolué.
Il y a plusieurs raisons de refactoriser du code :

• Réduire la complexité d’un morceau de code

• Faire émerger des concepts qui étaient implicites
• Arranger le code après avoir terminé de travailler dessus
• Adapter le code aux changements structurels de l’application

4.2 Motivation
La refactorisation est un des meilleurs outils pour lutter contre l’entropie logicielle car il permet de
soigner le code et de conserver sa flexibilité au fil du temps. Si les entreprises sont si peu regardantes
de la pratique, c’est parce qu’on attend des développeurs qu’elle fasse partie de leur travail quotidien.
Nul besoin d’expliquer à son boss qu’on a besoin de temps pour améliorer la qualité de son code car
il vous répondra “mais pourquoi ne pas l’avoir codé proprement dés le départ ?”
Savoir refactoriser est, pour les mêmes raisons que le Clean Code, une technique fortement négligée.
Selon un sondage réalisé auprès de 59 développeurs, 66% d’entre-eux ne refactorisent pas ou très peu
leur code. Seulement 6% le font constamment.

4.3 Sources
• Refactoring de Martin Fowler
• Working Effectively with Legacy Code, Michael Feathers
5 Patterns
5.1 Introduction
Un pattern est une solution à un type de problème que l’on peut rencontrer dans tout type
d’applications. Il peut s’agit de méthodes pour construire des objets, pour gérer des hierarchies
de classe perpendiculaires de façon extensible ou bien de régir la communication entre deux objets.
D’autres classes de patterns vont répondre à des problématiques d’intégration (Integration Patterns),
d’autres à des problèmes très métiers (Analysis Pattern) et encore d’autres à des problématiques
d’applications lourdes (Enterprise Application Architecture Patterns).
Les patterns aident à avoir un vocabulaire commun pour discuter de ces problèmes mais également
à reconnaître d’un coup d’oeil la solution employée pour les résoudre. En regardant un code qui
emploie un pattern tel que l’Observer Pattern, on sait tout de suite que la classe peut émettre des
évènements ou réagir à des évènements par exemple.

5.2 Motivation
Les patterns aident énormément à alléger la complexité d’une application. Une fois maîtrisés, ils
réduisent considérablement la charge cognitive à la compréhension d’une partie du programme.
Quand on reconnait un pattern, on sait immédiatement comment fonctionne le code et on passe
moins de temps à l’analyser.
De plus, les patterns aident grandement à découpler les différentes parties du code. On peut ainsi se
concentrer sur une partie du problème sans penser aux autres.
Maîtriser les patterns, c’est faire preuve d’une grande maturité en temps que programmeur. Car
cela implique de les avoir pratiqué, d’avoir résolu de véritables problèmes avec et d’être capable de
repérer quand les utiliser. De plus, un bon programmeur sait également quand NE PAS utiliser un
pattern dans une situation qui va rendre le code plus compliqué qu’autre chose.

5.3 Sources
• Design Patterns, GoF
• Patterns of Enterprise Application Architecture, Martin Fowler
6 Tests Automatisés
6.1 Introduction
La puissance de l’informatique réside dans sa capacité à automatiser des tâches qui sont pénibles
pour l’homme. L’une de ces tâches est de tester une application.
Les tests automatisés viennent en renfort et soulagent les personnes responsables de garantir la
qualité de l’application (QA). Ces tests sont de préférence écrits avant le code (Test-First) et sous
forme de tests d’acceptance permettant de valider le bon comportement du programme. Ils sont
couplés à des tests d’intégrations visant à tester le fonctionnement du système avec des systèmes
externes (base de données, services tiers) et de tests end-to-end qui valident les branchements et
s’assurent que le code est exécutable depuis le client jusqu’au fond de l’application.

6.2 Motivation
Rares sont les entreprises aujourd’hui qui ont des procédures de tests automatisés. Cependant, les
décisionnaires semblent de plus en plus réceptifs à l’idée d’adopter la pratique. Les promesses sont
lourdes :

• Réduire le nombre de régressions

• Stabiliser la vélocité de l’équipe
• Simplifier la compréhension du code
• Donner confiance aux développeurs lors des déploiements
• Augmenter la productivité de l’équipe et la stabiliser sur le long terme

De plus, il est difficile pour beaucoup d’entreprises de rajouter des tests sur un programme existant.
Maîtriser cette compétence, c’est devenir un atout majeur pour les boîtes qui sont prêtes à faire la
transition.
Mais c’est aussi un bon moyen de rejoindre des boîtes qui ont déjà une pratique quotidienne des tests
automatisés, des boites dans lesquelles il semble faire bon vivre, en tout cas mieux que dans d’autres
entreprises qui pressent la livraison de features et acceptent de passer une partie considérable de
leur temps à résoudre des bugs.

6.3 Sources
• Unit-Testing, Principles Practices & Patterns - Vlad Khorikov
• Dependency Injection, Principles Practices & Patterns - Steven Van Deursen & Mark Seeman
• Continuous Delivery - David Farley
7 Test-Driven Development
7.1 Introduction
Le Test-Driven Development, c’est l’art de développer en étant guidé par les tests. C’est donc une
méthode de développement.
Le principe est de commencer par écrire un test qui échoue (Red Light), d’écrire du code destiné
à faire passer ce test (Green Light) et puis enfin de refactoriser pour remettre au propre. C’est la
boucle Red-Green-Refactor.
C’est une technique qui donne des résultats prodigieux :

• Tout le code est testé

• Les tests étant écrits en premier, le code est structuré pour être testable et donc découplé
• C’est une méthode incrémentale et itérative qui permet de découper un gros problème en
plusieurs petits problèmes (Divide & Conquer)
• C’est une technique qui peut permettre de découvrir des algorithmes très optimisés qu’on ne
suspectait pas de prime abord
• C’est une bonne façon de designer son code (Programming by Wishful Thinking)

7.2 Motivation
Si peu de boîtes pratiquent les tests automatisés comme une discipline vitale au bon fonctionnement
d’un projet, qu’en est-il du TDD ? Malheureusement, elle l’est encore moins.
Mais là aussi, de plus en plus d’entreprises se réveillent et se mettent à accepter cette pratique.
Seulement, il y a trop peu de programmeurs qui sont capables de faire du TDD proprement. De plus,
beaucoup d’entreprises y mettent la bonne volonté mais prétendent faire du TDD alors qu’elles font
en réalité du Test-First voire pire, du Test-Last. Corriger le tir permet de se révéler comme étant un
atout important pour ces entreprises.
Il s’agit donc de viser non pas la masse des entreprises qui ont le monopole des candidats (océan
rouge) mais plutôt celles qui cherchent desespérément des profils expérimentés dans ces pratiques
(océan bleu).

7.3 Sources
• Test-Driven Development by Example - Kent Beck
• Growing Object-Oriented Software, Guided by Tests
8 Architecture
8.1 Introduction
L’architecture est un sujet très vaste dans l’IT. Ce qui nous intéresse le plus ici, c’est l’architecture
logicielle : l’art d’organiser les différents composants d’un programme.
Ce qui nous intéresse, c’est de reconnaître ces composants, d’être capable de les créer, de les organiser
et d’être conscient des dynamiques et des relations entre ces composants. Et par composant, on
entend simplement un regroupement de fonctions ou de classes, de préférence avec un thème
commun qui garantit leur cohésion.
Les principes SOLID sont les principes les plus fondamentaux en ce qui concerne l’architecture de ces
composants. Les maîtriser aide grandement à maintenir un système qui soit modulaire et découplé,
un système dans lequel l’ajout de fonctionnalités ou la modification de règles existantes est simple
et localisée.

8.2 Motivations
Aucun développeur ne peut durablement devenir un Senior sans avoir acquis et maîtrisé l’art
d’architecturer une application, que ce soit depuis la base ou bien sur un projet existant. Le
but premier d’une architecture étant de garantir la productivité des développeurs, le rôle d’un
développeur-architecte est de travailler continuellement sur cette architecture pour en remplir le
but.
Un développeur conscient de ces enjeux et capable d’en discuter et de prendre des décisions ne
restera pas junior bien longtemps. Il se révèlera être un élément critique car il sera capable d’une
grande autonomie et on pourra lui accorder une grande confiance pour faire évoluer le système et
travailler sur des fonctionnalités de plus en plus importantes.
Les principes de la Clean Architecture, bien que difficiles à maîtriser, sont parmi les plus essentiels
à l’acquisition d’une maturité d’architecte.

8.3 Sources
• Clean Architecture, Robert C. Martin
• Fundamentals of Software Architecture, Mark Richards & Neal Ford
• Ma formation sur la Clean Architecture1
1 https://clean-architecture.ancyr.fr
9 Domain-Driven Design
9.1 Introduction
Le Domain-Driven Design est une approche du développement logiciel qui met l’expert métier au
centre du processus de développement. L’équipe de développement est en constante collaboration
avec ces experts, et tous les partis prenant échangent avec un même vocabulaire.
Tout le code reflète au mot près le langage utilisé par les experts du projet, de telle sorte à ce qu’un
technophyte puisse comprendre et se retrouver dans les parties du code qui sont à haut niveau (plus
métier et moins techniques).
Le DDD a vocation à être utilisé dans des applications qui modèlent des problèmes riches en règles
métier et en complexité métier.

9.2 Motivation
Le DDD reste très peu utilisé en France car c’est un des sujets les plus complexes à maîtriser,
mais aussi les plus riches. Tirer parti des enseignements du DDD, c’est créer un code beaucoup
plus explicite (qui met en évidence les règles métier) et beaucoup plus expressif (qui en réduit la
complexité).
C’est également s’offrir une palette d’outils très pratiques pour résoudre certains problèmes spéci-
fiques. Dans beaucoup d’applications, il y a des parties beaucoup plus complexes à représenter en
code que d’autres. Le DDD contribue à alléger cette complexité.
Enfin, les outils du DDD responsabilisent le développeur qui s’intéresse véritablement aux problé-
matiques du métier et pas seulement à la partie technique du projet. C’est un atout important pour
renforcer la confiance entre l’équipe de développement et les clients.

9.3 Sources
• Implementing Domain-Driven Design, Vernon Vaughn
• Domain-Driven Design Distilled, Vernon Vaughn
• Learning Domain-Driven Design, Vladimir Khononov
• Domain-Driven Design, Eric Evans
10 Agile
10.1 Introduction
Le manifeste de développement logiciel agile, signé par 17 éminent profils de la bulle IT, est un
mouvement qui propose une façon de développer des logiciels en opposition avec la méthode
Waterfall. Là où les principes Waterfall sont très orientés processus, planification, estimations et
gros travail d’architecture en amont, l’Agile se concentre sur des phases d’itérations courtes, une
capacité collective à gérer le développement du projet (sans management) et un véritable contact
avec le client final.

10.2 Motivation
Beaucoup d’équipes et de projets prétendent faire du Agile et du Scrum mais passent à côté de
l’essence même de l’Agilité. C’est d’ailleurs ce qui a mené au développement du Craftsmanship.
Il y a donc beaucoup à apprendre du développement agile et plus précisément de son ancêtre,
l’Extreme Programming. Son objectif est celui qui a poussé les entreprises à devenir agile : itérer
sur des courtes durées, tester des idées, récolter un feedback de l’utilisateur le plus vite possible.
Cependant, obtenir ce résultat demande de maîtriser une bonne partie des connaissances que l’on a
vu plus haut.

10.3 Sources
• Extreme Programming Explained, Kent Beck
• Clean Agile, Robert C. Martin
• User Stories Applied, Mike Cohn
11 Craftsmanship
11.1 Introduction
Un Craftsman est une personne qui prend sa profession au sérieux et qui met du coeur à l’ouvrage.
Il se sent responsable de la réussite du projet et considère qu’il est de son devoir de maîtriser à la foi
son art et ses outils.

11.2 Motivation
Si le sujet porte à débat, les pratiques du craftsmanship sont toutes riches de sens et proposent de
travailler d’une autre façon que celle du rush constant et des compromis. De nombreuses études
semblent pourtant indiquer que ces pratiques séparent très largement les équipes performantes de
celles qui le sont moins.
Toutes les pratiques énoncées jusqu’ici convergent vers cet absolu : c’est parce que l’on utilise des
méthodologies comme le Clean Code, le Refactoring, les Patterns, le TDD… le tout appuyé sur une
batterie de tests automatisés en laquelle l’équipe a confiance, que l’on peut tirer parti des pratiques
du DevOps et accélérer le développement du produit. Cette approche holistique du développement
logiciel vise pour objectif un niveau de productivité maximale.

11.3 Mots Clés

• Broken Window
• Katas
• Software Entropy
• Orthogonality
• Design By Contract
• Test-Driven Development
• Continuous Integration

11.4 Sources
• Modern Software Engineering, David Farley
• The Pragmatic Programmer, Dave Thomas & Pete Hunt
• Clean Craftsmanship, Uncle Bob
12 Conclusion
Wow, ça fait vraiment beaucoup de concepts. C’est à se demander par où commencer.
Le document est plutôt bien organisé : on peut commencer par étudier et maîtriser le premier
chapitre avant de passer au suivant, du début jusqu’à la fin.
Autrement, on peut aussi piocher et travailler plusieurs en parallèle. L’avantage, c’est que chacun
de ces points permet de mieux comprendre les autres dans un cercle vertueux. A mesure que l’on
maîtrise un point, il devient plus simple de comprendre les autres. Prenez n’importe lequel et vous
verrez.
Le plus important, c’est d’y aller pas à pas et de veiller à bien valider les acquis. Vous aurez certaine-
ment besoin de recouper les informations, de comparer et d’échanger avec d’autres développeurs.
N’hésitez pas à me joindre sur LinkedIn ou sur Discord.

12.1 Aller plus loin

Si vous êtes déjà une machine et que vous voulez aller encore plus loin, les sujets suivants peuvent
vous intéresser :

• La Programmation Fonctionnelle
• L’Event-Driven Architecture
• Les Monolithes Modulaires
• Les Microservices
• L’Event-Sourcing
• Le CQRS
• Les Domain-Specific Languages
• Le Serverless
• Le NoSQL
• Le NewSQL
• Le System Design

12.2 Liens
• Profile LinkedIn1
1 https://www.linkedin.com/in/anthony-cyrille/
Conclusion 15

• Discord Privé2
• Ma newsletter3
• Formation Clean Architecture4

2 https://discord.gg/cchpGeKxBk
3 https://flw.sh/ancyrweb
4 https://clean-architecture.ancyr.fr/