[OCTO] Article de Blog - Le brownfield n’est pas du code legacy

le 10/05/2024 par Bruno Boucard
Tags: Software Engineering, Bonne Pratique, Architecture, Craft, Back

Le brownfield n’est pas

du code legacy

Cultivons notre jardin - Candide

Voltaire nous inspire

Candide nous pose une question sur la définition du code brownfield. Cultivons notre jardin, est une formule d’altruisme emprunté à Voltaire (Candide) qui convient d’appliquer au code afin de dégager plus de valeur auprès de nos utilisateurs. Il nous appartient d’agir et de rendre meilleur notre « jardin », de faire prospérer notre terre, d’y travailler pour récolter de meilleurs produits attendus par nos utilisateurs. L’allégorie du jardin, est une manière de qualifier l’état du code dans le monde de l’artisanat logiciel :

  • Un Code est dit greenfield quand le produit est naissant, mais le produit n’a jamais connu de livraison en production.
  • Un Code est dit brownfield quand le produit est déjà en production et avec des dysfonctionnements et quelques anti-patterns au niveau du code.

C’est donc une manière de catégoriser les bases de code au sein d’un produit ou d’un système d’information. Cependant, la connotation du code legacy que renvoie le brownfield est-elle justifiée ?

Confusion entre brownfield et code legacy !

Les faits sont là, le brownfield règne sans partage dans les entreprises. C’est sans doute la caractéristique la plus commune dans le monde de l’IT. Par abus de langage, on appelle souvent Code Legacy une base de code brownfield l. Caractéristiques d’un Code Legacy :

  • Un code difficile à faire évoluer, car souvent illisible, fortement couplé, non testé et souvent non testable.
  • Contient, une collection d’anti-patterns de code, qu’on appelle code smells.
  • Les décisions fonctionnelles sont impossibles à prendre, car le code est difficile à comprendre, ce qui retarde cruellement les mises en production.
  • Une charge cognitive importante qui s'active et à laquelle chacun fait face pour tenter de déchiffrer du code entremêlé où tout est mélangé; c’est une véritable souffrance mentale, qui finit par démotiver l’équipe concernée.

La majorité des développeurs sont démunis face à l’adversité d'un code legacy. Le brownfield et le code legacy sont souvent associés, car l’essentiel des produits brownfields est composé de code legacy, mais ce n’est pas une fatalité.

Et si nous changions de perspective

Nous sommes biaisés par nature, osons faire un pas de côté. Si vous changiez d’angle d’attaque afin d’y faire d’autres constats ?

  • Un produit greenfield n’est pas en production et n’a pas encore de « vrais » utilisateurs. Un produit qui n’a jamais franchi le champ de bataille d’une mise en production, ne délivre pas de valeur auprès de ses utilisateurs. En d’autres mots, se lancer dans une réécriture en mode greenfield engendre des risques.
  • Un produit brownfield est quotidiennement en production, sollicité par une audience qui ne manquera pas de faire des feedbacks, c’est donc bien votre code brownfield qui est certes parfois fragile, mais qui rencontre ses utilisateurs quotidiennement. Votre brownfield incarne les usages fonctionnels que vos utilisateurs connaissent et pratiquent régulièrement. Toute modification portée sur un produit legacy a un impact sur son audience. C’est bien votre brownfield qui touche vos utilisateurs et non votre greenfield.

Parlons des coûts :

  • Le Produit greenfield dans le cas d’une réécriture.
    • Mobilise deux équipes. Une qui maintient en condition opérationnelle le produit brownfield et une autre qui développe les fonctionnalités du produit brownfield dans le nouveau produit greenfield.
    • Le maintien des deux équipes et des exécutions parallèles infère des coûts non négligeables et une organisation spécifique.
  • Le Produit brownfield doit être cultivé afin de reprendre le contrôle sur le code. Les conséquences sont
    • L’augmentation des fréquences de livraisons et diminution des dysfonctionnements.
    • Moins de changements et plus de satisfaction pour les utilisateurs,
    • L’équipe de développement retrouve des meilleurs feedbacks et un plaisir de travailler sur son produit.
    • Les coûts sont constants et prévisibles.
    • L’équipe pourrait récolter après quelques itérations un produit redevenu désirable et qui rétablira la confiance entre l’équipe de développement et les utilisateurs.

