J’aime considérer les principes (& co) comme des guides. Ils me donnent des indications sur ce que je fais pour prendre de la hauteur. Ça m’aide à réfléchir et à me questionner. Suis-je dans une bonne direction ? Pourquoi ce principe semble m’alerter ici ? Qu’est-ce que ça va m’apporter ? De quoi ai-je besoin ? En me posant des questions, je m’assure de prendre en compte mon contexte et de m’y adapter. Je cherche aussi à bien comprendre le principe, pour qu’il me guide au mieux. Peut-être que ça ne fait pas sens de l’appliquer ici.

Un exemple avec le principe DRY (Don’t Repeat Yourself). Je viens d’écrire du code qui ressemble à un autre morceau de code ailleurs dans le projet. Le voyant DRY s’allume et me dit d’éviter la duplication. En prenant du recul, je peux me demander si c’est réellement de la duplication. Est-ce qu’ils sont dans le même domaine métier ? Est-ce qu’ils ont les mêmes raisons de changer ? À quel point est-ce identique ? Ou même, est-ce trop tôt ? Même si le principe peut m’indiquer un comportement à adopter, je prends d’abord soin de réfléchir et d’analyser mon contexte.

À l’opposé, une approche plus dogmatique des principes. On arrête de réfléchir, on ne se pose pas (trop) de questions. On applique bêtement ce que le principe nous dit. En même temps il n’y a pas à réfléchir, si le principe le dit, c’est forcément vrai. Alors on le fait. On commence même à avoir une vision binaire : je respecte ou je ne respecte pas. D’ailleurs, si je ne respecte pas, c’est évidemment mal.

En reprenant l’exemple du principe DRY, j’aurais sûrement supprimé la duplication tout de suite. Sans questionnement. Deux bouts de code qui se ressemblent ? Oula, vite ! Qu’on me supprime cette duplication ! Pourtant, il s’agissait de règles métiers de deux domaines différents. Peu de temps après, j’aurais cassé le comportement d’un des deux domaines en modifiant ce bout de code non dupliqué. Espérons qu’un test unitaire soit passé au rouge et que ce ne soit pas les retours alarmants de la prod qui auront mis en avant le problème.

Continuons de réfléchir, de creuser les principes en profondeur et de prendre en compte notre contexte. N’appliquons pas bêtement et évitons les vérités absolues.

J’ai présenté certains éléments dans mon précédent article, ici je ferais une liste plus complète afin d’avoir une vision globale et rapide de ce qu’on peut utiliser. On pourra ensuite voir les interactions entre les éléments. Individuellement, chaque ingrédient apporte un type d’information, mais ensemble, ils forment un tout et agissent sur les autres.

Les différents éléments

Domain Event / Événement

Avec les événements, on construit la colonne vertébrale. C’est ce qu’il se passe dans notre système. Les événements sont décrits par un verbe au participe passé. « Facture générée », « Commande livrée ». C’est quelque chose qui a eu lieu. C’est très important. On veut forcer les participants à penser avec des actions achevées, des changements d’état, des choses qui peuvent agir comme un déclencheur pour une autre action.

Les événements forment la base de l’Event Storming, tout tourne autour des événements. C’est compréhensible par le métier, par tout le monde. On peut raconter une histoire avec. On aura forcément les événements dans cet atelier, et on commence d’ailleurs par cette étape.

Actor / Acteur

Les acteurs interagissent avec le système, ils déclenchent des commandes. Ils initient une action qui va produire un événement. Ce peut être un utilisateur ou une partie d’un logiciel, un système. On essaie d’être assez précis avec la dénomination de l’acteur, de représenter ce qu’il est vraiment, son nom, son rôle. « Le client », « Le livreur », « Le système Y ». On utilise très souvent les acteurs car on veut visualiser qui fait quoi.

External System / Système Externe

Ce sont les dépendances. On veut visualiser ce qui est à l’extérieur de notre système, ce qu’on ne gère pas. On veut aussi voir apparaître les adhérences auxquels est soumis le système, ce qui le contraint, les goulots d’étranglement. « Le fournisseur », « Service Z ». Tout comme les acteurs, on veut voir qui fait quoi, et cette fois-ci, on a une information supplémentaire - c’est quelque chose d’extérieur.

Command / Commande

La commande est le déclencheur d’un événement, souvent une conséquence d’une action utilisateur, une prise de décision d’un acteur ou d’un système externe. On parle de l’action réalisée qui sera le déclencheur d’un ou plusieurs événements avec un verbe à l’infinitif. « Ajouter au panier ». Il n’y a pas forcément une commande sur chaque événement.

Avec les commandes, on commence à être plus précis sur le processus et on se projette également un peu dans le code.

Policy / Règle

Une Policy permet de rendre explicite une règle métier. C’est la glu qui lie un événement et une commande. Avec une Policy, on représente des commandes qui sont exécutées suite à un événement et selon une condition précise. En général, on décrit une Policy avec Lorsque ... alors ... : « Lorsque le paiement dépasse 500 €, alors il faut envoyer un SMS à l’utilisateur ».

