DEV Community: craft Softwr & Music

Le “Messager”: un projet pas comme les autres chez Primobox

craft Softwr & Music — Tue, 18 Jan 2022 14:41:48 +0000

Trouver une entreprise dans laquelle on peut progresser, apprendre, innover, tout en forgeant un logiciel de qualité et des compétences partageables à tout le monde, n’est pas chose courante.

Primobox est de cette trempe là.

Laissez-moi vous raconter brièvement cette aventure que j’ai eu la chance de vivre.

Genèse

Vous connaissez l’adage “Diviser pour mieux régner” ? C’est ce que nous invite à faire l’approche DDD (Domain Driven Design). Et c’est avec ce principe en tête (délimiter des Contextes Explicites et Discrets ¹) qu’un projet de Messager autonome est né chez Primobox (pour faire simple, le Messager est celui chargé de remettre le courrier à ses destinataires).

Doté d’une grande responsabilité, simple au premier abord mais qui permet d’envisager des options et des possibilités multiples, en toute autonomie.

Une fois ce domaine (contexte) métier spécifique identifié , parmi les autres besoins clients que doivent satisfaire les solutions proposées par Primobox, il était plus facile de lancer un chantier ciblé de modernisation du code.

Avec un périmètre et des relations bien définis, ce véritable “métier dans le métier” allait pouvoir prendre son envol.

Vision

Un projet réussi commence par une vision. Alexandre Fillatre, CTO chez Primobox a su initier et nourrir cette vision. Basée sur une idée simple : les différentes phases qui composent l’activité de l’offre de service chez Primobox (dématérialisation de la relation entre employés et employeurs) ont chacune une raison d’exister propre, tout en étant capable d’interagir avec les autres parties et d’évoluer de manière autonome. Alexandre nous a partagé cette vision et nous a fait confiance pour la mettre en œuvre.

Utilisateurs

En amont, un vrai travail pour comprendre le besoin utilisateur avait été initié et je l’ai traduit en éléments que nous allions mettre dans le cœur du “Messager”.

L'atelier de Wording et les User Journeys m’ont été très utiles pour cerner le domaine métier dans son ensemble et dans ses particularités.

Clarté

La clarté se gagne par l’analyse. Grâce aux travaux préliminaires de l’équipe Produit et Ergonomie, j’ai pu coucher sur le papier une carte (à la Wardley) des interactions entre le Messager et les autres éléments qui constituent la solution globale dont nos clients ont besoin.

Cela permet de savoir quelles fonctionnalités sont plus importantes, lesquelles sont annexes, lesquelles sont laissées à la responsabilité d’autres modules (existants ou à créer) voire externalisées.

Des choix stratégiques importants sur le périmètre fonctionnel ont été faits afin de réduire la charge de travail et la complexité présente sur certains produits.

Cela dessine une forme d’architecture, plus basée sur les besoins que la technique.

Cela nous libère aussi des détails techniques, car sur un Context Mapping (toujours cette notion de cartographie) se dessinent les frontières entre les Bounded Contexts; et l’on voit facilement les choix contraints par l’existant (legacy), et par ailleurs les espaces où les contraintes changent de nature. Par exemple, là où la performance est plus importante que la compatibilité.

Audace

Prendre des paris audacieux, après tout, pourquoi pas ? Pourquoi rester conforme à ce qui a été fait par le passé et se priver de progresser ?

Parlons du langage de développement. Primobox a un historique Java solidement ancré.

Moi j’arrivais du monde .Net.

Alexandre Fillatre a su discerner qu’un bon développeur ne saurait s’arrêter à une syntaxe donnée, l’essentiel étant ce que l’on sait obtenir de tel ou tel langage de développement.

La POO est une chose universelle mais les langages modernes évoluent pour être plus hydrides et flirtent plus facilement avec la Programmation Fonctionnelle. C’est le cas de C#, puis de Java qui lui a emboîté le pas.

Quitte à s’éloigner de C# 9 pour aborder la JVM, autant opter pour un langage du même niveau.

C’est là que nous avons pensé à ... Kotlin !

Etant pour ma part un adepte précoce de C# et de l’écosystème .Net, je n'avais jamais eu à me frotter au monde Java ailleurs que dans mes études. Grâce à Kotlin, franchir le cap a été pour moi d’une facilité déconcertante.

J’ai retrouvé tous mes réflexes acquis en C# avec une syntaxe encore plus élégante. Ayant l’habitude de Linq, Kotlin est naturellement provisionné pour faire la même chose. En mieux ! Et il est facile de trouver de l’aide et des exemples. Et des très bons tutos.

Arrière boutique

Ah oui, si vous cherchez des ressources sur Kotlin dans les Internets, vous verrez que ce langage est la panacée pour les applications mobiles. Et pourtant ! C’est excessivement réducteur.

Kotlin produit (aussi) du bytecode qui va tourner sur la JVM. Donc c’est un parfait candidat pour tout le code backend. C’est ce que nous avons fait pour cette application complexe, avec une architecture très évoluée, ce qui nous a permis d’être parfaitement intégré dans l’existant Java et surtout très performant.

Idiomes

Quitte à choisir un langage qui nous était inconnu (à moi et mon coreligionnaire, pur Javaiste pour sa part) jusqu’ici, autant le faire bien et complètement.

Kotlin a de multiples talents. Facile d’apprentissage, il emprunte un peu à Typescript, C#, Scala et bien sûr Java, puisqu’il produit du bytecode ciblé pour la JVM.

Son éditeur (Jetbrains) a tout fait pour que les développeurs Java s’y retrouvent, et puissent même ré-utiliser n’importe quelle classe du JDK ou n’importe quelle lib Java. Et ça fonctionne très bien. On peut même écrire du code “façon Java” (utiliser des exceptions, mettre des if en pagaille, des null partout...). \
Bref, si on n’y prenait garde, on écrirait presque du Kotlin qui ressemble à du “mauvais” Java (je veux dire par là du Java d’avant guerre, avant la version 8 si vous préférez...).