Les avantages économiques et la satisfaction des utilisateurs sur un produit brownfield sont avant tout pragmatiques. Refaire un produit en greenfield repose sur un espoir de faire mieux, mais il est risqué et coûteux.

Découvrons les approches pour prendre soin de votre brownfield.

Entretenir son brownfield

À l’instar d’un jardin que l’on cultive, le brownfield se doit d’être entretenu afin que les prochaines récoltes soient généreuses. Prendre soin de votre code n’est pas une activité spécifique, mais une préoccupation permanente. Cela peut sembler excessif, mais mon propos est mesuré. Affiner le code ne signifie pas uniquement appliquer les règles du Clean Code, c’est aussi un questionnement sur le nommage et le design général au regard du modèle qui se doit d’être simple et aligné avec le problème métier. On parle ici d’une approche et non d’une méthodologie. Pour les praticiens du Domain-Driven Design, le Model-Driven Design est l’approche de modélisation au niveau du code qu’on appelle Deep Modeling, accompagné d’une collection de patterns techniques qu’on appelle Supple Design. Le Supple Design permet d’introduire la souplesse dans le code afin de pratiquer le Deep Modeling. Cette approche permet à base d’affinements successifs en collaboration avec les experts du domaine d’obtenir un code à la fois simple, souple et aligné avec le vocable du métier. Le Model-Driven Design est le dernier étage d’une fusée qui comprend aussi :

  • Le Domain Storytelling est une approche orientée sur un flux fonctionnelle qui permet d’être très explicite sur les intentions métier. Il existe un outil graphique qui permet de s’initier de manière ludique.

  • Le Behavior-Driven Development est un moyen de transférer la connaissance des comportements métier vers l’équipe de développement.

  • Le TDD outside/in est une pratique avancée qui permet d’engendrer du code sur la base d’un test acceptation, où le code sous-jacent fera l’objet d’un développement avec le TDD inside/out.

  • Les patterns permettant de casser des dépendances fortes est un ensemble de t__echniques pour briser des dépendances sans risque__ vis-à-vis du comportement initial, au sein d’un code fortement couplé.

  • Le Refactoring de design est une collection de mouvements au niveau du code afin de corriger l’essentiel des codes smells. Les codes smells sont une collection d’anti-patterns qui permettent de poser un vocable commun sur des problèmes de design. L’objectif est d’améliorer la communication entre les développeurs et favoriser la correction de code smells.

  • Le TDD inside/out est la pratique la plus simple, pour développer en mode design émergent au niveau d’une structure de code.

  • Le Clean Code est une série de principes permettant de bonifier le code, comme les principes SOLID qui permettent d’apporter de la souplesse au code afin d’épouser de potentiels changements.

  • Les Design Patterns est une collection de solutions techniques éprouvées permettant de structurer le code de manière durable.

C’est un lourd investissement, auquel tout développeur devrait s'engager pour être en mesure de prendre soin du code du produit. Si toute l’équipe de développement maîtrise toutes ces approches, alors on parlera d’une équipe émancipée et autonome. Celui qui cultive son jardin dans la sphère logiciel, n’a pas à rougir des activités d’un jardinier professionnel.

Votre brownfield est-il vraiment en friche ?

Les situations catastrophiques du code legacy ne sont pas sans espoir. Il arrive que la situation soit à désespérer, le code est une forme de grosse boule de boue avec une équipe de développement entièrement renouvelée, sans aucune connaissance sur l’existant. Comment imaginer reprendre le contrôle dans pareil cas ?

L’approche pour reprendre en main un jardin en friche