Les Policies peuvent être présentent dans un système, qui gère cette règle lorsque l’événement correspondant se produit. Ce peut également être un humain qui agit lorsqu’un événement se passe. Par exemple, « Lorsqu’une fraude est détectée, alors il faut appeler le client ». C’est un processus humain. Dans ce cas-là, on peut ajouter un post-it acteur sur la Policy pour représenter la personne.

Read Model / Données

Il y a une nuance importante dans le nom anglais, Read Model. On va parler des données que l’on affiche et qui vont aider les acteurs à prendre des décisions. On ne parle pas des données que l’on écrit (écriture dans une base, un registre…), ces informations sont déjà indiquées dans les commandes comme « Ajouter (l’article) au panier ».

On y écrit les données principales. « Nom, Prénom, Email ». On se limite pour mettre en valeur ce qui compte réellement.

Aggregate / Agrégat

Les agrégats vont apporter une vision bien plus micro et être très proche du code. Pour paraphraser Martin Fowler, un agrégat est un regroupement d’objets du domaine qui peuvent être manipulés comme un seul objet. C’est un pattern qui vient du Domain-Driven Design.

Ce regroupement a du sens pour le métier. On préfèrera manipuler l’agrégat plutôt que chaque objets individuellement - ces objets sont cohérents s’ils sont manipulés ensemble. Dans l’exemple du e-commerce, on peut imaginer un agrégat « Panier » qui contiendrait plusieurs objets « Article » et un objet « Promotion ».

L’intérêt en faisant émerger les agrégats avant de se plonger dans le code va être de visualiser où ils se retrouvent, s’il n’y a pas trop d’événements ou commandes autour d’un même agrégat.

Hot Spot / Point d’attention

Tout au long de l’atelier, on peut marquer les désaccords, les questions, les risques, etc. Ça fait partie du modèle. On peut marquer tout ce qui s’éloigne du scénario nominal pour rester concentré. Ce seront des éléments à creuser plus tard. « Attention RGPD », « Que fait X ? », « Risque de fraude de paiement ». On veut également les visualiser pour mettre en lumière les zones d’ombres, les questions, les problèmes. On agira peut-être là-dessus suite à l’atelier.

Déclencheur temporel

Le temps est parfois aussi un déclencheur d’action. Par exemple, une sauvegarde qui doit être réalisée toutes les heures. On marquera alors simplement « Toutes les heures » sur le post-it. Ce sera le déclencheur d’une commande ou d’un événement visant à créer une sauvegarde.

Bounded Context / Contexte borné

Une fois la modélisation du système bien avancé, dessiner les Bounded Context va permettre de définir les contours des domaines et sous-domaines métiers. En les identifiant, en les explicitant, on veut faire émerger des périmètres métier cohérent, des services, des ensembles de fonctionnalités, des contextes à l’intérieur desquels les objets, les mots, le vocabulaire auront un sens important. On peut aussi visualiser comment ils interagissent entre eux.

Dans une plateforme d’e-commerce, on pourrait imaginer plusieurs contextes : le service client, le service achats, le service livraison. Le terme « client » n’a peut-être pas la même signification au sein des trois services. Peut-être même que le terme est différent, le service livraison pourrait parler de « destinataire ».

Les interactions entre les éléments

Individuellement, tous ces éléments sont simples et apportent un niveau de compréhension différent. L’acteur informe sur qui prends la décision, l’événement indique ce qu’il s’est passé.

Ensemble, ils forment un tout. Ils se complètent, et certains ont une interaction directe entre eux. Quand un acteur agit, il déclenche une commande. Quand une commande est exécutée dans un système, un événement se produit.

Je trouve intéressant de voir comment chaque élément se comporte avec les autres et ce schéma (venant d’Alberto Brandolini, le créateur), le représente bien. C’est intéressant pour la compréhension de l’Event Storming, pour modéliser, et aussi pour concevoir plus tard le logiciel.

Une commande est exécutée. « Ajouter l’article au panier ». Une décision a été prise, il y a une action, quelque chose doit se passer. Cette commande se produit dans un système. Ce peut être le nôtre, auquel cas elle agira sur un agrégat. « On ajoute un Article au Panier, on applique éventuellement une Promotion, on recalcule un prix total ». Ou ce peut être dans un système externe.

Par l’action de cette commande, le système en question génère un événement. « Article ajouté ». Cette fois-ci, ça a eu lieu, l’histoire a évolué. Il s’est passé quelque chose dans le système.

Avec cet événement, un état a changé. On peut projeter de nouvelles données « il y a 5 articles dans le panier, le nouveau prix total est de 343 euros » et les afficher dans une nouvelle interface graphique.

L’événement peut déclencher une règle, une Policy. Le système réagit à cet événement si une condition particulière est rencontrée. « Lorsque le panier contient 5 articles, alors une réduction de 20% est appliquée sur l’article le moins cher ». Une commande est alors exécutée. « Appliquer la promotion ».

Qui d’autre peut être à l’origine d’une commande ? Un acteur. « Le client » a lancé la commande « Ajouter l’article au panier ». C’est lui qui a pris la décision, qui a agi.

Une commande est donc exécutée par un acteur ou par une règle provenant d’un système. Qui produira un événement. Et ainsi de suite. La boucle est bouclée.

