I had the chance to work few months in Agicap, an enterprise producing a cashflow management SAAS for businesses.
It was a great mission, my team worked a way that I consider to be, so far, the most efficient and pleasant in my career. We managed to produce value at a constant speed while keeping a full control of our code, not allowing any kind of quality depreciation over time.

This blog post is just a recap of all practices we had in place and why I believe it was beneficial for us. Please, keep in mind we chose these regarding our context, this is not some sort of silver bullets list.

Some context first, we worked on a new application, this was a green field project integrated in a distributed system. To do so, we were eight experienced and skilled people :

• one product manager
• one UX/UI designer
• one front-end developer
• five back-end developers (I was one of them)

The team worked in full remote as team members lives in various places in France.

We were also supported by an SRE team for infrastructure and delivery automation concerns.

In less than two months, we had a first MVP in production with some real users, then we kept delivering features on a regular basis (more on this later) while maintaining a high code quality.

How did we organize?

We worked in an Agile way, we had some rituals like daily meetings, retrospectives and some feature refinements, but we never chose an agile framework to work with. The reason is we wanted a process that match our way of working, not some « by the book » that no one really understands. Nevertheless, as we put a high focus monitoring our work in progress (WIP), Kanban is probably the closest to our way of working.

To help you realize how important WIP was for us, with five back-end developers, we tried to avoid developing more than two features in parallel, this mean we were working most of our time in pair/mob programming (I would say approximately 90% of mine). The rest of the time was dedicated to minor tasking and meetings with other teams. We sometime did more parallel work and it resulted in some organizational clutter and a lower overall quality.

We never had to do any kind of estimate, every task we did take as long as needed. I believe it helps reduce the WIP as you’re not constraint by time, so you’re not tempted to rush a feature to start the next one. As you’re not rushing the work, the overall quality benefits from it and you reduce the probability of a defect that requires you to stop what you’re doing to fix it. If we considered that one task was taking much longer than expected (and it happened several times), we just stopped it, step back to understand why and then we acted to solve bottlenecks and issues.

It doesn’t mean we did not have any planning at all, we were following a three-month roadmap with all the main features expected from this period. The trick was the planned workload was always lower than the team’s capacity (we were confident we could achieve our goals). By doing so, you’re preventing delays from unexpected constraints and complexity. Spare time is available for the team to do some refactoring, addressing code pain points, keeping the code base healthy. This time can also be used investing more in automation.

Discovering a new feature

When developing a new feature, it is important to spot complexity, edge cases and unexpected interactions with existing features as soon as possible. To do so, we had short meetings (half an hour) on a regular basis (usually twice a week). During these, we presented new features, challenged UI mockups, and we tried to create an exhaustive listing of every use cases.

Example Mapping is an amazing workshop to work around those corner cases as it provides a good support for reasoning. I will not explain here how the workshop works, I recommend that you read The BDD books: Discovery for more details. Also, a benefit we didn’t expect when introducing example mapping: it allowed us to isolate some problematic business rules among a feature, so we managed to develop it without the rule to avoid this unnecessary complexity.

Tests and refactoring

All our developments were test-driven, we put a lot of efforts in our test suite to be clean, easy to evolve and not too coupled to the production code. Tests require as much effort as the rest of the code to remain clean and evolutive, don’t hesitate to invest in builders and abstractions. It allowed us to do some heavy refactoring on our model without any major impacts in our test suite.

Refactoring isn’t just cleaning process or a response to remove some pain in the code. Software evolves and new features may not match the existing model. We broke ours several times to prepare for future developments. Fortunately, we worked in a context where everybody understands technical stakes, so we never had to justify any of our refactoring. Occasionally, we developed some temporary features to help our PM solve business issues, but these never lasted more than a few weeks before being superseded by longer-term solutions.

Experiments and failures

We tried to define and follow a norm for our developments, but it had to continuously evolve as new features may introduce new requirements. This is a moment when the team discussed and try to choose an adapted solution. More than once we didn’t agree, so instead of losing time in useless discussions, we stopped and tried several solutions in a time-boxed period (no more than a few hours). Then we compared results and defined the way we wanted to implement new behaviors. Quite often, it was a mix of several solutions.

Other times, we were pretty confident with what we developed, and then later (during development or even after deploying it to production) we realized it wasn’t that great. In this case, we only had to answer the following questions:

• If already developed and deployed, is this piece of code subject to future evolution or not?
• Does it have an impact on our productivity when developing features? (It could be the case for some architectural elements.)

Depending on the answers, we chose to stick with the current implementation, or we evolved it.

Continuous deployment

I’m doing a short parenthesis here to introduce you Accelerate‘s metrics:

• Lead time
• Deployment frequency
• Percentage of failures
• Mean time to restore

I want to highlight something: by increasing deployment frequency, you naturally reduce lead time. Also, as the batches you’re deploying are smaller, you reduce the number of changes to the previous version, so you decrease the probability of a defect. If you detect a defect anyway, as the number of changes is small, you will probably isolate the issue faster, so you can lower your mean time to restore.

For these reasons, the team was aiming for continuous deployment, our goal was to deploy in production every time we merged something on our main branch. As we were learning how to do so, we didn’t achieve that goal before the end of my mission, but we were already deploying at least once per day and we were already benefiting from it. Continuous deployment isn’t binary, there are different grades, each one adds more problematic to consider. Here’s one example: we had to set up a zero downtime deployment process as our users can use our service at any time and we don’t want to interrupt them. If your users only use your service during office hours, and you’re OK with a single deployment per day, automatizing a night deployment can be an excellent tradeoff to avoid zero downtime concerns.

Here’s the list of practices we had to deal with to achieve our goal: API versioning, feature toggling, rolling updates, graceful shutdown, zero downtime database schema migration, deployment automation. These can look rather simple in theory, but appears to be challenging when applied. For this reason, we included them progressively in our practices, so we could master them more easily.

These allowed us to work effectively with a trunk-based approach, this way, we were constantly integrating our developments and reducing merging costs. We also became more confident in our deployments as we had various ways to isolate potential defects (using feature toggles or downgrading to the previous version for worst-case scenarios). Feature toggling has other interesting aspects: as we could activate a toggle for some specific users, we used it to test new features directly in production. Once validated, our PM could communicate freely with users and choose when to make it accessible without depending on the developers.

To conclude

I really enjoyed this mission, this way of working matches how I imagine my work. It requires skills and rigor, but to me, it removes a lot of pain that I consider avoidable. Anyway, I’m conscious this is highly contextual, and not every company and teams have the means to do so.

At the beginning of this project, I had the feeling we could move faster and develop more. I’m happy we didn’t because it wouldn’t have been sustainable after a few months.

By my experience, the software industry seems to be addicted to sensation of speed. We have to learn to slow down to reach a sustainable and constant speed of production.

Au cours de ma carrière, j’ai été confronté à plusieurs reprises à des clients et/ou des acteurs internes qui souhaitent assurer un haut niveau d’uniformisation sur le code des applications. Cela se traduit par des conventions de style, de nommage, et parfois même des choix plus impactant comme des frameworks ou des architectures spécifiques. Dans les cas extrêmes, les propos de ces personnes laissaient entendre le refus d’un quelconque écart avec ces règles.

De mon expérience, la motivation derrière cette démarche est toujours la même : permettre à un développeur de facilement passer d’une application à une autre. En effet, les développeurs sont encore aujourd’hui des ressources rares et chères au regard du marché, et la plupart des entreprises n’ont pas les moyens d’attirer et d’en employer un grand nombre. Il s’agit donc ici pour l’entreprise de maximiser l’usage des ressources limitées qu’elle a à sa disposition. Cependant, cela implique d’appliquer ces conventions à l’échelle d’un sous-ensemble d’applications, voire même à l’ensemble des applications d’une entreprise.

Si ces motivations me paraissent tout à fait légitimes et raisonnables, je ne suis pas totalement en accord avec la solution envisagée, tout du moins sous ses formes extrêmes. Je vais tenter ici d’apporter ma réflexion sur le sujet. 

Disclaimer

Dans ce billet je vais raisonner à une échelle macro : un ensemble d’applications ou une seule application regroupant différents contextes métiers. Au sein d’un périmètre restreint (un contexte métier), il me semble en effet important de préserver un minimum de cohérence dans le code. À noter également que je ne remets pas en cause ici l’intérêt d’uniformiser la partie infrastructure et configuration de vos systèmes. Si par exemple vous travaillez avec Microsoft Azure ou Amazon AWS, vous voudrez sans doute maintenir une façon cohérente de vous interfacer avec ces plateformes.

Un même SI, mais différents contextes

Comme je l’ai déjà évoqué, le vrai bénéfice d’uniformiser le code est de permettre au développeur de rester en terrain connu. Il peut rapidement trouver ses marques comme la structure technique de l’application est déjà connue. Le plus gros de l’effort se focalise sur la compréhension de l’application, de son métier. 