Reprendre un jardin en friche réclame une approche et beaucoup de discipline. Un produit au sein d’un SI brownfield demande de respecter quelques étapes importantes. L’objectif est d’adopter une démarche progressive où tous les risques sont calculés :

  1. Explorer les éléments saillants. Généralement l’équipe support connaît relativement bien les produits de l’entreprise. Et dans le pire des cas, s’il n’y a vraiment plus personne, comment retrouver les besoins métier ?

Avec l’aide du management, rechercher toutes les personnes, équipes de développement, Support ou utilisateurs, qui pourraient participer à un atelier d’EventStoming de type Big Picture. L’objectif est de retrouver des narrations fonctionnelles. La qualité de l’information peut être imprécise, elle permet d’obtenir un début de connaissance, que nous allons améliorer au fil de l’eau.

  1. Découvrir les premières narrations. Commencer des recherches dans le code, afin de retrouver les comportements décrits. L’intérêt de repartir d’un brownfield est que la “golden source” c’est le code.

Il faut donc confronter le code aux propos énoncés par les quelques sachants (experts du domaine). Cela peut prendre une semaine ou même un mois sur un morceau du SI.

  1. Organiser les équipes. Chaque équipe dispose d’un tableau blanc, où nous exprimons toutes nos pistes, nos remarques, et notre vocable métier que nous souhaitons utiliser en collaboration avec l’expert du métier. Nous explorons profondément le code à la recherche d’indices, qui viendraient confirmer les propos des experts du métier.

L’organisation d’un remaniement de code à grande échelle est essentielle. Répartir les experts par équipes (dans le cas d’un SI). Organiser chaque équipe en mob programming, afin de raconter les narrations fonctionnelles de ce qu’ils observent dans le code. L’objectif de l’équipe de développement est de traduire, à l’expert du domaine, ce que le code fait réellement au regard d’un comportement métier.

  1. Obtenir des narrations fonctionnelles. La narration est au cœur de la communication humaine. Pourquoi ne pas l'utiliser pour surmonter des malentendus coûteux lors de la conception de logiciels ? En racontant et en visualisant des histoires, les experts du domaine et les membres de l'équipe rendent tangibles les processus métier et les connaissances du domaine. L’approche Domain Storytelling permet à chacun de comprendre les personnes, les activités et les éléments de travail concernés. Cette approche permet de creuser davantage sur les flux fonctionnels qui résonne bien après le premier Event Storming Big Picture.

Le Domain Storytelling est une technique permettant de transformer la connaissance du domaine en un produit aligné avec les attentes des utilisateurs. Il rassemble des experts du domaine et des équipes de développement. Les experts du domaine peuvent immédiatement voir si l’équipe de développement est sur la même longueur d’ondes qu’eux.

  1. Découper du code en modules indépendants. Nous devons briser les dépendances aux frontières fonctionnelles afin de forger un module métier qui deviendra un service spécifique. L’approche consiste à appliquer les patterns de l’ouvrage de Michael Feathers pour ne rien casser dans un premier temps.

Les techniques présentées reposent sur l’ajout d’une ouverture (injection dépendance) du code, tout en conservant l’API existante. Bien évidemment, on posera les tests respectifs afin de s’assurer que nous n’avons rien cassé. Ce point est important, car c’est justement parce que le code n’est pas testable que nous utilisons ces techniques. Vous l’aurez compris, cette approche connaît une courte période sans filet de sécurité, mais il n’y a pas d’autres approches lorsque le code n’est pas testable par défaut.

  1. Remanier le design du code. Redresser toutes responsabilités, corriger les codes smells, rendre le code souple et explicite fonctionnellement. Dans cette étape, on s’intéresse particulièrement à la bonne répartition des responsabilités.

On déplace des portions de code, on crée de nouvelles entités, afin d’obtenir une répartition des comportements où rien n’est anémique ou obèse. L’expert du domaine est très sollicité afin d’expliquer tous les comportements. De nouveaux tests locaux sont mis en place pour valider nos assomptions. Il arrive parfois qu’une grosse partie du code ne soit plus utilisée. Après confirmation de tous les sachants, experts du domaine métier, nous prenons la décision de retirer tout le code inutile.