C’est un atelier qui peut s’utiliser dans n’importe quel domaine et pas seulement dans le monde du logiciel (même si son créateur, Alberto Brandolini, est un développeur). On pourrait modéliser le fonctionnement d’une équipe de RHs tout comme le parcours d’achat d’une application.

Les événements forment la colonne vertébrale de L’Event Storming. On parle de ce qu’il se passe dans le processus, dans le système, sur une ligne de temps. On peut le raconter, c’est une histoire. Le storytelling est un aspect très puissant de cet atelier.

C’est en plus modulable : on peut ajouter différentes étapes qui feront naître de nouvelles conversations selon le besoin. On pourrait par exemple introduire les acteurs qui agissent sur le système ou les dépendances externes. On peut s’adapter en fonction du niveau d’abstraction que l’on souhaite avoir, d’une vision très macro à une vision très micro sur un bout de logiciel.

Pour autant, l’Event Storming reste simple, ce qui le rend d’autant plus efficace - on va en retirer quelque chose à la fin. Le cadre est léger. C’est très libre, voire parfois chaotique. Et c’est très bien. Ça donne de l’espace aux participants pour faire émerger une compréhension commune.

Quand déclencher un Event Storming ?

Dès lors qu’il y a de l’incompréhension ou un besoin de s’accorder. La force de l’Event Storming est de rassembler de nombreuses personnes et de tout mettre à plat sur un mur. On va rendre l’implicite explicite et harmoniser les modèles mentaux de chacun.

Quelques autres signaux intéressants pour déclencher : on a trop de bugs, on a des zones de floues, on veut s’aligner avec un existant, on veut cartographier de la connaissance.

Plus axé conception logiciel, l’Event Storming aura également son utilité associé au Domain-Driven Design lorsque l’on souhaite découvrir des Bounded Contexts ou des agrégats, ou associé à de l’Event Sourcing pour identifier les événements.

Une animation d’Event Storming

Il y a plusieurs recettes pour animer un Event Storming. Alberto compare l’atelier à une pizza. Il y a une base avec de la tomate et de la mozza (notre ligne de temps avec nos événements). Et ensuite, on y ajoute différents ingrédients au choix (des acteurs, des commandes, des données, des règles, …), sauf quelques exceptions (ni ananas, ni table de base de données :p). Je parle de tous ces éléments et leurs interactions dans cet article.

Selon le besoin, on va donc ajouter des étapes supplémentaires. En général, on veut au moins voir qui fait quoi. On veut identifier les acteurs et les systèmes externes qui nous ajoutent des contraintes, ainsi que les problèmes.

Pour cette introduction, on composera avec les événements ainsi que les commandes, acteurs, données et dépendances. C’est une bonne entrée en la matière que j’ai vu avec Marion Lecerf et Pablo Pernot lors d’un atelier pendant la conférence School of PO ; on obtient rapidement une cartographie intéressante du système.

Libre à vous d’adapter comme vous le souhaitez. On peut ajouter ou supprimer des étapes, en rassembler certaines en une seule étape, être plus macro ou plus micro. C’est très modulable. J’y reviendrais dans un second temps.

Préparation

En amont de l’atelier, on prendra soin d’inviter toutes les personnes qui ont un lien avec ce que l’on veut faire. Si on prend l’exemple d’un logiciel, on pourrait y inviter des développeurs, des POs, des experts du métier, des collaborateurs d’une équipe externe, etc. Toute personne qui peut contribuer est la bienvenue - on veut voir l’image dans son ensemble, on veut éclaircir des zones d’ombre, il faut qu’il y ait tous les acteurs.

Second point, la salle et le matériel. Il faut réserver un grand espace, avec de grands murs. On éloignera le mobilier qui peut gêner, et on mettra à disposition une infinité de stylos et de post-its avec les bonnes couleurs. Prévoir plusieurs mètres de papier craft idéalement pour permettre d’écrire et dessiner directement dessus. Possiblement du scotch ou des ficelles. Ça fonctionne aussi à distance sur un outil comme Miro.

Les événements

Sur une ligne de temps que l’on aura tracé, les participants vont s’atteler à positionner ensemble tous les événements qui composent le processus. On construit la colonne vertébrale. C’est ce qu’il se passe dans notre système. On peut commencer par délimiter le début et la fin en plaçant le premier événement et le dernier événement du processus pour borner.

On utilise des post-its oranges. Les événements sont décrits par un verbe au participe passé. « Facture générée », « Commande livrée ». C’est quelque chose qui a eu lieu. C’est très important. On veut forcer les participants à penser avec des actions achevées, des changements d’état, des choses qui peuvent agir comme un déclencheur pour une autre action. Les événements doivent être parlant pour les experts métiers et ça tombe bien, ils sont censés être dans la pièce avec nous.

Si on a du conditionnel, on peut faire deux branches. Et si on a trop de branches, on se dit qu’il faut les mettre de côté et faire un atelier dédié afin de se concentrer sur notre branche principale. On veut se concentrer sur notre cas nominal.

On veillera à exprimer tout ce qui vient via des post-its. On veut voir émerger l’ensemble du modèle. On discutera après. Ça peut sembler chaotique mais c’est ce que l’on veut. Lors de l’atelier avec Pablo, il indiquait qu’il poussait au chaos : si ce n’est pas assez bordélique, c’est peut-être qu’il n’y a pas les bonnes personnes ou qu’il y a trop de limites.