Hors, si l’on s’intéresse aux différents métiers d’une entreprise / d’une application, on se rend compte qu’ils ne sont pas homogènes en termes de valeur produite, de complexité, d’usage, de volumétrie des données, et même pourquoi pas de charge de travail. Certains métiers vont également être dépendants d’autres métiers pour produire de la valeur. Un outil comme les Wardley Map permet aujourd’hui de bien mettre en lumière ces dépendances, mais aussi les différences de maturité et de spécificité business des composants d’un SI. 

La sphère DDD nous propose une ségrégation par Bounded Context pour structurer une application. En fonction du rôle (Core, Support, Generic) du domain associé, les solutions techniques proposées ne sont pas les mêmes (cf: Domain-Driven Design Distilled, Types of subdomains, p.46) :

• Core : métier très spécifique à l’entreprise, code avec des efforts de modélisation et développement importants.
• Support : métier plus simple et supportant le Core, code avec des efforts moindres.
• Generic : intégration et usage de systèmes tiers ou outsourcés.

De mon expérience, et de façon grossière, une application business s’articule souvent de cette manière : un métier complexe, dépendant de métiers périphériques (avec souvent des métiers de “paramétrage”), et qui vient parfois interagir avec des systèmes tiers, par exemple un CRM. 

L’usage de conventions de code uniformisées peut faire sens dans le cas des supporting domains. Une simple architecture de type CRUD peut par exemple se révéler suffisante pour répondre à ces besoins. Cependant cela me semble inadapté aux core domain (par les contraintes métiers fortes) ainsi qu’aux generic domain (contraint par les systèmes tiers). Porter l’uniformisation du code à ces contextes augmente la complexité et fait tendre vers des solutions sous optimales. 

Nos limites cognitives

Nous sommes tous contraints par les limites de nos capacités cognitives, ce qui correspond à l’ensemble des informations que l’on est capable de traiter à un instant donné. Il faut garder en tête que toutes les applications ne représentent pas la même charge cognitive pour un développeur, et que plus il a d’applications à gérer, plus sa charge cognitive est importante. Uniformiser le code permet dans une certaine mesure de réduire cette charge et d’accélérer la transition vers une autre application. 

Mais même avec cela, un trop grand nombre d’applications reste problématique :

• Trop d’informations à garder en tête pour être réellement efficace.
• Un temps et de l’énergie conséquents perdus lors de nombreux “context switching”.

Pour lutter efficacement contre cette limite, on peut envisager d’autres stratégies qui visent à limiter le nombre d’applications dont un développeur peut être responsable. 

Si l’on en revient aux Wardley Maps, on peut déjà simplement se demander : “À quoi sert cette application ? Est-elle vraiment essentielle pour mon business ?” Posez-vous sérieusement ces questions sans les évacuer d’un revers de manche. Simplifiez autant que possible, car nous avons tendance à surcomplexifier les systèmes que nous produisons, et aussi à apporter des solutions à des problèmes qui ne devraient pas exister.

You may not be interested by rocketry, but Elon gives us here a lot of heuristics for designing efficient systems. It matches perfectly well with software development.https://t.co/wjmePPe6VA

— Romain Berthon (@RomainTrm) August 7, 2021

Une autre stratégie (peut-être moins recommandable) est d’accepter que certaines applications ne soient plus maintenues par quiconque pendant un temps. Bien entendu, vous ne pouvez pas faire ça avec toutes vos applications, ici ce sont les contextes generic et supporting qui peuvent être concernés. Il est tout de même important d’identifier la fréquence des changements ainsi que les futures évolutions nécessaires avant de laisser vivre une application.

Parfois, le besoin d’uniformiser le code est exprimé par les développeurs eux-mêmes. De mon expérience, cette demande vient toujours de profils transverses à qui on demande d’intervenir sur plusieurs projets en même temps. Cela peut parfois mettre en lumière un problème d’organisation (pourquoi a-t-il besoin de travailler sur tous ces projets ?). Mais il reste important d’écouter ce type de retour et d’évaluer si une action d’uniformisation est nécessaire.

Innovations et gestion des risques

Lorsque l’on conçoit un système, il est rare de trouver immédiatement la bonne solution, le bon design. C’est particulièrement vrai dans le logiciel où le code change, les fonctionnalités évoluent. Il est donc très difficile d’anticiper les besoins futurs, et tenter d’anticiper n’est pas toujours souhaitable, car celà nous mène régulièrement à des optimisations prématurées et de l’over-engineering. 

Pour cela, il est important de rester ouvert aux changements et aux propositions d’évolution. L’amélioration des pratiques passe alors nécessairement par une phase d’expérimentation et d’exploration.

Quand une nouvelle contrainte apparaît, il faut donc comprendre ses impacts sur la solution actuelle et identifier de potentielles évolutions à apporter pour mieux y répondre. Cependant, si l’on souhaite conserver un code toujours uniformisé, deux scénarios s’offrent à nous :

