Pascal Le Merrer - Software Crafter Freelance

Nous avons appliqué une manoeuvre de Conway inversée, qui consiste à aligner l'organisation des équipes avec l'architecture désirée.

Après la clarification du métier lors d'ateliers d'Event Storming, j'ai identifié l'architecture cible à l'aide du Domain Driven Design stratégique. J'ai regroupé les sous-domaines en fonction du nombre d'échanges qu'ils avaient entre eux. Ainsi, chaque équipe en charge d'un groupe de sous-domaines était peu dépendante des autres équipes.

Puis, le management a réorganisé les équipes, afin qu'elles soient alignées avec cette nouvelle architecture.

L'étape suivante consistait à réorganiser le code pour qu'il corresponde à l'architecture cible. J'ai défini, avec des collègues, une stratégie de tests, et la nouvelle structure à donner au code pour qu'elle soit plus claire et homogène.

Enfin, j'ai rédigé un guide de migration expliquant comment passer le code existant vers sa nouvelle organisation, puis aidé des équipes à l'appliquer, lors de séances de mob programming.

Ces changements ont amélioré significativement le quotidien des développeurs, qui ont pu monter en compétence sur les sous-domaines dont ils avaient la responsabilité.

En procédant par petit pas, j'ai entièrement revu le code de cette application. J'ai, comme à mon habitude, employé le Développement Piloté par les Tests (TDD), ce qui a amélioré significativement la couverture de code. J'ai réalisé la phase finale de ce refactoring en pair programming avec des collègues, afin qu'ils puissent reprendre ce projet sereinement. Enfin, j'ai mis à jour la documentation, puis ajouté un dashboard dans Datadog afin d'améliorer l'observabilité. La mise en production n'a révélé aucun bug.

Après une période d'observation, j'ai organisé des rétrospectives, ce qui n'avait pas encore été fait dans le cadre de ce projet. Cela a résolu les plus gros dysfonctionnements de l'équipe.

Ma première contribution au projet a été de rédiger une procédure d'installation sur les postes de développement (qui ne pouvait pas être automatisée), car rien n'existait de ce point de vue. A cette occasion, j'ai sécurisé le partage des mots de passe.

La couverture du code étant quasi inexistante, j'ai mis en place un test de caractérisation —AKA Golden Master test— afin de pouvoir faire des modifications en toute sécurité. Puis j'ai mis en place une vérification automatisée du contenu des commits. J'ai activé une à une la vingtaine de règles qu'elle comportait, et appliqué petit à petit ces règles à l'ensemble du code. Cela a permis une amélioration significative de la qualité du code présent et futur.

Une seconde étape, après avoir découvert le code lors de la précédente, a été de remettre en marche les tests automatisés. Puis de les accélerer et de les fiabiliser. Il s'agissait essentiellement de tests d'intégration, car le code métier faisait de nombreux appels à des API externes. J'ai fait en sorte que le temps d'exécution des tests soit divisé par 7.

J'ai aussi analysé les performances du code métier. Cela m'a incité à remplacer les appels synchrones par des appels asynchrones, ce qui a multiplié par deux la rapidité d'exécution.

Une dernière contribution importante à ce projet a été de définir et mettre en oeuvre une architecture scalable, pour résoudre les problèmes de montée en charge. Le passage d'un monolithe à une architecture distribuée avec des files d'attente et des mécanismes de cache ont résolu les contentions observées.

J'intervenais sur toute la partie technique : management, méthodologie, choix technologiques, architecture, sécurité, développement Front-End, développement Back-End, base de données, déploiement. J'ai mis en place la documentation, structurée selon les principes de Diátaxis. En développant de l'outillage, j'ai fait en sorte que l'expérience développeur soit excellente, afin qu'un nouveau venu puisse être opérationnel en moins d'une demi-journée, puis soit efficace au quotidien. Je m'assurais également que l'ergonomie des IHM soit bonne.

Ce projet était exigeant en termes de performances. Il nécessitait de surveiller en parallèle la présence d'une centaine de patterns décrit dans le DSL (Domain Specific Language) utilisé par les experts métier. De plus, l'analyse a posteriori nécessitait de traiter de gros volumes de données dans un temps le plus court possible. J'ai donc choisi un langage offrant de bonnes performances, tout en étant abordable par l'équipe (Go), et travaillé particulièrement l'algorithmie. J'ai écrit un compilateur pour le DSL, afin d'en optimiser la vitesse d'exécution. Les retours flatteurs du client ont confirmé la pertinence de ces choix.

En tant que tech lead, j'ai été le principal concepteur de l'architecture, qui posait de sérieux challenges en terme de scalabilité, mais aussi d'intégration d'applications open source. En effet, parmi les applications tierces qui réalisaient diverses analyses, une n'était pas prévue pour être utilisée comme bibliothèque : il s'agissait d'une application web complète, avec un front-end, un backend et une base de données. La solution que j'ai trouvée consistait à démarrer un container Docker à partir de notre application (donc faire du _Docker in Docker_) pour exécuter cette application tierce.

Le reste de l'architecture était de type hybride : un serveur pour le front-end et l'API, une base de données unique (c'était suffisant), une work queue pour déclencher les jobs de façon asynchrone, et de multiples workers pour exécuter les différentes analyses. Ainsi qu'une machine virtuelle pour l'exécution d'une application par l'utilisateur.