On peut marquer les désaccords, les questions, les risques, ça fait partie du modèle. On utilise des post-its roses foncés / rouges pour ces points d’attention (les Hot Spots). Alberto n’hésite pas à marquer tout ce qui s’éloigne du scénario nominal pour rester concentré. Ce seront des éléments à creuser plus tard. « Attention RGPD », « Que fait X ? », « Risque de fraude de paiement ». On peut les positionner en hauteur pour surplomber, ou directement à l’endroit où ça fait sens, au choix.

Cette première étape peut prendre du temps, c’est normal. Les événements forment le cœur du processus. Lorsqu’on arrive à la fin, on demande à une personne de raconter l’histoire qui est modélisée. Le storytelling fait son apparition, les gens aiment écouter des histoires. On en profite pour peaufiner et clarifier le modèle si besoin. Peut-être qu’il manque une précision à un moment. Peut-être qu’il reste une zone de flou.

Les commandes

Dans notre seconde étape, on va positionner les commandes. C’est ce qui déclenche un événement, souvent une conséquence d’une action utilisateur, une prise de décision, ou d’un système externe.

On utilise des post-its bleus. La commande est décrite avec un verbe à l’infinitif. « Ajouter au panier ». Elle est placée devant l’événement sur la ligne de temps.

Les commandes peuvent être utiles pour faire émerger du bordel, surtout sur un système existant, pour aligner les connaissances. On peut trouver que la commande et l’événement sont redondants. Avec la commande, on parle de l’action réalisée par un acteur, qui sera le déclencheur d’un ou plusieurs événements. Il n’y a pas forcément une commande sur chaque événement. Avec les commandes, on se projette également un peu dans le code.

Les acteurs

Troisième étape, on positionne les acteurs. Ce sont eux qui déclenchent les commandes. Ce peut être un utilisateur ou une partie d’un logiciel. On utilise des post-its jaunes et on y marque le nom de l’acteur. « Le client », « Le livreur », « Le système Y ». L’acteur est placé sur la commande, légèrement sur la gauche.

Les données

On arrive à la quatrième étape où l’on positionne les données. En anglais Read Model. Il y a une nuance importante ici. On va parler des données que l’on affiche et qui vont aider les acteurs à prendre des décisions. On ne parle pas des données que l’on écrit (écriture dans une base, un registre…), ces informations sont déjà indiquées dans les commandes comme « Ajouter (l’article) au panier ».

On utilise des post-its verts. On y écrit les données principales. « Nom, Prénom, Email ». On se limite pour mettre en valeur ce qui compte réellement. Le post-it est placé avant l’acteur.

Ne pas hésiter à se faire une session de storytelling pour s’assurer que tout va bien, et qu’on est aligné. On peut faire des sous-groupes. Est-ce qu’on est tous d’accord ? Est-ce clair pour tout le monde ? On peut commencer à préciser. Précis mais pas exhaustif, sinon on n’en fini pas. On met davantage au propre.

Les systèmes externes

Pour notre cinquième étape, on positionnera les systèmes externes. Ce sont les dépendances. On veut voir apparaître les adhérences auxquels est soumis le système, ce qui le contraint. On utilise des post-its rose clair. « Le fournisseur », « Service Z ».

On peut à nouveau reprendre le storytelling et raconter les événements afin de s’assurer que tout est représenté comme dans la vraie vie.

Quelques détails et astuces

Ici comme ailleurs, vous verrez qu’on associe une couleur à chaque élément de l’Event Storming. Respecter ce code couleur a son importance. On veut faciliter la lecture et la compréhension lors de l’atelier, et on veut s’y retrouver facilement si ce n’est pas notre premier Event Storming (on s’enlève la charge mentale de devoir réapprendre un autre code couleur). En voici un rappel :

• Acteur en jaune,
• Agrégat en jaune clair,
• Commande en bleu,
• Données en vert,
• Événement en orange,
• Point d’attention en rose foncé / rouge,
• Règle métier en violet,
• Système externe en rose clair.

On pourrait dire la même chose de la mise en page. Si tout le monde adopte une façon unique de présenter les post-its, on améliore la lisibilité. Une bonne pratique est d’afficher le modèle des différents post-its sur le mur.

Veillez à bien espacer les post-its entre eux pour faciliter l’ajout de nouveaux post-its au fil des étapes. D’ailleurs, un classique quand on joue avec des post-its, écrivez en majuscules, en gros, et soyez concis.

Dernière précision. On peut toujours mettre un événement, un acteur ou tout autre type de post-it même si on est passé à l’étape suivante. C’est toujours le bon moment d’ajouter de l’information.

Avec quoi on repart ?

On obtient de la visibilité. L’ensemble du processus, du système est rendu visible. Il n’y a plus de zones d’ombre - ou s’il y en a, elles sont explicitement révélées. Les problèmes et les questions sont identifiés. On va pouvoir avancer sur ces sujets.

On obtient de la compréhension. On peut avoir des prises de conscience comme “je ne pensais pas que je te créais des problèmes là-bas en faisant ça” ou “je ne savais pas que tu faisais ceci”. Les participants comprennent ce qu’il se passe chez eux et chez les autres, on casse les silos. On va améliorer la collaboration.