• La quantité de code à modifier est trop importante, et le changement n’a pas lieu, on continue donc à travailler sur solution sous-optimale et l’on accumule de la dette.
• On se lance dans une évolution “big-bang”, sans savoir si la solution envisagée est la bonne, ni même si elle va aboutir. Là aussi, la méthode est sous-optimale puisqu’il faut investir beaucoup de temps et d’énergie avant d’espérer un quelconque résultat. Sans compter l’introduction de potentiels bugs dans des fonctionnalités qui ne nécessitent aucune évolution et qui fonctionnent parfaitement, ce qui est très frustrant pour ses utilisateurs.

Si les standards peuvent évoluer, il est donc plus pertinent de d’abord les tester sur un périmètre limité, et ainsi rapidement obtenir des feedbacks. Si les changements ne sont pas pertinents, alors le temps et l’énergie engagés auront été limités et il est simple de faire machine arrière. Si ceux-ci se montrent pertinents, on peut alors les généraliser de façon opportuniste, progressivement au fils des développements afin de mieux gérer les risques liés à ces évolutions.

Motivation des équipes

Outre le fait de ne pas rester coincé dans une solution inadaptée, les livres Accelerate (Allow teams to choose their own tools, p.66) et Team Topologies (Monolithic thinking (Standardization), p.114) soulignent également l’aspect humain; ces phases d’expérimentation et d’exploration tendent à augmenter l’engagement et la motivation des développeurs. 

J’y suis pour ma part très sensible, et un entretien avec un potentiel client où celui-ci insiste trop sur l’importance de coder selon ses standards est pour moi un mauvais signal. Ceci parce que le message que j’en retiens est : “Tu devras subir des choix passés, que tu n’as pas pris, et ce sans aucune possibilité de t’en extraire, même s’ils s’avèrent mauvais aujourd’hui. » Bref, pas très motivant. J’ai déjà refusé des missions pour cette raison.

Pour conclure

Vous l’aurez compris, je ne suis pas un grand défenseur de l’uniformisation du code à l’échelle d’une entreprise. Parce que les avantages que l’on peut en tirer me semblent finalement assez limités (limites cognitives, innovations, motivations), et aussi parce que cette approche a vocation à soigner les symptômes plus que les causes du problème (organisation, complexité du système). Comme je l’ai déjà évoqué, cette pratique peut faire sens pour des métiers « satellites » à faible complexité et sur lesquels les efforts de développements seront limités. Sur ce sujet (comme pour beaucoup d’autres), tout est question d’équilibre, il faut constamment veiller à ne pas s’enfermer dans un extrême.

Voilà maintenant plus de 5 ans que j’applique une approche TDD (test-driven development) sur l’ensemble des projets sur lesquels j’interviens. Si j’utilise toujours cette méthode, c’est parce que la présence de tests me donne confiance dans le code que j’écris : 

• Je m’assure qu’il fait bien ce que je souhaite.
• J’améliore constamment son design par du refactoring.
• Les tests mettent en lumière la très grande majorité des régressions que je peux introduire lors d’un refactoring ou d’une évolution.
• Je réduis ma charge cognitive et me focalise sur le cas métier que je suis entrain de traiter (les tests s’occupent de vérifier les autres cas pour moi).

Modifier mon code est donc une capacité permise grâce aux tests et que je souhaite conserver tout au long d’un projet : je peux améliorer son design pour le garder constamment adapté aux problèmes métier que je veux résoudre.

Avec le temps, je réalise qu’écrire des tests est une discipline difficile et que certaines pratiques peuvent être dommageables. Les tests unitaires “figent” le code et m’empêchent de le modifier facilement, ce qui peut sembler paradoxal puisqu’ils sont censés au contraire me le permettre.

Dans cet article, je vais essayer de mettre en lumière les raisons de cette dérive. Attention, mon propos ne sera pas focalisé sur la pratique du TDD mais sur les tests unitaires (TU) et la manière dont ils influencent notre capacité à modifier du code.

Écris une classe, écris une classe de tests

À chaque classe, chaque méthode son ou ses tests : C’est une définition du TU qui semble très répandue, je la rencontre beaucoup au cours de discussions avec d’autres développeurs, sur twitter, dans des articles de blog, etc. C’est même de cette manière que l’on m’a initié au TDD.

Il est vrai que c’est une façon simple d’écrire un test. Le périmètre que l’on souhaite tester est petit, avec un nombre de dépendances normalement raisonnable. C’est une approche vers laquelle on peut facilement se tourner lorsque l’on n’est pas à l’aise avec la rédaction de TU.