Pourtant avec Kotlin, tout est fait pour écrire du code “élégant”. J’en veux pour preuve la non nullabilité des types par défaut, l’immutabilité par défaut, la présence des data classes (équivalent des Records de C# ou Java 16) parmi tant de choses qui m’ont enchantées. \
On notera aussi que Kotlin dispose nativement de structures de données avancées (Pair, Triple, Linked List, Tree, etc...) et de possibilités de manipulation de fonctions qui sont juste délicieuses.

Et j’allais oublier de mentionner les très puissantes co-routines.

Attention

Tout au long de notre travail, une attention particulière a été portée aux autres membres de l’équipe. Nous avons communiqué régulièrement :

sur l’avancée du projet, même si nous n’avions pas de revue de sprint (on en parle plus loin), sur les innovations ou techniques que nous avions choisi de mettre en œuvre, car celles-ci pouvaient aussi trouver leur place dans d’autres projets du groupe.

Nous sommes aussi dans une démarche d’invitation permanente : tous les autres membres de la R&D peuvent venir collaborer au projet, apprendre Kotlin ou tout autre concept que nous avons mis en œuvre.

Langage Naturel

Le langage des utilisateurs et des experts métier a été le nôtre tout le long de la réalisation.

Pas de jargon de développeurs.

Notre domaine métier est en français. Toute la modélisation et le codage du logiciel se sont donc faits dans cette belle langue.

Nous avons réservé l’anglais pour les parties purement techniques (logées dans des composants isolés et accessibles via les Ports & Adaptateurs, conformément à l’architecture hexagonale exposée plus loin); par exemple la mécanique d’accès à la base de données ou au bus de message.

C’est très pratique pour se rendre compte au premier coup d'œil si notre métier (en français) reste pur et ne se mélange pas avec des considérations techniques (en anglais).

Stratégie

L'approche DDD est un guide dans la nuit. Ce n’est pas à proprement parler une méthode, et surtout pas un framework. C’est un ensemble d’outils et de bonnes pratiques, tout à fait compatible avec l’agilité et le software craftsmanship.

Nous avons eu cette approche d’emblée, dès les premières heures du projet. C’est, il me semble, la condition sine qua non pour réussir.

Comme dit précédemment, j’ai commencé par la mise en place d’une Wardley Map, puis avec Damien Boué nous avons travaillé sur des Bounded Contexts Maps. Cela nous a permis de nous synchroniser aussi avec les équipes Produit.

Tactique

En DDD la stratégie s’accompagne toujours d’une tactique, je ne vais pas vous faire ici un cours de DDD, les ressources sur Internet ne manquent pas.

Je ne vais pas vous parler ici des essentielles décompositions en agrégats, entités et value objects (chasser la Primitive Obsession).

Je vous dirai seulement qu’une des leçons que nous avons apprises est de songer sérieusement à limiter la taille de nos agrégats ! (cf ces bons conseils peu connus de Vaughn Vernon)

Jusqu’à ce qu’ils ne contiennent qu’une entité. Cette idée peut vous paraître saugrenue mais vous lui direz merci quand vous verrez la complexité accidentelle poindre son nez.

Bien sûr cela demande à réfléchir plus et surtout à ne pas se laisser entraîner par une conception basée sur le Mapping Objet Relationnel (ORM ou Objet Documents Mapping dans le cas des entrepôts NoSQL) qui, entre autres inconvénients, pousse notre modèle à être anémique. Mais aussi lorsque l'exécution de nos adapters devient concurrente (comme dans toutes les API Web), nous aurait obligé à poser des verrous transactionnels (et donc faire effondrer la performance). Cela est inévitable lorsque les agrégats sont trop gros et que l’on veut y accéder en écriture.

Donc, gardons les atomiques !

Coeur

L'une des (nombreuses) brillantes idées de ce projet a été de suivre le précepte de “Functional Core/ Imperative Shell”, introduit en 2012 dans la communauté Ruby, puis repris plus récemment par Kenneth Lange et aussi par Thoman Pierrain & Bruno BOUCARD ;

Cette approche a d’énormes avantages, citons-en 2 :

d'abord repousser les effets de bord (les fameux, ceux qui rendent vos tests trop compliqués, plus du tout isolés, voire inconsistants et cachent de nombreux bugs) en dehors des considérations métier.
corollaire : cela vous permet de vous concentrer sur la seule logique métier de manière fonctionnelle, c'est-à-dire en privilégiant l’immutabilité et la transparence référentielle.

Cette façon de penser le logiciel en y plaçant un cœur purement fonctionnel (dans les 2 sens du terme) permet d’isoler vraiment les tests métiers et donc de se passer entièrement des mocks à cet endroit.

Dans le cœur métier propre du Messager sont également apparues d’autres frontières, et donc d’autres Bounded Context pour des composants qui avaient besoin de pouvoir évoluer sans casser les autres. Tout ce travail d’isolation (via des ACL, anti corruption layers) est primordial pour ne pas s’enfermer dans une complexité accidentelle et dans ce qui devient inexorablement, malgré toute bonne volonté, une “big ball of mud” (grosse boule de boue).

Hexagone

Il y a le cœur fonctionnel, et il y a la coquille (shell en Anglais). C’est ce que l’on retrouve aussi dans les architectures hexagonales (ou Clean Architecture).

Dans la partie coquille (hors cœur métier donc) on va retrouver les ports et adaptateurs.

C’est cette philosophie que nous avons appliquée fortement.

Et nous avons fabriqué des adaptateurs techniques pour toute situation spécifique.

L'absorption de commandes venues d’une API REST est un adaptateur indépendant. Il a une dépendance directe avec les objets métiers. \
Par contre pour toute opération en base de données (nous avons, en prévision d’un CQRS séparé les opérations de lecture et celles d’écriture), il y a des adaptateurs dédiés.

Il en va de même pour les opérations d’envoi et de réception de messages dans un bus (afin de prévenir les agents dans d’autres Bounded Contexts qu’un événement important s’est passé dans notre domaine.

Qualité

TDD offre ce double avantage d’être la méthode d’écriture du logiciel (et non de test) qui nous a permis de faire du design émergent guidé par le DDD tactique et de toujours se fixer des petits pas. Et bien sûr, on obtient une couverture de tests très satisfaisante, puisqu'aucune ligne de code ne devrait être écrite si elle n’est pas justifiée par un test.

Kotlin (encore lui !) vient avec une géniale librairie : Kotest. Attention à ne pas faire comme moi au début, de faire la confusion entre KotlinTest et Kotest.

C’est bien Kotest qui permet de choisir parmi moult styles de tests, il y en a vraiment pour tout le monde : style Behaviour Driven Development (celui que nous avons choisi), style Scala, Ruby, Cucumber ou JavaScript/TypeScript. Ou ce bon vieux JUnit.

Écrire des tests, c’est bien joli, mais encore faut-il s'assurer qu’ils servent à quelque chose et qu’ils sont robustes.

Les outils déjà en place pour les autres projets Java de l’entreprise (Jenkins, SonarQube,un scanner de vulnérabilité des dépendances) se sont parfaitement intégrés à notre nouveau projet Kotlin.

La Couverture de code a pu donc être constamment mesurée, mais j’en dirai plus au prochain chapitre.

D’autres outils sont venus renforcer cette recherche de qualité :

ArchUnit, pour vérifier en permanence le bon usage des dépendances et vérifier que nous ne cassions pas les principes de l’architecture hexagonale.
Gatling pour s’assurer que notre solution tient la charge en situation réelle

Rigueur

Un grand enjeu de la qualité logicielle semble être la couverture de code, mais cette mesure peut s’avérer erronée, comme je le prouve dans ma présentation sur les tests par mutation de code.

Dans ce projet, il nous a paru opportun de consolider notre approche TDD, parce qu’après tout nous sommes tous faillibles, et qu’un outil qui nous montre que nous manquons de tests, que des bugs sont encore présents, est tout simplement une aubaine.

Nous avons choisi la lib PiTest, qui fonctionne sur le ByteCode Java, et donc très bien avec Kotlin.

Simple d’usage, facile à ajouter à un pipeline d’intégration continue, cet outil va nous aider à mieux coder et mieux tester (l’un ne va pas sans l’autre). Il nous a rappelé sans faillir aux règles du TDD (ne pas écrire une instruction qui ne soit justifiée par un test).

Par contre, il est avisé d’utiliser ce genre d’outil sur du nouveau code plutôt que sur du legacy, et de cibler du code purement métier, c'est-à-dire au centre (functional core) de l'architecture hexagonale.

Paradigme (changement de)

Ce n’est pas chose facile que de bousculer (un peu) les habitudes des développeurs. Alors que la programmation orientée objet est maîtrisée par tous mes collègues, je leur ai fait la proposition de parier sur l’immutabilité.

L’immutabilité, c’est quoi ? Une idée qui nous vient de la programmation fonctionnelle mais qui s’applique très bien à la POO. Le principe est simple : quand les objets ne “mutent” pas (comprendre : ne changent pas d’état) alors ils sont plus facile à maîtriser, à comprendre et surtout on évite beaucoup, beaucoup de bugs car on limite grandement les effets de bord dans les méthodes de ces objets immuables.

Mieux encore, cette immutabilité est facile à obtenir avec des langages tels que Kotlin (celui que nous avons choisi pour ce projet) ou même Java (à partir de la version 8 le mot clé _final _est apparu, et il a été ensuite complété avec des librairies qui poussent une vraie immutabilité des objets, comme par exemple https://www.baeldung.com/immutables).

Elle permet de transitionner naturellement vers une écriture de code plus “fonctionnelle” c'est -à -dire avec une meilleur répartition des responsabilités (voir chapitre suivant), et une plus grande intégrité référentielle.

Solide

Notre attention s'est focalisée sur la production d' un code SOLID. Ce n’est pas facile de vous parler des principes d’un code SOLID, surtout que cela fait partie de la grande famille du code “propre” (Clean Code). Le premier principe est peut être le plus important et le plus simple à comprendre : Simple Responsibility. Et tous les autres en découlent. Nous avons toujours cherché dans ce projet à exprimer et répartir les responsabilités de façon très claire et très cohérente entre les différents modules.

Que ce soit dans le découpage métier (Bounded Contexts, DDD Stratégique) ou dans l’approche technique (Archi Héxagonale DDD Tactique), notre objectif a tout le temps été de limiter la responsabilité à un niveau minimal et acceptable, afin de mieux séparer et isoler ces responsabilités. Les cartes CRC nous ont aussi beaucoup aidé à y voir plus clair dans notre design.

Découplé

Le découplage est un fondamental à la fois de l’architecture d’un logiciel mais aussi de la journée ordinaire d’un développeur. Il s’agit simplement de ne pas accumuler la complexité et les interactions douteuses qui peuvent se loger dans le code. Pour cela nous avons fait le choix d’abstractions pour définir et maîtriser ces fameuses dépendances.

L’idée est d’exprimer simplement les choses en termes de “quoi” et non de “comment”.

Exemple : au lieu de dire à notre code “je veux une base de données Mongo pour stocker des informations”, nous avons établi une abstraction (interface) qui dit “je veux pouvoir stocker cette information”. Le “comment” ne nous intéresse absolument pas.

En se référant à cette abstraction ( “Je_veux_stocker_information_X” ), nous voilà libres de son implémentation. Et c’est double bénéfice.

D’abord nous pouvons choisir librement l’implémentation et en changer à tout moment au cours de la vie du projet (nous avons choisi Mongo DB mais peut être que ce choix sera remis en cause).

Et surtout, pendant les tests fonctionnels, nous n’avons pas l’obligation de mettre en route la fameuse base de données Mongo que nous avons choisie pour la production. Nous pouvons juste utiliser un fake, c'est-à-dire une implémentation naïve, simpliste.

Evenementiel

Une autre grande force de ce projet est que nous avons d’emblée pris en compte la nature événementielle d’une application. Dans un logiciel, il se passe des choses.

Il est plus important de capturer des évènements que d’enregistrer l’état des objets.

Malheureusement, trop d’applications sont développées en mode CRUD (Create Read Update Delete), aidé (mais pas dans le bon sens) par les framework de mapping ORM. Ce mode de développement rend compliqué toute migration fonctionnelle, car justement il est difficile de placer des règles métiers quand on pense que tout se limite à des opérations d’ajout/modification/suppression/lecture en base de données.

En pensant événements, on est au contraire ouvert à tout ce qui peut se passer comme vérifications, contraintes, évolution du métier. On est bien plus proche des actions des utilisateurs.

On peut créer des programmes plus aptes à répondre au besoin métier, et moins coincé dans une solution technique.

En pratique, nos agrégats métiers émettent des événements, en réaction à des commandes, après avoir opéré les vérifications métier qui s’imposent. Nous avons mis en place un mécanisme de remontée automatique des événements (event bubbling) depuis les entités filles qui composent un agrégat global (grâce à ReactiveX et ses Observables).

Partage

Cela a été une discussion intéressante (parmi tant d’autres) : Comment s’y prendre pour se partager le travail et le partager avec les autres ? Bien sûr il y a l’usage de l’attirail Jira, Git, Jenkins... Mais ce qui importe c’est surtout la façon dont on s’en sert.

Nous avons opté pour des ADR dans les points clé de notre repository, afin de garder trace de nos discussions et de remettre en contexte les choix tactiques opérés dans le code.

Nous avons aussi mis l’accent sur le pair programming. Mais nous avions quand même voulu garder les Code Reviews, pour prendre de la hauteur sur le code produit (essentiellement par Damien Boué et moi même). Je suis plus partisan du Trunk Based Development, mais en adoptant des tests plus longs à exécuter comme le Mutation Testing, il était intéressant d’isoler tout nouveau code dans une branche dédiée afin de voir s’exécuter correctement toute la lignée de tests, sans compromettre la branche principale (on aurait pu faire du TCR mais c’est un peu violent).

Nous avons plutôt opté pour des Short Lived Branch avec des règles du jeu : pas plus de 2 branches différentes en simultané et ne portant pas sur les mêmes "zones" du code.

Au bout d’un moment, nous avions assez d’abstractions (branching by abstraction) pour éviter des “rebase” douloureux.

Bien sûr, quand nous avions à faire des refactoring qui touchaient plusieurs endroits du code, il fallait d’abord solder toutes les branches en cours, avant de s’attaquer à des modifications qui auraient eu trop d’impacts sur l’architecture ou les interfaces fondatrices.

Pour éviter que les refactoring ne durent trop longtemps et ne conduisent à des réconciliations de code houleuses, j’ai recommandé d’adopter la méthode Mikado, afin, une fois de plus, de progresser par petits pas, de merger très très souvent, de ne pas se lancer dans des travaux d’Hercule, et de se rendre compte des problèmes au plus tôt.

Le refactoring devient également plus aisé en adoptant la méthode "parallel change” ou “expand and contract” : on ne casse pas l’existant; on implémente dans une nouvelle méthode ce qui doit être refactoré, et petit à petit on transite vers le nouveau code, avant d’effacer l’ancien quand il n’est plus utilisé nulle part.

Encore une fois, l’architecture hexagonale, avec son découplage maximum, nous a permis de minimiser la casse.

Je suis très content d’avoir travaillé comme cela, car les revues de code nous ont permis de se poser la question “est ce que notre design reste cohérent” à chaque étape de la construction du logiciel.

Agilité

Il était important d’avoir du feedback rapide même sur un produit qui n’est pas encore mis en exploitation. Nous avons opté pour un travail en flux type Kanban, avec des jalons variables qui étaient matérialisés par des Minor Releases, selon nos désidérata et contraintes.

Nous avons pu compter sur une Intégration Continue (CI/CD) super efficace grâce au soutien de l’équipe DevOps en place.

Résultat

Le projet n’est pas encore terminé, et vous n’en verrez pas une démonstration graphique, car ce n’est qu’un composant au milieu de tant d’autres. Mais comme il va devenir un maillon fort de l’édifice logiciel de Primobox, c’est la fiabilité, la rapidité et la performance de produits qui vont s’en trouver renforcées. Ainsi que la maîtrise technique des équipes R&D.

Exemplaire

Ce qui est d’emblée visible ce sont les métriques d’un code de qualité, tel que peut nous les montrer Sonarqube. Et pour moi c’est une grande fierté d’avoir contribué à ce projet.

Notes

Discret au sens mathématique du terme : qui est clairement délimité, séparé, isolé. ↩

Pourquoi les tests End to End sont réellement un enfer (et ne sont qu'illusion)

craft Softwr & Music — Fri, 05 Feb 2021 21:49:44 +0000

C'est un peu mon dada depuis des lustres cette affaire; et la source de discussions très animées avec mes pairs. La pomme de la discorde? A vous de me dire...

Je ne peux cesser de l'affirmer pour l'avoir vécu de l'intérieur:
les tests End 2 End, E2E pour les intimes, sont un véritable enfer.
Un enfer pavé de bonnes intentions.
Une facilité qui se transforme très vite en handicap.

Une solution vers laquelle on plonge d'autant plus facilement quand on fait du quick & dirty, croyant que les tests bout en bout sont assez pour s'assurer du bon fonctionnement de ce qu'on livre.

Une solution trompeuse, pour ceux qui ne veulent pas faire du test unitaire et du TDD.
Un mirage pour ceux qui pensent que développeurs et testeurs ne font pas le même métier et doivent être dans des équipes distinctes (quoi que, quel est le vrai métier du tester agile? c'est une question qui fait débat également).

C'est pareil que le sucre dans l'alimentation: bon, pas cher, se trouve partout, et procure du plaisir.
Mais ca rend obèse et diabétique!
Et quand vous y avez goûté, le piège se referme sur vous.

Pourquoi?

D'abord, pourquoi en écrire, de ces fameux tests de bout en bout?
Plusieurs arguments en leur faveur:

Parce que je pense tout vérifier pour pas cher

Un test qui vérifie en une seule passe ma base de données, mon code métier, mon IHM, les services tiers, mon broker de message, mon infrastructure... Plus on est de fous, plus on rit. Mais viendra ensuite le temps de la grimace!

Parce que je ne sais pas faire autrement

Ah oui, quand on a enfin la maîtrise de Selenium, qu'on y a passé tellement de temps: on se dit qu'on a plus le temps de faire du TDD. Donc on arrête d'investir et d'apprendre.

Parce que tout le monde fait ça

C'est un peu comme dire que, puisqu'il y a autant de gens qui croient que la terre est plate, alors c'est que forcément elle l'est.
Ca fonctionne aussi pour faire croire que les résultats d'une élection ont été volés. Bref 🤨
Ca ressemble étrangement à un biais de confirmation, voir à un effet de foule.

Allons un peu plus loin, pour voir...

Que dit la littérature sur le sujet?

Il y a plusieurs pistes, dont une fait référence absolue:
La fameuse pyramide des tests.
Tout le monde la connait, mais en pratique très peu la respectent.
Pourquoi? Je ne sais pas et j'avoue que les bras m'en tombent encore et toujours...
On sait, mais on ne veut pas voir. Probablement.
Parce qu'aussi, il y a un manque de courage avéré.

Pourtant, il suffit de regarder: la pyramide est inversée. La base représente la partie la plus large. Là où tout repose. Donc elle se doit d'être solide. Et c'est là que les tests unitaires se logent.
Et par tests unitaires, je parle bien de ceux écrits dans une démarche TDD. Red, green, refactor. Pas moins. Et qui se jouent en isolation.

Le haut de la pyramide, c'est un peu la cerise sur le gâteau. Là où beaucoup trop de gens y voient écrit "End 2 End", il aurait mieux fallu marquer: Exploratory ou Smoke tests.

J'entends encore (et toujours) dire que les tests unitaires c'est compliqué à faire, et que le TDD, bah, ca prend du temps (ce qui est totalement faux). Et surtout ça demande des compétences, donc "on verra plus tard".

Et le "plus tard", c'est justement le test E2E. Celui qui vient à la fin. Et qui fini par prendre une place prépondérante dans une intégration continue. A tort.

Si Uncle Bob, Martin Fowler, Kent Beck ne manquent pas d'avoir proféré toutes les injonctions à l'endroit du TDD et à l'encontre du E2E; d'autres auteurs n'ont pas toujours été aussi clair.

Dans un livre pourtant bien écrit (Unit Testing Principles, Practices, and Patterns ), Vladimir Khorikov est revenu tout récemment sur la mésinterprétation croissante de son propos sur les tests E2E; il en a fait plusieurs billets dans sa newsletter et je reprends quelques un de ses arguments ici.

Et puis il y a les ultra convaincus, qui n'y vont pas par quatre chemins: les tests E2E sont une arnaque! (pour rester polis).

Combien ca coûte en vrai?

Très cher! Trop cher!

Un test E2E parait facile quand on regarde les 2 tutos et les 3 bouts d'exemples qui trainent partout.

Un test E2E ça va, 10 tests bonjour les dégâts.
Ils prennent du temps pour s'exécuter. La boucle de feedback est beaucoup trop longue!
J'ai travaillé avec des éditeurs logiciels chez qui il fallait lancer les testes E2E (tous piloté par Selenium svp) le vendredi après midi et prier le weekend pour espérer voir un résultat viable le lundi matin.
Car ces tests pouvaient échouer lamentablement, non pas à cause d'un vrai bug dans le code, mais parce que toute la machinerie mise en branle était fragile et cassait souvent toute seule.
Un naufrage.
D'ailleurs ce sont des sociétés (que j'ai connues) qui ont plié boutique depuis.

Donc je vous parle en termes purement économiques. Financiers. Money!!!

Sont-ils fiables ?

NON!
Les tests E2E ont comme principales caractéristiques de vouloir tout tester, donc de tirer toutes les dépendances du monde; cela peut être (liste non exhaustive):

des APIs tierces
des bases de données / système de fichiers
des ressources externes
des systèmes de communication (vulgairement des Entrées/Sorties)
des librairies tierces
le temps! (indéterminisme)
la génération de nombres aléatoires, et tout ce qui se base dessus: numéros de séquence unique (Guid), Cryptographie...

Et pour ajouter de la difficulté dont on se passerait bien, certaines de ces dépendances peuvent présenter des comportements asynchrones et/ou indéterministes.

Beaucoup se risquent à régler les 2 derniers problèmes avec des exceptions, ce qui ne règle rien, alourdit votre code (en temps d'exécution et pire en lisibilité) et rend l'ensemble encore plus sujets aux bugs. Bref, rien ne va!

Deux symptômes apparaissent:

Les faux négatifs

Quand un test E2E plante c'est souvent parce qu'une de ses dépendances a planté.
La base de données ne répond plus ou n'a pas le bon jeu de données initiales par exemple. Ou -horreur suprême- les tests doivent être joués dans un ordre donné, cad on a un test qui dépendrait d'un autre (là, on frise le mental breakdown).
Hors ce n'est pas le comportement du système tiers que vous voulez tester, car celui-ci est déjà testé par ailleurs (ou devrait l'être par son fournisseur si celui était un minimum sérieux).
Ce que vous voulez savoir c'est comment vos composants, un ^par un - en particulier celui qui fait l'interface (ou mieux l'adaptation) avec le dit système externe, se comporte en cas de problème. Point.¹

Un faux négatif reflète un test coûteux à maintenir, car il vous faudra pas mal de temps (surtout pour chercher d'où vient le problème puisque vous faites jouer toutes les dépendances en même temps avec des effets de bord de partout) pour le debugger et lui redonner un comportement normal. Ou bien il aura tendance à revenir instable assez souvent.

Les faux positifs

Ce sont les tests qui restent verts alors que vous venez de changer le comportement d'un bout de code quelque part. Difficile de les identifier dans les End 2 End.
Toutes les dépendances traversées vous amènent à écrire des tests qui ne testent pas vraiment ou pas entièrement votre code, in fine.

Il arrive que supprimer des lignes de notre code n'impacte aucun test E2E, car cela tombe hors des radars des dépendances.
Du coup, vous livrez un bug mais vous ne voyez rien passer.
Par contre, vos utilisateurs ne manqueront pas de tomber dessus très rapidement.

Alors, c'est quoi un bon test?

Il doit avoir 4 grandes propriétés:

Protéger contre les régressions
Une modification de code entrainant un retour en arrière sur un comportement attendu devrait faire passer au moins un test au rouge.
Pour éviter cela, vous pouvez vous doter d'un outil pour faire du test de mutation (mutation testing).
Donc absence de faux positifs (des tests qui resteraient verts alors qu'ils devraient être rouges).
Donc détection de bugs efficace.
Résistant au refactoring
Le refactoring de code (changer du code sans changer son comportement) ne doit pas faire passer vos tests existants au rouge.
Donc absence de fausses erreurs (faux test rouge).
Donner un feedback très rapide
Un test ne devrait pas prendre plus de quelques dixième de secondes pour donner son résultat.
Donc pas d'attente, pas de boucles, pas de sleep ou wait (sérieusement? vous pensiez tester comme ça du code asynchrone??? 🤯). Personne ne devrait accepter attendre plus d'une demi-heure pour avoir les résultats d'une campagne de tests.
Maintenable
Des journées à écrire un test, à le faire passer au vert puis à le modifier ou le consolider?
Allons, allons. Il est temps de faire table rase de tout cela.
Il faut qu'il soit facile à écrire, et facile à lire bien entendu.
Plus il y a de lignes de code dans un test, moins solide il sera.
Et attention au code caché (par exemple derrière de la configuration et donc des dépendances).
Ne pas mocker ce qui ne nous appartient pas (je reviendrai là dessus).

Plus le test est dur à faire tourner: reboot un serveur, restaurer une base de données, résoudre des problèmes de config ou de réseau... plus ce sont des dépendances dont il vous faut vous défaire. Par plus d'abstractions.

“Push tests as low as they can go for the highest return in investment and quickest feedback” Janet Gregory and Lisa Crispin

Payez vous une cure de désintox des tests E2E

Les tests End To End sont une facilité, pas une fatalité.
Avec de la pratique et de la rigueur, on peut les limiter à un très très petit nombre et les remplacer avec une meilleure efficacité (couverture technique ET fonctionnelle améliorée) à condition de bien s'y prendre.

Il vous faut procéder par petit pas:

1er pas: débranchez tout! (vers des tests hermétiques)

On teste en isolation. Il y a des milliers de lectures à ce sujet, je m'y étendrais pas cette fois ci;
Voici ce qu'en pensait un ingénieur de chez Google en 2014 .

On peut dire qu'un bon test devrait pouvoir tourner sur n'importe quelle machine sans connexion réseau.
Oui, oui. Vous avez bien lu.

Surtout, surtout, faites tout pour éviter le coup: "mais ca marche sur ma machine, je ne comprends pas!".
Et ne comptez pas sur le DevOps pour vous sauver, au contraire ^^

2e pas: une conception objet "test oriented"

Si vous faites du TDD², et suivez les heuristiques SOLID intelligemment, alors vous devriez automatiquement vous sentir légitimes pour dire: "les tests E2E sont une complète aberration, car ils mettent à mal toutes les règles que je tente d'appliquer":

Single Responsibility
Open for extension / Closed for modification
Liskov Substitution
Interface Segregration
Dependency Injection

Appliquez ces heuristiques à tous vos tests, et effectivement vous verrez, les tests E2E sont à coté de la plaque!

Le code de VOS tests est aussi VOTRE code. Il obéit aux même lois.

3e pas: vers une architecture "test oriented"

Et pour cela, l'architecture hexagonale a fait ses preuves. J'y reviendrai sûrement dans un prochain article.
Cet architecture préconise de mettre en place des Ports et des Adapteurs, qui permettent justement de ne pas tout tester en même temps, d'éviter les tests E2E. Si on a les bons niveaux d'abstraction bien sûr.

4e pas: le métier est vérifié et codé dans des Bounded Contexts

Je reprends ici les termes du Domain Driven Design, car même sans faire d'Event Sourcing, DDD nous propose de découper, délimiter, responsabiliser le domaine métier et ses règles; et évidement de le découpler de tout ce qui est autour (UI, persistance, services externes, sous domaines, domaines génériques, domaines support).

Ce qui va découper, découpler votre système et donc rendre redondant (voir impossible) du test de bout en bout. Et tant mieux.

Mais comment peux tu être sûr ?

C'est à peu près du même niveau que de me dire: "comment peux-tu être certain que la terre est ronde, parce qu'à l'œil nu elle apparait plate".

Il y a toujours eu des gens pour me dire: "mais tu ne peux pas avoir de certitude à 100%" sans les tests de bout en bout.

Je ne dis pas pour autant qu'un test E2E est inutile. Parce que la vraie question est "que teste-t-on"?
Ou plutôt :

"Que peut-on tester?"

Si on ne dispose d'aucun outillage de tests efficace, alors oui, il ne reste (hélas) que le test E2E.
Mais vouloir tout tester avec un E2E est une perte d'argent et de temps comme je ne cesse de le répéter ici.

C'est là où tout le monde s'embrouille sur la pyramide de tests quand on lit: "integration tests".
Pour beaucoup, tester en intégration c'est tester tout ce qui peut s'intégrer, ensemble, en même temps. Et bim!
On revient sur du E2E.

Tout comme ceux qui ont confondu les tests E2E avec les tests de l'Interface Graphique.
Parce que c'est tellement facile (en apparence) à coder avec des outils comme Selenium ou Cypress.
Parce que justement leur architecture spaghetti, ou N-tiers ( = plat de lasagne), ou maintenant Micro Services ( = plat de raviolis) ne permet plus de séparer la UI (User Interface) d'un monstre monolithique où tout est collé bout à bout.

Pourtant, le but est de tester si les composants qui ont, par ailleurs, été testés de manière isolée, s'intègrent bien entre eux.
Une fois cela vérifié, pourquoi l'ensemble ne serait-il pas stable?

Integration ou Contrat ?

Une intégration fiable se joue autour d'un contrat fiable.
S'assurer que le contrat est respecté, DES DEUX COTES, c'est faire une intégration qui tient la route.
Il faut vérifier (automatiquement de préférence) l'équivalence du contrat des 2 cotés d'un composant: fournisseur (provider) ET consommateur (consumer).

Quand on fake (parlons de doubler, comme au cinéma), le test n'est valide que si la doublure est ressemblante.
Il faut s'en assurer constamment (à chaque build, à chaque intégration continue), le contrat ne doit pas être rompu ³.

La bonne idée pour éviter des vérifications superflues, c'est de laisser le compilateur les faire par le typage. Un typage très fort et un respect des règles SOLID. Et ne pas utiliser les exceptions. Et suivre toute la démarche DDD, cela aide beaucoup.

Les bénéfices de l'abstinence

Les gens qui mettent (perdent) tout leur argent dans le E2E testing, sont hélas ceux qui n'ont pas pris soin d'explorer d'autres pistes.

Et pourtant, il y a des choses bien plus profitables (rentables, messieurs les financiers) comme le Smoke Testing, le Sanity Testing et le Regression Testing.

Et s'il ne devait en rester qu'un

Et bien, un test "End to End" , de bout en bout, pourrait bien s'avérer utile pour tester ce qu'on ne sait vraiment plus tester autrement, et c'est peut être justement l'intégration de l'intégration.
L'articulation ultime.
Mais je suis sûr qu'on peut le remplacer par un autre test d'intégration, si on cherche bien ;)

Et à ce moment là, que dois je vérifier?
Que mon système démarre bien. C'est tout.

Derrière cela veut dire que ma config est juste et que mes systèmes sont opérationnels. Mais cela aussi je peux le surveiller ("monitorer") par d'autres tests plus unitaires.

Juste un test, un happy path. Un seul. Pour convaincre le dernier des incrédules.

Je ne me laisserai même pas tenter par une liste de "High Value Paths" comme on peut le lire par ici ou là; parce que si vous entrez dans cette logique, vous allez en écrire autant que de Use Cases de votre métier (c'est à dire: pléthore).
Alors que toute la logique devrait être dans le Domaine Métier et les agrégats qui le constituent tel que nous l'apprend DDD.

C'est l'objet du prochain article que je suis en train de peaufiner.
Merci de m'avoir lu jusqu'ici.

Références

https://www.stevesmith.tech/blog/end-to-end-testing-considered-harmful/

Analyser/prouver comment ensuite l'éventuel problème (déclenché par un système tiers) se propage à l'intérieur de votre ensemble de composants, devrait être réglé par une programmation propre (principes SOLIDES encore, mais aussi ne pas utiliser les exceptions, utiliser des monades de type Result ou MayBe ou Optional). Finalement se résoudre en un problème de typage et donc de compilation, pas de tests à proprement parler. Ca serait tellement plus rapide à vérifier! ↩
J'ai cité TDD cinq fois à ce stade, laissez moi vous recommander un peu de lecture sur le sujet. ↩
Le bon outil, me semble-t-il, c'est le Contract Based Programming/Testing. Oui c'est un travail supplémentaire. Mais je ne vois pas comment l'éviter pour ne pas retomber dans le piège du E2E qui finalement est un pis-aller pour ceux qui ne prennent pas le temps de faire soit du typage fort, soit du Contract Testing (Consumer-driven contract testing (CDC) expliqué ici ) ↩

Que vaut le travail que l'on ne fait pas?

craft Softwr & Music — Tue, 26 Jan 2021 09:59:21 +0000

Je me suis posé cette question dans le prolongement de l’excellent article de mon confrère Nicolas Brondin où il explique bien que le travail de développeur ne se résume pas qu’à produire du code.

Étonnant d’en venir à justifier que l’on travaille quand on ne travaille pas. Je pense même que cela peut choquer hors du cercle des informaticiens.

Cela révèle que développer (coder) est un métier vraiment pas comme les autres.
C’est le mien, j’en suis très fier et il ne s’agit ni d’une passade ou d’une erreur de trajectoire. Ni je pense d’un hasard.
En tout cas, ce n’est pas une honte de rester développeur jusqu’au bout et de ne pas vouloir être super chef ou commercial comme aboutissement d’une carrière.
Savoir coder n’est pas (forcément) une transition vers quelque chose de soit disant plus honorable ¹.

Ce n’est qu’au fur et à mesure de ma progression dans ce métier que je m’aperçu que ce n'était pas un simple travail d’ingénieur au sens commun du terme. Ni de scientifique d’ailleurs.
Nous (les développeurs) utilisons des outils de la science, mais nos productions ne sont pas des découvertes. Nous ne démontrons pas de théorèmes. Nous ne découvrons rien que nous ne sachions déjà (sur les théories de l’informatique et le travail de nos pairs avant nous).
Nous explorons simplement.
Et surtout nous créons des choses qui n'existaient pas dans leur tout (le nouveau logiciel, la nouvelle fonctionnalité) sous une forme auparavant donnée.
Nous créons. Nous ne découvrons pas.
Et chaque logiciel est unique.
En découle qu’il n’y a pas d'usine logicielle, au sens où notre travail n’est pas industriel.
Ce qui sort d’une industrie, d’une chaîne de montage, ce sont des séries, des copies.
Exactement ce que le logiciel n’est pas.

On ne peut pas changer 1000 personnes 1000 fois...

Pour preuve: donnez le même problème à résoudre à 1000 informaticiens différents, et vous aurez 1000 code sources différents.
Ne serait-ce que par l’existence de plus de 800 (parmi ceux recensés) langages de développement connus à ce jour (http://www.rosettacode.org/wiki/Rosetta_Code).
Combinez cela au fait que, dans un même langage de programmation X ², 10 développeurs vous produiront 10 codes sources différents, du fait même qu’émergent des styles d’écritures différents, propre à l’expérience de chacun, mais aussi à leur vécu, leur formation, et quelque chose d’impalpable qui est de l’ordre de l’intuition et la sensibilité, c’est à dire bien en dehors des domaines de la rationalité et de la science.

Oui, le travail de produire un logiciel est complexe et échappe à la science au bout d’un moment.
Alors, comment voulez-vous que nous puissions prédire “combien de temps cela va prendre à développer ???”.
Impossible avec certitude. Ne cherchez pas et passez plutôt du temps à coder!

Mais il y a autre chose, sur les “styles” de programmation.

Regardez 2 réponses (sous forme de code) au même problème (le très célèbre kata qui consiste à transformer en chiffres romains un nombre entier positif inférieur à 4000):

2e code, qui fait exactement la même chose:

Les 2 versions du code donnent le même résultat au moment de l’exécution.
Alors, pouvez-vous encore honnêtement penser que le travail de développeur se résume à la ligne de code que l’on a écrit?

Les lignes de code n’ont aucune valeur juste par leur nombre. Au contraire.

Montre moi ton code, je te dirai combien tu vaux

Si l’on me demandait de payer le développeur à la ligne, je n'hésiterai pas à attribuer à 80% des lignes de code une valeur négative.
Pourquoi?

Une raison parmi tant d’autres est la lisibilité du code. Il est plus facile de lire quelque chose de concis; à condition que cela soit explicite évidemment.
Par contre, comment mesure-t-on l’expressivité du code?

L’autre valeur négative qui se cache derrière une ligne de code en trop est le bug qu’elle va induire. Moins de code = moins de bug. Là pour le coup, c’est juste mathématique.

Autre valeur négative: la complexité du code rend difficile voir impossible sa maintenance et son évolution. Quand un nouveau cas (use case) se présente; ou bien un comportement non prévu (bug) vous devez fouiller dans beaucoup de lignes de code pour corriger. Perte de temps et d’argent.

Viens le point littéraire de l’article, merci Saint Exupéry, mais il est toujours pertinent:

Il semble que la perfection soit atteinte non quand il n'y a plus rien à ajouter, mais quand il n'y a plus rien à retrancher.

Au passage, vous avez noté qu’il était romancier, non pas informaticien.

De la mesure du code

Pour revenir à la valeur d’une ligne de code, nous avons des heuristiques, des guidelines, qui nous permettent de juger des qualités ou des défauts (selon un certain nombre de conventions, adaptables) du code, et qui nous poussent à l’améliorer (refactoring).
Pour moi, ce sont avant tout les principes DRY, YAGNI et SOLID, mais aussi la Connascence ou couplage .

Ce travail autour de la qualité du code est plutôt abstrait.
Qui sait réellement la mesurer sans équivoque?
Ce n’est pas Sonarqube qui va vous dire si vous avez fait du copier coller, ou si vous ne respectez pas les principes SOLID. Encore plus pour du YAGNI ou une Feature Envy.
Rien ne remplacera une expérience/expertise humaine.

Je vois quand même 2 bonnes mesures de qualité du code à commencer à appliquer: la complexité cyclomatique et les graphes de dépendance (je pense à NDepend pour .Net).
Ceux-là devraient être intégrés comme règle dans Sonar (ou équivalent).
On attribuerait des valeurs négatives aux lignes de code qui augmentent la complexité cyclomatique et les dépendances.
Tout comme il faut pénaliser celles qui ne sont pas couvertes par les tests.
Mais là encore, c’est une mesure qui peut être déformée. Voir contournée.

Quantité vs Qualité

C’est donc un travail intellectuel énorme que de se retenir d’écrire une ligne de code.
Toute ligne en trop, ou de mauvaise qualité, rentre dans la catégorie de la fameuse “dette technique”.
Et d’ailleurs, qui pourrait évaluer la valeur (négative) de la dette technique que l’on s’efforce de supprimer? Comment la chiffrer?

En tout cas, le travail de frugalité intelligente, de parcimonie éclairée, ne se joue pas qu’au niveau du développeur mais aussi sur celui des architectes.
Combien de choix d’architecture logicielle, de frameworks, de librairies à la mode, qui ont conduit des projets au désastre.
Combien de frameworks (je pense aux affreux JavaBeans et autres horreurs type Corba à l’époque) qui vous impose d’écrire des tonnes de lignes de code overkill ? Imbitables ...
Ou bien si un framework n’est pas si mal pensé, combien de fois est-il vraiment bien utilisé?

Il est si facile de transformer un bon pattern en un anti pattern, juste par un mauvais usage.

Un mot pour conclure:

Uncle Bob (Robert C. Martin): "A good architect maximizes the number of decisions not made."

Not made. La meilleure décision est celle que l'on ne prend pas...

Difficile là aussi de donner une valeur à l’absence. Et pourtant.

Finalement, peut-on évaluer le travail du codeur?

Comme on l'a vu ce travail qui n’est ni science, ni industrie, que vaut-il? Quel est il? Peut-être une forme d’art? Et comme dans tout art, il cache une grande part d’intangible.
N’en déplaise à ceux qui veulent tout monnayer et tout transformer en chiffres.

Heureusement, il restera la valeur ajoutée délivrée aux utilisateurs. Mais encore faut-il y ajouter le calcul de la dette technique, la vraie valeur du code. Cela s'appelle le coût marginal de la prochaine User Story, pour reprendre les propos d'Arnaud Lemaire.

Pour moi, il y a d’abord eu la fascination pour les machines, et surtout la possibilité -rendue simple- de prendre le contrôle de la machine. De parler à l’oreille des machines pourrait-on dire. Pourtant, je n’ai eu que relativement tardivement (par rapport aux 1ères lignes de code que j’ai écrites) accès aux travaux d’Alan Turing , Alonzo Church et Noam Chomsky, 3 des pères de la programmation (et je dois humblement admettre que, n’ayant pas poursuivi dans le domaine de la recherche, je n’ai acquis que des bouts de leur savoir)³. Je n’avais pas une vraie vision de mon métier alors. ↩
j’aurais bien aimé dire Z, mais Zed est déjà le nom d’un langage de programmation ^^ ↩
Et quand bien même, qui peut dire qu’il comprend parfaitement tout ce que ces génies ont voulu nous transmettre? ↩

Modèle anémique ou modèle métier? Comment la modélisation objet a su évoluer .

craft Softwr & Music — Fri, 18 Dec 2020 10:29:24 +0000

Constat

J'ai la chance de pratiquer la modélisation d'objets dans le cadre d'applications variées, utilisant pour la peine un mix entre diagrammes UML, diagrammes C4 plus récemment et beaucoup de Design Emergeant en codant directement les classes d'objets au fur et à mesure avec la sécurité du TDD (Test Driven Development).

Et immanquablement se pose la question de : "comment organiser les classes?" et surtout "quelles sont leur responsabilités?". Cela abouti toujours à de grands débats qui animent les séances de code; en cela le Pair Programming, et encore plus le Mob Programming ouvrent les discussions.

Donnant actuellement des cours UML et conception objet à des universitaires, il est toujours délicat d'expliquer comment poser les bases d'un "bon" design objet.

L'apprentissage classique et le nombre de tutos qui ont emboité le pas dans la catégorie "auto formation" se délectent d'exemples simplistes et -hélas- peu en phase avec le quotidien du développeur: le cercle, le carré, le rectangle, la forme géométrique (shape) sont les modèles usés et usuels pour illustrer aux étudiants un 'bon' modèle d'objets. Objets auxquels on colle les opérations fadasses: calculer aire et je ne sais quoi de trop scolaire.

Avec cela, beaucoup de développeurs se font une très mauvaise idée de ce que devrait être un vrai modèle objets dans une application d'entreprise qui se verra mise en production avec des milliers d'utilisateurs (ou plus j'espère) et des années de durée de vie, entrainant une nécessaire maintenance et évolution.
Sans parler des bugs qui apparaitront inévitablement.

L'héritage lancinant de Merise

Je trouve que la méthode Merise a causé énormément de tort et de retard à l'ingénierie logicielle en France (pour ce que j'en connais).
Très en vogue dans les années 80, elle est assez rigide et s'accorde bien du cycle de développement en V. Elle impose tout un tas de diagrammes que je qualifie d'emblée de Big Design Upfront. Ce qui a tendance à rassurer les chefs de projets et les développeurs quand il faut s'attaquer à développer un système sans trop savoir où cela va nous mener.

Cette méthode de modélisation ne prône pas vraiment l'agilité, et, pour moi, mène à des architectures d'applications trop rigides et fortement couplées, avec une qualité de design assez pauvre.

Elle se base aussi sur un postulat bien encombrant: tout doit reposer sur une base de données, relationnelle qui plus est!

Cette omniprésence de la base de données (et des gens qui en sont les gardiens, à savoir les concepteurs et les administrateurs, les fameux DBA longtemps très recherchés et considérés comme des demi-dieux) nous avait amené à ériger en modèle de programmation parfait l'architecture N-tiers, dans laquelle la couche de persistance (l'accès à la base de données) était la fondation de tout et dictait son modèle aux autres couches. D'horribles dépendances se créaient. Mais après tout c'était du Merise à la lettre.

Evidemment cette dépendance au choix d'un SGBDR et un tel couplage était rapidement source d'un coût de maintenance insupportable. Un changement de solution SGBDR demandait quasiment la ré-écriture du tout.

Si malgré tout, on pouvait obtenir l'assurance que l'on allait rester fidèle à son moteur SQL préféré pour la vie, se posait le problème de la responsabilité attribuée: la base allait même jusqu'à gérer les règles métiers complexes;
avec l'échouage ultime qu'était l'utilisation de triggers, où le comportement était mêlé de manière inextricable au simple stockage. Dur à tester, couteux à maintenir, horrible à faire évoluer.

Poussée du design objet

Heureusement les librairies et les frameworks (🤔) nous ont poussé vers d'autres design d'architecture.

Le problème étant: comment faire vivre des objets à coté d'une base de données. Et comment y accéder depuis différentes Interfaces Homme-Machine; ces dernière se multipliant à la faveur du déploiement des Internets et des clients (programmes client/navigateurs/plug-ins) de plus en plus universels et versatiles (pour ordis, tablettes, mobiles, interface vocale, objets connectés).

Cela a donné le genre de modélisation objet où l'on fait émerger les classes parce qu'il y a des tables dans une base de données et on les affubles de toutes les opérations possibles et imaginables:

On avait envie, par principe DRY (Don't Repeat Yourself) d'avoir des objets omnipotents, qui encapsulent tout, le savoir être (l'état) et le savoir faire (les opérations). Des objets avec des tonnes de méthodes. Et des objets qui se promèneraient (les mêmes) de couches en couches du système, de l'interface graphique à la base de données.
Des initiatives ultra-monolithiques furent légion, telles que des bases de données orientées objets (je pense à un vieux système français aujourd'hui disparu: O2) ou des frameworks tout en un, type WinDev (encore hélas en vie) ou FoxPro ou Delphi. Cela pouvait bien fonctionner sur des applis Client Lourd. Mais au prix d'un couplage immense.

Heureusement les interfaces Web et la multiplicité des solutions de stockage (sans parler des services et de la virtualisation extrême de tout cela) rend impossible de trimbaler des objets aussi lourds et chargés de tant de responsabilité.

Et tant mieux, il nous fallait un code plus simple.

Epurer, jusqu'à l'anémie

C'est comme cela qu'on en est arrivé à des modèles d'objets anémiques.
On s'est mis à concevoir des classes qui représentent des entités mais qui ne contiennent aucune logique métier, car elles étaient bien souvent une émanation des DAO (Data Access Objets) dans une architecture 3-tiers ou dans un design MVC/MVVM.

C'était pour "simplifier". Seulement, on n'a fait que mettre la poussière sous le tapis.
Soit la logique métier remontait dans d'énormes classes de "service" ou "business layers" qui finissaient par devenir énormes parce que le métier n'était pas mieux découpé.

Ce qui, au final, n'a rien simplifié car on s'est retrouvé pieds et points liés à la couche d'accès aux données ¹.
Avec derrière tout cela, l'idée qu'une bonne couche de liaison à la base de données allait une fois de plus nous dicter tout ce qu'il fallait: fais ton MCD (ou plutôt obéit à celui que le DBA a fait pour toi) et adapte ton code à cela.

Les ORM (Object-relational Mappers) continuaient de nous laisser croire que la méthode Merise était la bonne et que jamais nous ne nous serions capable de nous délivrer de ce fichu MCD.

Ou alors, ces objets orientés "données", non contents d'être anémiques en eux même, pouvaient cacher des règles métiers dans la couche DAO sous jacente: il fallait alors que l'exécution du code traverse la partie DAO pour voir apparaitre les contraintes sur les relations, les formats de données, et une partie des règles métiers que l'on savait traduire en ordre SQL: clés uniques, ou pire: triggers.

Et d'un autre coté, on en venait à coder dans la business layer (et parfois même coté client avec de beaux validateurs 🤢) les même règles.

Dès qu'on multipliait les services, on multipliait les règles, même si plusieurs services pouvaient finalement modifier la même entité (ou agrégat tant qu'on y est) avec chacun ses vérifications pour ses propres besoins, laissant la persistance finale se débrouiller plus ou moins bien avec des injonctions paradoxales. Bugs en pagaille assurés.

Une fois de plus, la base de données avait le dernier mot. Et les DBA jouaient le rôle d'arbitres entre équipes de devs qui se déchiraient sur la compréhension du besoin du client.

C'est du vécu!

Un peu de code ...

Je me suis remis dans la peau du codeur qui chasse les objets anémiés avec un petit Kata pour illustrer le principe Tell Don't Ask avec un TyrePressure Monitor ou un Cpu Monitor (en bref, un moniteur de ce que l'on veut, ca marche très bien).

La règle métier va se loger, non pas dans le service, mais dans la classe moniteur qui est utilisée par le service, afin que cette dernière 'affirme' (tell) la règle au lieu que ce soit le service qui demande (ask) des valeurs internes au moniteur pour satisfaire la règle.
Il faut que toute logique (fonction) qui a besoin d'une donnée doit se trouver dans la même classe qui contient cette donnée (encapsulation et Loi de Demeter).

Le résultat est ici.

Things that change together should be together. (Fowler)

Et si on parlait de DDD ?

Mais comment éviter un domaine objet anémique sans retourner aux erreurs du modèle objet old school, des objets obèses ?
C'est à la lecture de cet article que j'ai eu envie d'écrire ces lignes.

L'idée étant de pouvoir décrire un modèle riche mais affranchi des contraintes qui ne sont pas les siennes:
se sauvegarder dans une base de données untel ou s'afficher à l'utilisateur sur un interface Z (il existe des milliers de frameworks pour faire le beau sur le Web²)) ne concerne en rien, absolument en rien le Modèle du Domaine d'une App ou d'un SI.

Au début était le verbe

La motivation d'Eric Evans, avec son livre bleu Domain Driven Design, n'était pas tant de parler architecture logicielle mais de représentation.

Plutôt que le mot objet/classe, il choisit le mot entité.
Et le plus important des principes qu'il a voulu mettre en avant est celui du langage parlé par les humains impliqués dans un projet.
Pas le langage de développement mais bien le vocabulaire partagé, le nommage des choses, la sémantique commune, la conversation que les développeurs doivent avoir avec les experts métiers.

Cette approche appelée "Ubiquitous Language" nous oblige à poser plusieurs choses.
D'abord séparer les Domaines métiers, car plusieurs se cachent forcément dans tout système d'informations (mot valise que je vais utiliser pour parler d'une App, d'un SaaS, d'un site, d'un prog, bref... du code en production).
Ensuite établir des Entités regroupées en Agrégats afin d'obtenir un Modèle à l'intérieur d'un Domaine Délimité (Bounded Context).

Ce qui émerge petit à petit

Un atelier tel que l'Event Storming ou l'Event Modeling, nous aide à mieux savoir quoi modéliser (et comment) en partant de zéro et sans connaissance technique particulière (des posts its , des stylos et de grands murs suffisent).

Traditionnellement, il y a plusieurs choses qui émergent de ces ateliers: les évènements en premier, les commandes (ou actions en second) et très vite derrière les agrégats et leur "policies".

Cette distinction entre évènements et agrégats n'est pas anodine. Bien que les évènements aient des effets sur les agrégats, les agrégats existent pour eux même. Ils décrivent ce qui reste une fois les évènements passés. Et leur "policies" est leur profession de foi, ce qui est toujours vrai pour eux (et leur entourage proche).

Voila pourquoi une bonne modélisation du Domaine en Agrégats (Entités + Value Objects) va pouvoir nous enrichir en "règles métier", tout en traitant par ailleurs les évènements.

(Pour en savoir plus sur l'Event Storming il y a foule d'articles et bien sûr de publications à ce sujet, mais peu en français.)

Les évènements sont transients. Parfois contingents. Mais ils passent. On ne peut les arrêter. L'Event Sourcing tente de capturer ces évènements, comme on tenterait de capturer le temps.
Ce qui n'est pas sans risque!
On peut avec un certains nombres d'outils, remonter le temps et le cours des évènements; c'est la force de l'Event Sourcing. Au regard d'un certain prix à payer pour y arriver correctement.

Le Domain Model , quant à lui, survit aux évènements; c'est lui que l'on présente à l'utilisateur final (sous une forme adaptée, dite View Model ou Read Model ), lequel se moque pas mal des journaux de logs.
Les éléments du modèle montrent l'état (partiel et à un instant t) du monde (tel que manipulé dans un contexte donné) et sa cohésion.

L'intérêt d'un Modèle bien fait est d'imposer une cohérence qui s'affranchit des évènements (et également de se laisser facilement parcourir, découvrir).

J'aurai le plaisir de vous parler des évènements dans une autre article.
Et avant cela, d'aller plus loin dans les détails de la modélisation objet d'un domaine avec la suite de cet article.

On peut encore trouver du code assez horrible comme celui ci (projet Jigsaw), où on vous impose des trucs du genre: As you can see, the Java Beans are strictly equivalent to the table they represents. The name of the bean properties MUST be strictly equals to the column names in the SQL table. ↩
Si un framework de présentation (je pense à tous ceux basés sur les patterns MMVM ou MVP ou MVC) vous demande de placer dans sa couche à lui (son environnement si vous préférez) le modèle, je pense que vous pouvez le jeter par la fenêtre. Le modèle métier n'appartient pas à la couche de présentation. La couche de présentation manipule un View Model seulement. Les dépendances viennent du centre (core) de l'architecture, pas des bords (UI ou Storage). ↩

La DoD en question

craft Softwr & Music — Tue, 03 Nov 2020 15:48:13 +0000

On m'a récemment posé la question : qu'est ce qu'une bonne DoD? Definition of Done. En Français: définition de fini.
Difficile à dire. Est-ce une liste à la Prévert? Ou un contrat implicite (0)?
Elle se doit en tous cas d'être unique à chaque équipe et à sa stack technique; elle dépend bien évidemment de son niveau de maturité.

Néanmoins il m'apparait clair qu'elle devrait être source de discussions et d'un accord clair entre toute l'équipe!
Car quand c'est fini, c'est fini. On ne revient plus dessus. Sinon on est "hors contrat".

On peut commencer par lire l'avis de JP Lambert sur le sujet:

On y apprend avant tout que "sa" DoD a été établie par Les équipes web du Player qu'il a accompagnées. Et que celle-ci a évolué avec le temps. C'est un des aspects cruciaux d'une DoD: c'est un objet vivant!

D'abord la DoD, c’est du sérieux, cela devrait être une revue que toute l’équipe fait à chaque fin de Sprint. Ce n’est pas une unique personne qui valide la DoD dans son coin! Il faut donc lui consacrer du temps et de l'attention.
Il me semble que les cérémoniaux Scrum ne prennent pas (assez) de temps pour passer en revue la DoD (à mon goût).

Une DoD est néanmoins quelque chose de très personnel à une équipe; et doit être le fruit d'une réflexion de groupe et de compromis. Elle peut éviter qu'un groupe au travail ne se perde au milieu de ses propres objectifs ou ne soit plus aligné avec les valeurs qu'il partage. En cela, elle est aussi un contrat social du "bien travailler ensemble".

Alors, que met-on dedans?

Je me permet de vous livrer des pistes, issues de ma propre expérience et d'équipes que j'ai pu accompagner. Ce ne sont que des exemples, à adapter à vos besoins.

Les basiques :

Toute l’intégration continue a tourné depuis le dernier commit et tous les tests sont verts.
Aucune user story ne reste ouverte d’un sprint à l’autre (si une reste ouverte, il faut la re-découper en deux, fermer ce qui est vraiment fait et préparer ce qu’il manque à faire en une nouvelle US en restant focus sur la valeur livrée) (1)
Avoir des tests qui soient alignés avec les user stories et qui s'exécutent en permanence (soit par des Executable Acceptance Tests, soit par des matrices de traçabilités que l'on peut générer en taguant les tests unitaires et faire correspondre ces tags avec les exigences émergeant des U.S.) (2)

Documentation :

Réclamer des fichiers d’enregistrement des choix techniques/d’architecture (ADR) https://github.com/joelparkerhenderson/architecture_decision_record
pour le reste, il n'existe pas de "bonne documentation" (lisez les 6 lois); un crafter comme moi vous dira que la seule documentation qui vaille réside dans les tests (à condition qu'ils soient lisibles) et le code.

Pour le code propre

je mets personnellement des règles assez strictes, mais surtout des choses à vérifier manuellement. Les SonarQube et autres Linters / scanneurs de code me gonflent, même s'ils sont une aide utile pour les équipes qui cherchent l'uniformité ou qui n'arrivent pas à prendre assez de temps pour discuter de leur code entre eux; c'est un mal nécessaire et j'espère que ce n'est qu'une phase transitoire (3).
Quelques idées de règles possibles:

Tout a été écrit en mode TDD (le test écrit avant le code : il compile et il est rouge. On écrit le code : le test devient vert. Cela oblige à écrire de tout petits tests, on refactore avant d'écrire un nouveau test). Ce n’est pas parce qu’on fait de l’infra/devOps qu’on ne peut pas faire de TDD ; la preuve : https://www.hashicorp.com/resources/test-driven-development-tdd-for-infrastructure
Refactoring effectué // par exemple: Commentaires supprimés (les commentaires sont un bon indicateur de la faiblesse du code. Cf https://refactoring.guru/smells/comments )
Pas de code dupliqué
Limiter la complexité cyclomatique (peut se vérifier avec une règle Sonar, contraignant mais si on est un bon programmeur, on doit trouver les solutions)
Pleins d’autres règles sur le Clean Code ont été posées partout sur les internets, personnellement j'adhère à https://refactoring.guru qui nous dit:
Couplage trop fort : chercher les heuristiques
- Trop de clauses imports en-tête de classe/module
- Présence de « new » dans un constructeur d’une classe/module (couplage fort entre le code qui fait le new et la classe instanciée)
- Usage d'un outil de calcul des dépendances,
- et plein d'autres bonnes pratiques comme l'Injection de Dépendances et l'Inversion de Contrôle (DI et IoC).

Le souci c'est que cette liste va vite devenir longue et plus personne ne va la lire.
Et se pose toujours la question: est ce que tel bout de code en vaut la peine? Sera-t-il toujours là ou sera-t-il amené à disparaitre? Jusqu'où aller dans le refactoring?
Bien malin qui peut le dire. Le problème est que nous sommes tous à un moment donné sujet à l'amnésie. Le refactoring nous aidera juste à moins hurler "mais qui a écrit cette m**de" dans le futur (et bien souvent, celui qui avait écrit de la m, c'était moi!!!).

Le mieux à ce niveau étant peut-être d'admettre que l'équipe se doit d'être au meilleur niveau technique qui lui est possible et qu'elle doit sans cesse se former à cela (par le biais de Kata, de Mob Programming, de révisions régulière de tous les principe de Refactoring et Clean Code).

Le DoD pourrait dire:

Nous sommes satisfait de notre code (sachant tout ce que j'ai évoqué ci dessus), et nous avons fait en sorte d'être meilleurs à cette itération qu'à la précédente.

J'ai vu des équipes très tendues sur ces points là et la notion de qualité de code vraiment appréciée à des degrés très divers entre les développeurs. La qualité voulu par les uns constamment remise en question par les autres ou par le PO ("on n'a pas le temps"). C'est pourquoi la DoD devrait être écrite en dehors du cadre des Sprints, comme une volonté farouche d'arrêter de coder de la merde. Et d'en payer le prix plus tard. Et surtout d'être tous d'accord là dessus.

Tests

Ma conviction: ce ne sont pas les tests E2E qui garantissent que tout est ok; vraiment pas!
Utilisez du Contract Based Testing pour faire des intégrations propres entre vos différents services (je reviendrai là dessus).

Pour les équipes devOps, c’est également abordé dans cette vidéo de 30mn: https://www.hashicorp.com/resources/test-driven-development-tdd-for-infrastructure
Il y a plein d'Outils:

open-policy-agent
Goss
Inspec
Test-Kitchen
- Plus de détails utiles sur https://github.com/joatmon08/tdd-infrastructure

Elements non fonctionnel

Quid de la performance du code? De la montée en charge? Des accès concurrentiels? Des failles de sécurité?
Mais là aussi, tout dépend de votre seuil de tolérance, et encore une fois d'une vision de l'avenir de votre produit.

La DoD est là pour nous dire combien est-on prêt à investir dans le futur.

Autres catégories

On peut aussi rajouter dans la catégorie Pérenne ou dans une autre catégorie, ce qu’on peut appeler : « Synchro »

Etre sûr d'avoir dispensé, auprès des autres équipes concernées par les modifications résultantes de ce sprint, toutes les informations utiles (versionning, modèles communs, contrats, APIs et autres).

On s'aperçoit que c'est déjà, avec ces quelques bases, beaucoup de travail. Et que cet article est déjà beaucoup trop long ;)

Claude Aubry a depuis longtemps planché sur le sujet de la DoD, et il va au fond des choses, en proposant des niveaux dans les éléments de la DOD et cela a beaucoup de sens.

Les premières fois vous allez vous rater, forcément.
Ne vous découragez pas, et surtout ne laissez jamais tomber votre DoD.
Pour les POs zélés, ou les chefs de projets en mode "quand est-ce que vous aurez fini???", il faut vraiment miser sur la DoD dès le 1er jour du Sprint. Pour éviter qu'une dérive sur la qualité et la maintenabilité ne s'installe dès les premières itérations.
Il est très difficile de revenir en arrière ou perdre ses habitudes, tous agiles que nous soyons.

"Comment vais-je faire pour finir?", "Et si je commençais par finir?" devraient être les premières pensées qui animent votre travail.

Pour ne pas se laisser surprendre par la livraison et éviter l'effet panique, il vaut mieux commencer par la fin justement.
La vérification et la stabilisation de votre travail est la valeur ajoutée qu'il manquera toujours à celle du métier que l'on vous demande d'honorer.

Pour conclure, il semblerait que la meilleure DoD soit le consentement, éclairé et discuté, de l'équipe tout entière. La coucher par écrit permet d'abord la discussion et peut aussi rassurer vos parties prenantes.

(0) Evidemment je ne penche pas pour l'implicite à moins que l'équipe ne soit excessivement mûre et stable. "Making the implicit explicit" devrait s'appliquer aussi à la DoD.

(1) Si une telle situation se produit plusieurs fois, il faut réellement re questionner l’équipe sur son approche de l’agilité : est-on assez mûr pour faire des Sprints? Pourquoi laisser filer les US ouvertes ou ré-ouvertes ? Est-on sûr de la qualité de ce que nous produisons ? Savons-nous finir ce que nous commençons ? Savons nous en calculer la valeur ? Savons-nous garder les choses simples? Savons nous limiter notre WIP (Work In Progress)?

(2) C'est une immense problème que la vérification automatique d'une User Story. Le BDD pour écrire des tests End To End est une idiotie sans pareille sur laquelle je reviendrai dans un long article. Le BDD pour écrire des tests d'intégration ou de vérification métier est très utile. En fait, je ne fais pas de distinction entre BDD / TDD et TU.
Rien n'est facile en la matière mais la Vérification et Validation vaut toute documentation. Lire à ce sujet Cyrille Martaire https://leanpub.com/livingdocumentation

(3) Ce genre de pratique trop courante, car cédant à la facilité, est souvent corollaire de la présence d'un architecte tout puissant, qui dicte des règles à ces associés à travers un outil froid et des règles bétonnées. Rien ne vaut la pédagogie et la discussion, mais c'est plus long ;)