On obtient de l’alignement. On s’est mis d’accord tous ensemble sur le modèle, sur les problèmes. Continuons d’avancer ensemble.

La suite est très modulable, tout comme l’est l’atelier. On peut imaginer un tas de choses pour travailler sur le processus :

• Voter pour le problème principal, qui pourrait devenir la priorité numéro une.
• Mettre en lumière les zones à améliorer, et travailler dessus avec le temps.
• Identifier où il peut manquer des compétences.
• Regarder le niveau de qualité dans les zones les plus importantes pour le métier.
• Travailler sur les dépendances et goulots d’étranglement.
• Simplifier le processus.
• Etc.

Pour aller plus loin, Les éléments d’un Event Storming et leurs interactions.

Merci Marion Lecerf et Pablo Pernot pour les divers échanges, et Yannick Grenzinger qui avait initié mon équipe l’année dernière :)

Ce n’est cependant pas une décision à prendre à la légère. Certaines raisons sont parfaitement justifiées, alors que d’autres peuvent nuire au projet. Pourquoi a-t-on besoin de casser une dépendance dans certains tests ? Et de quoi veut-on être indépendant ? À quoi faut-il faire attention ? C’est de tout ça dont j’ai envie de parler aujourd’hui.

Qu’est-ce qui nous pose problème ?

Commençons par le commencement. On veut savoir pourquoi rendre un test indépendant, regardons du côté des problèmes auxquels cette envie d’indépendantisme répond.

Test déterministe

Avoir des tests qui échouent sans raison apparente à première vue, c’est embêtant. Encore plus lorsque ça semble être aléatoire. Et parfois, on a un passage au rouge du jour au lendemain, ce qui nous vaut la célèbre phrase “ça marchait avant”. Un test devrait avoir une intention claire et n’avoir qu’une seule raison d’échouer. On n’a pas envie de se lancer dans une session de debug pour comprendre ce qu’il se passe.

Alors qu’est-ce qui peut bien causer ces problèmes ? Un autre test. Ce bienfaiteur qu’est le test peut en effet être une source d’ennuis pour d’autres tests. Lorsqu’on lance un ensemble de tests, l’environnement et la mémoire sont partagés entre eux. Si deux tests lisent et écrivent dans un même endroit, ils vont éventuellement affecter le résultat de l’autre. Vous voyez où je veux en venir ? Base de données, fichiers, singletons, variables globales, … Tout ça représente une zone partagée et peut créer un lien de dépendance entre deux tests.

On arrive donc à notre première et principale raison. Pourquoi rendre un test indépendant ? Pour éviter un effet de bord venant d’un autre test. C’est dans ce but que l’on va casser une dépendance envers une base de données, un système de fichiers ou un singleton. Et que l’on mettra une fausse implémentation, avec un base de données en mémoire par exemple, pour avoir un état déterministe.

C’est d’ailleurs une autre raison, être déterministe. On veut rendre un test indépendant pour obtenir toujours le même résultat. Du côté des causes, on retrouvera celles vues précédemment et on peut notamment y ajouter d’autres éléments perturbateurs comme les requêtes HTTP, la date du jour, les fonctions aléatoires (quoi de mieux qu’un bon random() pour avoir un résultat imprévisible ? :p). Ce sont des sources qu’on ne contrôle pas. Mais pour être déterministe, il faut les contrôler : on cassera alors les dépendances afin de les remplacer. Ou peut-être que l’on s’orientera vers la création de fonctions pures.

Test rapide

Ajoutons un autre problème, sinon ce n’est pas marrant. Une suite de tests lente à exécuter est assez fâcheux. Les tests unitaires nous guident dans la conception et parfois nous rattrapent lors de sorties de route. On a besoin d’un feedback rapide, et encore plus lorsque l’on pratique le TDD.

On aura une nouvelle fois les mêmes fautifs. Feraient-ils preuve d’intelligence ? On se le demande, mais en tout cas ça nous arrange puisqu’il n’y a pas de centaines de causes différentes. Principalement, tout ce qui accède au réseau, aux internets, ralentira fortement vos tests. On peut rester dans la centaine de millisecondes comme dépasser aisément la barre des secondes. C’est sûrement la source la plus lente. Viennent ensuite les bases de données et le système de fichiers. Unitairement, le temps est peut-être faible, mais quand on dézoom et qu’on regarde le cumul sur l’ensemble des tests, ça devient (trop) long.

On en vient à notre dernière raison. On veut rendre un test indépendant pour qu’il soit rapidement exécuté. Là encore, on cassera éventuellement des dépendances qu’on substituera par quelque chose répondant immédiatement.

Couper les ponts

Si on résume en une phrase, on souhaite rendre un test indépendant afin d’éviter qu’il soit affecté par les autres tests, pour être déterministe, et pour être rapide. Voilà. Ce sont les raisons principales. Pas besoin d’aller chercher plus loin et d’isoler complètement un test.

Un autre moyen d’entrevoir ces raisons est de regarder du côté des principes FIRST. Ce sont des principes pour guider l’écriture des tests, et je trouve qu’ils reflètent bien les besoins d’indépendance. On parle de rapidité d’exécution (F pour Fast), de test indépendant des autres tests (I pour Independent) et de résultat déterministe (R pour Repeatable).