Cette pratique est souvent associée à l’injection de dépendance pour fonctionner. C’est à ce moment-là que l’on commence à introduire des mocks, on peut ainsi spécifier le comportement d’une dépendance sans dépendre de sa véritable implémentation. Notre classe/méthode reste donc bien isolée du reste du système lors du test. 

Mon point doit peut-être vous déranger : pourquoi vouloir absolument tester en isolement une classe qui de toute façon dépend d’autres classes ? Le comportement de la dépendance correspondra-t-il à celui que j’ai spécifié avec mon mock ?

Certains vous répondront qu’il vous faut également des tests d’intégrations. Afin de vérifier que les différents éléments du système interagissent de la bonne manière, et que le logiciel retourne le résultat attendu. 

Vous avez déjà perdu

Si vous adoptez cette stratégie, vous allez surement souffrir, ou souffrez déjà, d’une forte adhérence entre votre code et vos tests. En effet, il existe une contrainte forte pour chaque élément de votre système : des tests.

Cela signifie qu’à chaque signature de méthode que l’on veut changer, en plus du code l’appelant, il va falloir corriger les tests et les mocks qui lui sont associés. Nous avons donc perdu notre capacité à facilement modifier/refactorer notre code. J’ai encore le souvenir (douloureux) de journées complètes à “réparer les tests” suite à des modifications.

Ajoutez à cela un biais dont nous souffrons tous : celui des coûts irrécupérables. Alors qu’un test ne fait peut-être plus sens, nous avons tendance (consciemment ou non) à vouloir le conserver et le modifier, ceci uniquement parce qu’il est déjà écrit.

Vous l’avez compris, aligner de manière aussi systématique ses tests avec son implémentation génère un couplage important contre lequel vous luttez à chaque modification que vous souhaitez apporter.

Du coup, comment fait-on ?

Les TU impliquent obligatoirement un couplage avec le code. Même s’il existe des techniques pour le limiter, la première question qu’il faut se poser est : à quoi veut-on se coupler ?

De manière caricaturale, si vous travaillez sur des logiciels business, ce que l’on attend de vous est de développer des use cases. Ceux-ci sont des comportements que l’on attend de l’application, et il fait sens de vouloir les tester. Ces use cases peuvent être implémentés en une seule classe, ou en plusieurs. Ce sont des choix de design qui vous reviennent, mais aussi des détails d’implémentation que l’on veut pouvoir facilement changer et qu’un observateur externe du système doit ignorer.

Clairement, la stratégie que l’on vient d’explorer s’attache beaucoup à ces détails d’implémentation. Unitaire ne doit donc pas définir la taille de la portion de code que l’on veut tester. 

Je vous propose maintenant la définition que j’ai en tête quand je parle de TU: un test que l’on peut exécuter en isolation et dont le comportement est répétable et constant. 

Son résultat ne dépend donc pas du résultat d’autres tests ni de l’état de dépendances externes au système (appel à une web API, à une base de données). Notez que je ne définis pas la taille du périmètre testé.

Des tests de comportement

Aujourd’hui, j’adopte autant que possible une stratégie qui me permet de conserver ma capacité à modifier le code.

J’écris mes tests de sorte qu’ils dépendent uniquement des contrats entre mon système et le monde extérieur (endpoint REST, base de données, bus de données, etc.). Tout le reste est une boîte noire inaccessible. 

Ainsi, un test se présente typiquement de la façon suivante : 

1. Je définis l’état du système (ex: données en BDD)
2. Je lance une action métier via une API publique (ex: endpoint REST)
3. Je vérifie le nouvel état de mon système (ex: données en BDD) et les éventuelles interactions avec le monde extérieur (ex: publication d’un message sur un bus)

Pour écrire ces tests et les garder indépendants, j’utilise des implémentations “in memory” de mes dépendances externes (typiquement la base de données). Je m’assure également que ces implémentations ont des comportements identiques à celles que j’utilise réellement en production. Pour cela, j’écris quelques tests d’intégrations paramétrés qui testent uniquement les accès au monde extérieur.

Cette approche peut paraître extrême, mais elle répond au problème que je souhaite adresser dans cet article.

Je dois tout de même lui reconnaître certaines faiblesses : 

• Des boucles de feedbacks plus lentes.
• Des erreurs parfois plus dures à analyser.
• Il reste un couplage à certaines couches applicatives.

Créer des abstractions

Il est tout de même nécessaire d’aller un peu plus loin pour réduire l’adhérence avec les tests. En effet, si nous avons réduit aux interfaces publiques la surface à laquelle nous sommes couplés, celles-ci deviennent encore plus critiques en cas de modification. 