La présentation d’une approche énumérée peut sembler contradictoire. Vous pourriez penser à une méthode pour affronter le refactoring d’un système d’information. Pour clarifier la motivation de chaque étape, j’ai introduit un ordre exploratoire. Du plus flou au plus précis. Mais, notre cerveau ne fonctionne pas de manière linéaire. Il est parfaitement légitime de revenir à la phase de découverte du métier, avec l’Event Storming Big Picture par exemple, car à la lumière d’une nouvelle compréhension, on éprouve le besoin de creuser à nouveau un point précis.

Avec les premiers succès, arrive la confiance

À la fin de ce travail collectif intense, nous sommes en mesure de poser un premier test d’intégration avec succès. C’est le moment où nous vous conseillons de célébrer afin de retrouver un nouvel élan pour la suite. L’expérience nous a montré que la confiance des équipes et des experts métier après le succès du premier test d’intégration était totalement différente. Les premières étapes sont longues et épuisantes, et certains doutent du résultat. Mais, après ce premier succès, ceux qui doutaient sont souvent les plus engagés pour aller plus loin. Par exemple, en adoptant l’approche Behavior-Driven-Development lors des prochains tests d’intégration. La confiance est très importante dans ce type d’approche. Après un ou deux mois où toutes les équipes techniques ont été mobilisées, le code a retrouvé une bonne santé, tout le monde a retrouvé le sourire, utilisateurs compris.

Une démarche qui fait honneur au brownfield

Être fier de son code brownfield propre et écoresponsable. Si nous réactualisons le propos de Voltaire, r__endre meilleur notre « brownfield »__ permet de faire prospérer notre base de code, d’y travailler pour de meilleurs produits attendus par nos utilisateurs. En d'autres mots, les mauvais brownfield n’existent pas, il n'y a que des brownfield mal entretenus. Il ne tient qu'à vous de changer vos codes pollués de code smells en code propre. Cultiver son jardin, c’est en prendre soin, afin d’en tirer des bénéfices sur le long terme. Organiser un atelier de type Event Storming Big Picture, au sein de votre domaine métier, puis découper votre domaine en sous-domaine, enfin prioriser les sous-domaines qui vous semblent importants de traiter pour cette année. Cet article n’a pas la prétention de traiter de toutes les techniques de refactoring, mais sachez qu’il en existe suffisamment pour mettre fin à tous types de code legacy.

Vous disposez d’une approche qui nécessite de nombreuses compétences qu’il vous faudra travailler au préalable. Mais une fois ces techniques maîtrisées, vous aurez le loisir d’appliquer des approches qui vous permettront de gérer votre catalogue de produits avec sérénité.

Une démarche écoresponsable

Les produits brownfield reposant sur du code legacy sont souvent envisagés comme des rebuts juste bons à être réécrits. Le fait que les produits brownfield aient déjà une audience est une chance. Investir dans la remédiation du code legacy afin de faire de votre brownfield un avantage concurrentiel est une démarche vertueuse. Cette manière de réincarner le brownfield est une démarche écoresponsable. Vous conservez la même technologie, les mêmes matériels, les mêmes langages de programmation, et vous n’aggravez pas votre empreinte carbone. Tout votre écosystème est conservé. La balle d’argent n'existe pas, investir pour transformer votre code legacy en code propre, découplé, et livrable continuellement est certes du travail, mais en retour le produit est évolutif et les utilisateurs sont confiants dans leur produit.

Cette approche vous rappelle certainement le principe d'erooM énoncé par Tristan Nitot. Dans une époque où tout nous pousse vers plus écoresponsabilité, il est bon de rappeler que ce n’est pas juste un principe, mais une réalité pour chacun de nos métiers. Ne délaissez plus vos produits brownfield ! Cultiver vos produits brownfield afin d’engendrer des économies et rendre heureux vos utilisateurs sans impacter la planète.

Quelques références

Design Patterns

Clean Code

Test-Driven Development

Refactoring

Behavior-Driven Development

Domain-Driven Design

EventStorming

Domain Storytelling

Mob-Programming