Quelques mauvaises compréhensions

Maintenant que nous avons bien en tête les raisons qui motivent les tests à devenir indépendant, revenons sur quelques mauvaises compréhensions. C’est essentiel d’en parler, car il peut y avoir un impact fort : tests fragiles, maintenance lourde, démotivation des développeurs.

System Under Test

Quand on parle de SUT, on parle de SYSTEM Under Test. Ce n’est ni Class Under Test ni Fonction Under Test. C’est très important. Le système, ce peut être une fonction, ou une classe, ou un ensemble de classes et de fonctions. Peu importe, on va tester l’ensemble et tout ce qu’il y a derrière. On peut voir ça comme un module, ou une boîte noire - on teste toute la boîte depuis notre point d’entrée.

On ne cherche pas à isoler le système que l’on teste des autres classes et fonctions qu’il utilise. On rend le test indépendant, oui, mais pas la classe. On s’en tiendra aux raisons évoquées plus haut pour casser des dépendances. C’est parfaitement ok qu’une méthode que l’on teste appelle d’autres classes, qui appelleront aussi d’autres classes.

Heavy mocking

En comprenant bien ce qu’est le SUT et ce qu’il faut rendre indépendant, on s’évite au passage la sur-utilisation de mocks. On ne va pas essayer de tout isoler et donc de tout mocker.

Le problème avec les mocks, c’est qu’ils connaissent trop les détails de l’implémentation. Si on change notre implémentation (on a une meilleure idée, on fait du refactoring), on va casser les tests. Les assertions vont être fausses et c’est normal, le mock vérifie la mécanique interne.

La sur-utilisation des mocks va entraîner des problèmes en cascade : on couple les tests à l’implémentation, on a du mal à faire du refactoring, le code devient difficile à changer, le développeur se démotive, il y a moins de tests, moins de qualité, fin. Vraiment, on ne veut pas coupler les tests à l’implémentation :)

Comportement

Ça me fait une bonne ouverture pour terminer. Ce que l’on veut tester, c’est le comportement. Quand on fait des applications, c’est pour répondre à un besoin métier. C’est ça que l’on veut tester. On se limitera à enlever les dépendances gênantes pour les tests unitaires. Testez le comportement plutôt que les détails de l’implémentation.

Crédits photos : Anne Nygård, Richard Lee.

La méthode Mikado, c’est un peu la même chose. On suit un plan décomposé en plusieurs petits pré-requis pour atteindre un objectif plus grand bien précis. Sauf que ce plan, on ne l’a pas au départ mais on le construit au fil de notre avancée. Et c’est là toute la puissance de la méthode Mikado. On avance par petits pas, on expérimente, on visualise notre chemin, et on reste toujours dans un état fonctionnel jusqu’à atteindre l’objectif défini.

Je m’en sers régulièrement lors de refactoring et je trouve ça génial (n’en déplaise aux adeptes des chantiers abandonnés après 4 mois sans visibilité). La méthode m’apporte de la structure, je vois ce que j’ai à faire, j’avance par petites étapes. Rencontrer des difficultés ou des imprévus en chemin est moins problématique grâce à l’approche très itérative et expérimentale de la méthode. Je découpe les problèmes, j’essaie des solutions, je garde ce qui marche, j’annule ce qui ne fonctionne pas. Le projet est toujours dans un état fonctionnel. Je peux m’arrêter à tout moment et le livrer.

C’est très puissant pour effectuer des changements progressivement et avec rigueur dans n’importe quel domaine. Je parlais de refactoring, mais on peut effectuer tout type d’évolutions dans notre code, ou également sortir de la sphère technique en l’utilisant dans notre équipe pour modifier une organisation, ou dans notre quotidien.

La méthode Mikado

Avant de plonger profondément dans les détails, je vous propose de découvrir un exemple d’utilisation de la méthode Mikado qui parle à tout le monde pour représenter son fonctionnement.

Les grands principes

Ok. Maintenant que vous avez un exemple simple et concret d’utilisation de la méthode Mikado, nous pouvons décortiquer les grands principes au travers de cette histoire.

Avoir un objectif

On commence avec un objectif précis. Dès le départ, on sait où l’on doit aller, on a un cap. On se concentre dessus, on ne fait pas autre chose en même temps. Dans le récit précédent, le besoin était de remplacer un vieil écran par une nouvelle TV afin de regarder Kaamelott en 4K. Le résultat attendu est parfaitement clair.

Faire des expérimentations

Tout au long de notre chemin pour arriver à notre objectif, on va expérimenter. On va essayer des choses qui nous rapprochent de l’objectif. On avance par petites étapes. On cherche des solutions simples et naïves. Par exemple, on essaie de brancher directement la nouvelle TV et on voit ce qu’il se passe.

N’essayez pas de tout prévoir en avance, de faire un plan complet pour aller sur la lune. Demandez-vous ce que vous pouvez faire comme toute première étape pour avancer. Mettre le Blu-ray ? Ok, j’essaie.

Valider une expérimentation réussie