Par expérience, un bon moyen de mesurer le couplage à un contrat est de compter le nombre d’endroits où celui-ci est instancié.

Builders, générateurs ou encore données statiques, quel que soit la ou les technique(s) utilisée(s), l’objectif reste toujours le même : isoler la création d’une donnée, d’un service, de l’application, de sorte que si sa structure change, il ne faille appliquer ce changement qu’à un seul endroit dans les tests. 

Un autre bénéfice de ces méthodes est qu’elles rendent les tests plus clairs, puisque vous n’avez à spécifier que les données qui font sens pour le scénario. Avec le temps, vous arriverez sans doute à faire émerger un DSL pour vos tests, l’ajout de nouveaux use cases en sera facilité voir presque trivial.

Pour conclure

Il m’est arrivé plusieurs fois de rencontrer des gens qui ont tenté de mettre en place des tests unitaires ou du TDD sur leur projet, et qui y ont finalement renoncé après quelque temps parce que “ça ne marche pas”. Je pense que le problème que j’ai évoqué au cours de cet article est la principale raison de ces abandons.

Attention également aux dogmes ! Si je me montre critique envers les tests unitaires “petite maille”, ceux-ci peuvent se révéler utiles et parfois plus simples qu’un test “boîte noire”. De la même manière, il est parfois plus simple d’utiliser un mock plutôt que de définir l’état du système dans sa globalité. Il est ici question de compromis, de choix qui doivent être faits en connaissance de cause.

Si cet article vous a plu, je vous recommande de regarder la conférence DevTernity 2017: Ian Cooper – TDD, Where Did It All Go Wrong.

 

Edit 1 : Je vous partage également cet article que l’on m’a montré en réaction à ce post et qui explique sans doute mieux que moi le point que je souhaitais traiter ici.

Edit 2 : Deux autres remarques m’ont été faites :

• Certains tests sont déjà naturellement isolés (domaine, hexagone) et ne dépendent pas de détails d’implémentations. Ceux-ci sont aussi viables que la stratégie que je propose dans cet article.
• Si les tests « petite maille » ne sont pas idéals sur le long terme, ils peuvent être très utiles comme « échaffaudage » pour implémenter progressivement un scénario plus vaste. À condition de les supprimer une fois les conditions d’un test « grosse maille » remplies.

Il y a quelques jours, au cours d’une discussion, on m’a demandé quelles sont les pratiques que je pousse dans une équipe dans le but d’améliorer la qualité de code. Bon nombre de pratiques comme TDD, clean code ou encore DDD et ses bounded-contexts ayant déjà été cités, j’ai donc répondu : un code métier pur, parfois appelé functional core.

Dans cet article, je pars du principe que vous faite une distinction et séparation forte entre le code métier qui répond à une logique business, et le code infra qui répond aux problématiques techniques.

Quels intérêts ?

Un code que l’on peut qualifier de pur a deux caractéristiques : 

• Celui-ci retourne toujours le même résultat pour les mêmes entrées. Il ne dépend donc d’aucun état interne ni d’appels à des dépendances (base de données, heure système, etc.)
• Il ne modifie aucun état visible du système.

Les raisons pour lesquelles je pousse ce genre de pratiques sont extrêmement simples. Il m’est très facile de raisonner sur ce code puisque son comportement est à la fois prédictible et répétable. 

Il est également très simple de rédiger des tests pour ce genre de code. Vous pouvez donc décrire tous vos cas métiers sous cette forme : “mon système est dans cet état, je lance cette action, alors j’obtiens ce résultat”.

Par exemple, un scénario pour la réservation d’un parking : 

• J’ai renseigné mes dates et heures d’arrivée et de départ .
• Je valide ma réservation.
• Ma réservation est acceptée pour les dates .

Si l’on peut parfois considérer les problèmes de charge comme inhérents au métier, on a tout de même envie de les traiter comme des problématiques techniques. Gérer l’accès à un état partagé sur lequel on souhaite écrire se révèle vite complexe (usage de lock, de transactions par exemple) et empêche un code scaler. Nous ne voulons donc pas polluer de la logique métier avec ce genre de problématiques : garder le code pur est une façon simple de s’en assurer.

La raison d’être d’un logiciel 

Cependant, si nous écrivons des logiciels, c’est souvent pour produire ce que nous qualifions jusqu’à maintenant d’effet de bords : écrire en base de données, envoyer un mail, une notification, etc. Nous devons donc être capable de passer d’un code pur à impure et inversement. 

Une façon (peut-être simpliste) de voir un logiciel est une succession de transformations de données. Je veux lire une donnée sur mon disque dur (imprédictible), puis la transformer (prédictible) et enfin écrire le résultat sur mon disque (imprédictible). 