Lorsqu’une expérimentation fonctionne, on la valide. On commit, on enregistre, on garde ces modifications. Elles nous permettent d’avancer. Et si on arrête là, tout fonctionne toujours. On n’a peut-être pas terminé, mais on a avancé dans le schmilbik. J’ai acheté le Blu-ray de Kaamelott, je me suis rapproché de mon objectif final.

Annuler une expérimentation échouée

Quand une expérimentation rate, on annule. On retire toutes les modifications de notre expérimentation et on revient dans l’état précédant. On restore sur git, on remet tout en place. C’est une des clés de la méthode. Si vous ne le faites pas, vous n’appliquez pas la méthode Mikado. Pour être transparent, j’ai tenté de ne pas le faire, de prendre des raccourcis, d’aller trop vite. Je me suis perdu et cela ne m’a pas aidé.

Revenir en arrière est très puissant. On n’a pas expérimenté pour rien, on a appris des choses. On se pose des questions pour continuer. Qu’est-ce qui me bloque ? Que faut-il faire pour débloquer cette étape ? On va construire la suite de notre chemin grâce à cette expérimentation échouée et on pourra revenir sur cette étape plus tard, dans de meilleures conditions pour réussir.

Si on arrête là, tout fonctionne. Toujours. Parce qu’on garde les expérimentations qui ont réussi et on retourne en arrière lorsqu’elles échouent.

Dessiner un graphe pour visualiser

Vous ne le voyez pas en lisant l’histoire, mais un graphe a été créé et modifié au fil des expérimentations. C’est un outil essentiel dans l’utilisation de la méthode Mikado qui permet de visualiser l’avancée. On voit ce qu’on a fait, ce qu’on a tenté, ce qu’il reste à faire. On sait facilement à quel point on se situe. On pourra reprendre aisément plus tard ou se faire aider par d’autres personnes. Oui car c’est également un très bon support pour communiquer, pour expliquer ce que l’on fait, pour avoir un coup de main.

La création du graphe

Dessiner un graphe avec la méthode Mikado est très simple. On commence par écrire l’objectif tout en bas dans un double cercle.

On ajoute ensuite un cercle pour chaque expérimentation que l’on réalise, au-dessus du pré-requis précédant, et on les relie à l’aide d’une flèche. La flèche pointe vers le ou les pré-requis à effectuer au préalable - il faut d’abord acheter le Blu-ray afin de le mettre dans le lecteur.

On repère très rapidement les possibles prochaines étapes : il s’agit des pré-requis n’ayant pas de dépendance. On peut alors choisir une expérimentation et essayer.

• Si elle échoue, on ajoutera une ou des nouvelles expérimentations en pré-requis à cette étape.
• Si elle réussie, on cochera l’expérimentation. Ce qui débloquera peut-être d’autres étapes.

Bref, la démarche

Si vous avez bien compris les principes, la démarche ne devrait pas vous surprendre. C’est tout simplement l’application de ces principes coordonnés par le graphe, étape par étape. Dans le livre Mikado Method, il y a un diagramme qui représente très bien les différentes étapes à suivre. Je l’ai recréé ci-dessous.

On commence par dessiner l’objectif sur notre graphe. On essaie ensuite naïvement de trouver une solution. S’en suit une répétition de ces étapes selon le succès de l’expérimentation :

• Dès que l’on bloque ou que notre expérimentation échoue, on dessine les nouveaux pré-requis dans le graphe, on annule les modifications, et on choisit un autre pré-requis.
• Lorsque l’on réussi, on enregistre nos modifications, on commit, et on démarre avec une autre expérimentation du graphe.

On réitère toutes ces étapes jusqu’à atteindre l’objectif. Simple et terriblement efficace.

La dernière brique

On a vu une méthode qui permet de structurer des changements. Même lorsqu’il y a un grand chantier devant nous, la méthode Mikado apporte de la structure en travaillant rigoureusement par petites étapes et expérimentations. Le graphe nous guide tout le long pour arriver à notre objectif, et sert également de support pour communiquer. On ne conserve que ce qui fonctionne et on annule ce qui échoue, ce qui permet d’avoir un projet ou contexte toujours opérationnel.

Et à la fin, il reste toujours une brique Lego ou une pièce du meuble Ikea. Considérez-là comme une dernière chance d’améliorer votre travail une fois que l’ensemble est achevé :)

J’observe un nombre grandissant de discussions autour de la Clean Architecture. C’est davantage présent dans les projets, dans les souhaits, dans les échanges, dans les publications. Pourtant, je pense qu’une (trop grande) partie des personnes passe à côté de concepts essentiels et ne se pose pas les bonnes questions. Malgré la bonne intention, ça peut être dangereux. J’aimerais amorcer une prise de recul et ouvrir des questions.

Et si on prenait du recul ?

Je vois des discussions qui tournent seulement autour du pattern, du diagramme de classe. “Le Presenter fait ceci et cela. Il parle à celui-ci ou à celui-là.” Quand je demande ce qu’est la Clean Architecture, on me répond souvent en me récitant un diagramme de classe. Pas un mot sur l’abstraction, l’entrée/sortie, l’inversion de contrôle, … Et encore moins sur l’isolation du métier.

J’ai également assisté à des entretiens et des échanges avec des développeurs qui s’acharnent avec des suites de questions pour savoir si Machin va plutôt dans le Router ou Interactor ou Presenter, si c’est pas à Bidule de faire ça, et le rôle de Truc là-dedans, … Plutôt que de parler de l’esprit de la Clean Architecture, ils ne parlent que des classes.

Certaines équipes utilisent la Clean Architecture comme cadre pour empêcher les développeurs d’en sortir, en suivant un modèle à la lettre. Faire sans comprendre, sans réfléchir ne mène pas très loin. À quel point cela vaut le coup, de rendre des choses difficiles, d’ajouter de la complexité pour empêcher des développeurs de sortir des rails ? Il y a peut-être d’autres choix à explorer.

Dans tout ça, on oublie le pourquoi. On se concentre trop sur le comment. Pourquoi on l’utilise ? “C’est pour découper. C’est pour pouvoir tester.” me dit-on souvent, sans trop détailler. Oui, mais pourquoi ça devient “plus découpé”, “plus testable” ? Quels concepts y a-t-il derrière ? Pourquoi fait-on cela ?

Et si on se recentrait sur le métier ?

Le métier est la partie la plus importante du produit. Sans métier, le produit n’existerait pas, l’équipe ne le fabriquerait pas. C’est le cœur du programme et de l’entreprise. Certaines règles vont au-delà du programme. La répartition des places dans un train par exemple. Cette règle peut être présente dans plusieurs programmes différents et existe même en dehors de tout ça, dans le monde réel.

Ces règles ne dépendent pas d’un choix technique ou d’un framework, elles ne sont pas affectées par un changement technique. On change de base de données ? Pas de problème. On n’a pas encore choisi la base de données ? Pas de problème non plus. On change de framework ? Aucun souci.

Les règles devraient pouvoir changer aisément, le monde évolue constamment. On devrait les trouver et les comprendre facilement puisque c’est le cœur du programme. C’est pour toutes ces raisons qu’il est important d’apporter une grande attention sur cette brique. De la protéger de l’extérieur. De la rendre compréhensible, lisible. De la tester.

Le schéma de Clean Architecture représenté par les 4 cercles va d’ailleurs dans ce sens. On retrouve les règles métiers et les règles applicatives au centre. Et uniquement ça. Pas de framework, pas de base de données, pas d’interface graphique. Les frontières protègent les cercles à l’intérieur de l’extérieur. C’est aussi l’esprit de l’architecture hexagonale et du DDD (Domain-Driven Design).

Le métier est au centre parce qu’il est très important. Parce qu’on veut le protéger. Parce qu’on veut en prendre soin. Le reste, c’est du détail. Du détail d’implémentation.

Et si on se penchait sur les principes ?

La programmation orientée-objet a son rôle à jouer, bien plus que ce que l’on apprend souvent à l’école (vous savez, ce fameux héritage pour classifier des animaux). Certains concepts qui gravitent autour de la POO se cachent derrière la Clean Architecture et sa séparation des couches.

L’abstraction par exemple. Avec l’abstraction, on cache les détails de l’implémentation. On veut utiliser quelque chose sans savoir comment ça fonctionne derrière. On s’enlève cette complexité. Je veux enregistrer un favori sans savoir de quelle manière il sera stocké.

L’inversion de contrôle et l’injection de dépendances sont un autre exemple. Ces concepts sont présents pour renforcer les frontières, pour protéger les cercles. On veut que les cercles discutent entre eux, mais sans qu’un cercle intérieur n’ait connaissance d’un cercle extérieur. On découple. Un Use Case peut interagir avec une base de données sans que ce code ne soit à l’intérieur du cercle, de son module. Cette brique est indépendante. Ainsi, les changements autour de la base de données ne vont pas affecter le Use Case. Et c’est tout de même le Use Case qui est aux commandes, qui utilise la base de données.

On parle de modularité en programmation orientée objet. D’autres concepts sont également là. Je vous conseille de prendre le temps de les découvrir et de les comprendre. De voir comment tout cela s’articule, et d’aller au-delà de la Clean Architecture. S’ils ne vous intéressent pas, alors prenez encore plus de temps pour creuser le sujet. Mais n’en restez pas à l’application d’un pattern.

Et si on explorait plus loin ?

La Clean Architecture apporte de bonnes choses, mais ce n’est pas une silver bullet pour autant. La solution miracle n’existe pas. C’est une solution parmi d’autres. Il faut la comprendre, savoir ses forces et faiblesses, connaître ses principes, l’approfondir.

Il faut également explorer ce qu’il y a autour. L’architecture hexagonale est une approche similaire par exemple. Elle accorde beaucoup d’importance au métier, le place au centre et le protège avec un système de ports et d’adapters. Une approche simple qui se marie très bien avec le Domain-Driven Design (un tas de choses à voir là-dedans, je recommande pleinement de s’y plonger). Le Functionnal Core, Imperative Shell me semble être un autre moyen intéressant.

Et il faut garder en tête les différents principes de programmation. Ils sont toujours là, peu importe le choix de l’architecture. Ils vous accompagneront pendant longtemps.

Cherchez à comprendre et approfondissez, n’appliquez pas sans réfléchir. Soyez ouvert et explorateur, ne restez pas enfermé dans une vision unique. Et appréciez :)