Comment faire vivre les deux ?

Nous avons vu jusqu’ici qu’il doit y avoir une distinction claire entre, le code métier que l’on veut pure, et le code infra qui lui est nécessairement impure puisque sa responsabilité est de traiter avec des appels réseaux et système. 

Pour faire cohabiter ces deux mondes, il nous faut donc un bout de code dont la seule responsabilité est : 

1. De récupérer les données nécessaires à une opération métier.
2. Appeler le code métier.
3. Envoyer le résultat à la couche d’infrastructure.

Répondre à cette problématique de séparation métier/infra est la principale motivation derrière l’architecture hexagonale. Dans cette architecture, nos services portent cette responsabilité :

Avec une architecture CQRS ou CQRS/ES, ce rôle est porté par le commandHandler.

Notez que la structure du code reste inchangée, seuls les types changent.

Ce pattern demande une certaine rigueur de la part des développeurs, il est en effet facile d’introduire des effets de bords dans le code métier. Pour cette raison la stratégie adoptée par Haskell consiste à encapsuler les effets de bord dans des IO monade. 

Je ne vais pas m’aventurer ici à définir ce qu’est une monade, mais si vous n’êtes pas familier avec ce concept, voici une image très grossière : Une monade est comme une boîte contenant de la donnée, pour manipuler cette donnée, vous devez fournir à la monade la fonction à appliquer. Une liste est par exemple une monade, l’IO monade en Haskell représente un effet de bord.

Dans cet exemple, j’ouvre le fichier input.txt, j’applique la fonction toUpperString puis j’écris le résultat dans le fichier output.txt. J’ai fait l’effort ici de décomposer les fonctions afin de voir les signatures. 

La transition du monde de l’IO vers du code pur se fait grâce à une fonction appelée fmap, ici appelée via l’opérateur <&>. fmap prend une fonction pure et l’applique un contenu d’une IO pour produire une nouvelle IO. On obtient ici un IO Uppercase.

Enfin, pour écrire le résultat, on applique la fonction writeOutput via la méthode bind (opérateur >>=). bind nous permet d’appliquer une fonction retournant une IO au contenu d’une IO.

Out of the Tar Pit

Si cet article vu a plu et que vous souhaitez approfondir le sujet, je vous encourage à lire le papier Out of the Tar Pit qui traite de la complexité logiciel, et qui propose un découpage similaire du code. J’ai découvert ce papier grâce à un talk explicatif de Romeu Moura.

Je suis un développeur convaincu par les bénéfices du TDD, je l’applique au quotidien sur les projets que me confient mes clients. Cela me permet de rapidement valider que mon code a bien le comportement attendu, de le “documenter” et décrivant un cas d’usage et de m’assurer par la suite que je n’introduis aucune régression si je modifie le code testé.

Je fais tout ceci en sachant que je choisis des cas de test qui me semblent représentatifs de l’usage de la fonction, on parle parfois d’Example Based Tests. Si cette méthode est souvent suffisante, il m’arrive parfois de me poser les questions suivantes : Puis-je être sûr que ma fonction est correctement développée si je ne suis pas capable d’identifier un cas qui est représentatif ? Ai-je bien identifié tous les cas limites ?

C’est là qu’il devient intéressant de se pencher sur le property based testing.

C’est quoi le Property Based Testing (PBT) ?

L’idée est simple : identifier et tester des invariants. Comprenez quelque chose qui sera toujours vrai, quelles que soient les données que vous fournissez à votre algorithme.

Pour cela, il faut utiliser un framework qui va générer des données aléatoires et vérifier si l’invariant reste vrai. À chaque exécution de votre suite de tests, celui-ci va tester différentes combinaisons (généralement une centaine). Il est important de noter qu’un test de PBT en succès ne signifie pas que l’implémentation est correcte, il veut juste dire que le framework n’a pas su mettre en défaut l’implémentation. Il est tout à fait possible que celui-ci trouve un cas limite après plusieurs heures, jours, semaines, mois…

Ok, et si un test échoue ?

Si le framework arrive finalement à trouver un cas limite, il existe trois possibilités :

• le code de production n’est pas correct
• la façon dont l’invariant est testé n’est pas correcte
• la compréhension et définition de l’invariant ne sont pas correctes
  

Il est important d’avoir cette réflexion dès qu’un cas est identifié. Quoi qu’il en soit, le framework est capable de vous donner les données utilisées pour mettre à mal votre code, vous pouvez donc facilement écrire un TU classique pour reproduire le cas.

Un bon framework de PBT est capable de faire du shrinking. Une fois le cas limite identifié, celui-ci va travailler sur les données utilisées pour essayer de les simplifier au maximum tout en reproduisant l’erreur. Ceci nous facilite l’effort d’analyse : imaginez une fonction qui prend une liste en argument, est-ce ma liste de 250 éléments ou juste un élément qui plante mon code ? S’il s’agit d’un élément, le shrinking peut l’isoler.

C’est quoi un invariant ? Un exemple ?

C’est à la fois tout l’intérêt de cette méthode de test, mais aussi toute sa difficulté. Il faut être capable de raisonner sur le métier de son application pour pouvoir en faire émerger des règles.

Un des premiers exemples que l’on peut rencontrer est celui de l’addition. Celle-ci a trois propriétés :

• L’identité : x + 0 = x avec 0 comme élément neutre
• L’associativité : (a + b) + c = a + (b + c)
• La commutativité : a + b = b + a
  

Vous retrouvez également ces propriétés avec la multiplication, seul l’élément neutre change. Ces exemples sont très mathématiques (et peu intéressants), mais ce n’est pas le cas de toutes les propriétés, celles-ci peuvent prendre diverses formes.

Petite appartée, les exemples qui suivent sont écrits en F# avec FsCheck. J’ai volontairement  choisi un “mauvais” exemple métier puisqu’il est envisageable de tester tous les cas de manière unitaires, mais il me paraît très adapté pour illustrer ce qu’est un invariant.

Pour cet exemple, j’ai décidé d’écrire un petit programme qui doit me dire quelle est la main gagnante entre deux mains de deux cartes. Il s’agit d’une version simplifiée du Poker, si vous ne les connaissez pas, voici les règles :

• si les deux mains sont équivalentes, alors il y a égalité
• une paire gagne sur une main mixte (main avec deux cartes différentes)
• s’il y a deux paires, la paire avec la meilleure carte gagne
• s’il y a deux mains mixtes :
  • on compare la carte la plus forte de chaque main
  • si les cartes les plus fortes sont identiques, on compare les cartes les moins fortes
• l’As est la meilleure carte et le deux la moins bonne

Je vous laisse quelques secondes pour trouver des invariants…

Vous avez trouvé ? Il s’agit tout simplement de la liste de règles que je viens d’énoncer : celles-ci sont toujours vraies.

Ok, prenons la première règle : “si deux mains sont équivalentes, alors il y a égalité”. Pour cela, je laisse le framework me générer deux cartes aléatoires (seule la valeur de la carte importe ici) qui constituent les deux mains :

On peut aussi tester qu’une paire est toujours meilleure qu’une main mixte. Dans ce cas, on doit s’assurer que les cartes générées par le framework sont différentes. Pour cela, il est possible de poser des conditions qui, si elles sont respectées, permettent l’exécution du cas de test :

Je ne vais pas détailler l’ensemble des cas de test sur cet article, vous pouvez tenter de le refaire de votre côté. Vous pourrez trouver une solution possible sur mon github.

Certaines imprécisions

Contrairement à un TU, il n’est pas toujours possible de spécifier le résultat exact que l’on attend à l’issue d’un test de PBT. Pour répondre à ceci, j’aime beaucoup la définition proposée par Jessica Kerr.

Un test de PBT défini un cadre métier dont on ne doit pas sortir :

L’idée est d’être moins spécifique sur le résultat, l’important est de s’assurer que les impératifs métiers sont validés. Cela présente l’avantage de laisser une plus grande liberté dans l’implémentation puisque son couplage avec le test est moins important.

Si l’on souhaite tout de même tester un résultat de manière exacte, alors il faudra revenir à un test unitaire avec un résultat hard-codé.

Pour conclure

On peut trouver certains inconvénients au PBT, comme des temps d’exécution un peu plus longs que des tests unitaires classiques, ou encore une plus grande difficulté à écrire ces tests.

Mais vous l’aurez compris, le PBT améliore notre compréhension de l’application puisqu’il pousse à raisonner à des niveaux d’abstraction plus élevés que ce que nous incite à faire des tests unitaires classiques : “une paire est meilleure qu’une main mixte” est à un niveau d’abstraction supérieur à “une paire de 5 est meilleure que la main avec le 8 et le roi”.

Enfin, parce que le code est validé par un grand nombre de cas différents, le PBT améliore également la qualité de notre code ainsi que la confiance que nous avons dans celui-ci.

Si après la lecture de cet article le PBT vous intéresse, vous pouvez également regarder ce talk de Jessica Kerr ou encore celui de Romeu Mourra qui sont pour moi des références sur ce sujet.