DEV Community: Jean-François Le Foll

Pourquoi écrire des Documents de Choix d'Architecture ? (Architecture Decision Record)

Jean-François Le Foll — Wed, 16 Jun 2021 13:50:22 +0000

Tout d'abord qu'est-ce qu'un ADR ?

La base de notre métier est de faire des choix : choix de technologie, choix d'architecture, choix d'implémentation...
Certains sont plus impactants que d'autres.

Le but d'un ADR est de documenter et de tracer le raisonnement derrière ces choix, en gardant le contexte du niveau de connaissance et de maîtrise du sujet au moment de ce choix.
Quel était mon problème ? Quelles étaient les différentes solutions envisagées ? Quels éléments nous ont amenés vers ce choix ?

Quel formalisme pour un ADR ?

Un ADR, c'est un document texte, facile à partager au sein de l'équipe (dans un wiki ou dans un repository par exemple).

C'est un document immuable, il n'a pas vocation à être mis à jour, au mieux le statut peut changer si cette décision est remplacée par une autre.

Le titre de l'ADR doit être explicite :

choix_langage_backend
choix_base_de_données
gestion_des_dates
format_des_logs

Décrivez clairement le contexte, pourquoi cette décision se pose, quel problème / contrainte essayons nous de résoudre ?

Décrivez le raisonnement qui vous amène à votre décision, n’hésitez pas à lister les expérimentations que vous avez faites, les articles sur lesquels vous vous êtes basés, tout ce qui vous permettra de comprendre votre décision si vous relisez l'ADR dans 6 mois.

Ce sont pour moi, les trois parties les plus importantes d'un ADR : titre, contexte, raisonnement/décision

Vous pouvez également décrire les conséquences qu'aura ce choix (par exemple nouvelle contrainte ou nouvelle complexité).
Vous pouvez aussi ajouter un statut à votre ADR (accepté, rejeté, déprécié, remplacé...).

Vous pouvez trouver des modèles d'ADR beaucoup plus détaillés sur internet, mais au final c'est vous et votre équipe qui allez les écrire et les lire donc choisissez les rubriques qui sont pertinentes pour vous.

Conclusion

Dans un contexte en constante évolution, où nous apprenons de nouvelles choses régulièrement (sur les besoins des utilisateurs, sur les technos, ...), pouvoir pourquoi et comment tel ou tel choix a été fait est important pour une équipe et sa compréhension de son produit.
C'est aussi une source d'information pratique pour les nouveaux arrivants dans l'équipe.

D'un point de vue personnel, chez Avalon Lab, nous sommes des prestataires, nous accompagnons des entreprises et porteurs de projets qui n'ont pas forcément d'équipe technique.
Dans ce cas, les ADR nous permettent de documenter tous les choix technologiques et d'architectures que nous prenons, car finalement ce n'est pas nous qui allons vivre avec ces choix, mais bien les développeurs·euses qui seront recruté·e·s plus tard par le client.
Les ADR leurs permettrons de comprendre comment et pourquoi le produit est ce qu'il est.

Pour aller plus loin sur le sujet des ADR :

ADR GitHub organization

Architecture decision record (ADR)

Cover Photo by Kaleidico on Unsplash

CTO d'amorçage / Team as a Service, qu'est-ce que c'est ?

Jean-François Le Foll — Wed, 13 May 2020 14:57:45 +0000

Le principe du CTO d'amorçage / Team as a Service est d'intervenir, à minima en binôme, dans une structure sans compétence disponible en développement logiciel (développement, gestion de projet, etc ...) afin de démarrer un projet, d'accompagner le client sur le développement et la conception de son produit ou MVP, de poser les bases d'une architecture saine et éventuellement de l'aider dans son recrutement de développeurs.

Nous avons abordé notre action de CTO d'amorçage / Team as a Service suivant trois axes : tout d'abord d'un point de vue apprentissage fonctionnel, puis d'un point de vue méthodologique et enfin d'un point de vue technique.

Apprentissage fonctionnel

Le métier de ce client était quelque chose de nouveaux pour nous, nous avons donc fait plusieurs ateliers d'Event Storming avec l'expert métier.

Le but de ces ateliers est multiple :

Découvrir le langage métier de l'expert (et donc partager le même langage entre le code et la réalité métier)
Découvrir le fonctionnement de l'outil, le process métier, les besoins
Avoir une première idée / ébauche de la conception du logiciel

Ceci s'inscrit dans une approche Domain-Driven Design (DDD) ou Conception pilotée par le domaine (métier).

Ces ateliers sont refaits régulièrement, par exemple pour présenter un nouveau use case afin d'en explorer le fonctionnement.

Méthodologie

Chez Avalon Lab, nous sommes convaincus par les principes de développement agile.

Nous avons un fonctionnement assez proche de la méthode eXtrem Programming :

Contact étroit avec l'expert métier
Livraison fréquente
Feedback régulier
Binômage
Développement piloté par les tests (TDD)
Intégration et déploiement continue
Rythme soutenable
Conception simple

Intervenant dans un contexte "remote" dès le départ, l'expert métier n'étant pas localisé avec l'équipe de développement, nous avons mis en place plusieurs outils afin de collaborer efficacement en fonction des contraintes client :

Gitlab (gitlab.com), pour la gestion de projets (user stories, bug tracker, milestone)
Miro (miro.com), un tableau blanc collaboratif (schémas, atelier post-it)
Skype ou autre, notamment pour faire des démos, via le partage d'écran.

Technique

L'approche DDD, notamment au travers d'ateliers type Event Storming, nous permet de mieux concevoir l'application.

L'application est découpée en domaine, unités logiques correspondant à un regroupement logique de sens métier.

Pour implémenter ces domaines, nous avons suivi les principes de l'architecture hexagonale où tout le code, correspondant aux règles métier, est correctement isolé de l'extérieur (base de données, web services, interface utilisateur) et n'est pas "pollué" par du code provenant d'un quelconque framework ce qui rend les choix de solutions type framework moins définitive et impactant.

Aujourd'hui, on sait que les fonctions principales d'un logiciel concernent principalement de la présentation de données (certains parlent de 80 % lecture de données et 20 % écriture de données).

Partant de ce constant, nous avons adopté le pattern CQRS (Command Query Responsibility Segregation) qui sépare les tâches d'écriture (command), des tâches de lecture (query) et ayant des modèles de donnés séparés.
[Ce pattern peut être étendu avec le principe d'Event Sourcing lorsque le métier requiert un traçage / audit des différentes actions.]

Toutes les décisions d'architectures / de choix techniques sont tracés dans des documents de décision d'architecture (Architecture decision record - ADR).

Architecture SI

L'architecture physique du SI évolue en fonction des besoins métier, tout en se basant sur les principes généraux des 12 factors

Nous avons d'un côté un frontal web (SPA) et de l'autre un backend métier.

Pour le backend métier, notre principe de base est de démarrer avec un monolithe, comme nous adoptons une démarche DDD, ce monolithe embarque nos domaines qui eux sont indépendants et correctement séparés.

L'avantage est de simplifier la phase de construction de l'application ainsi que sont déploiement et son monitoring tout en gardant la flexibilité de pouvoir sortir un domaine afin de répondre à un nouveau besoin ou à des contraintes de charges spécifiques.

De plus, cette architecture est déclinée en deux versions :

Test/intégration => construite directement depuis les sources, à chaque modification (Continuous Deployement), permet aux développeurs et à l'expert métier de tester sur un environnement déployé.
Production => construite et déployée à la demande, ouverte aux clients.

Technologie

Dans l'optique d'aider le client à recruter des développeurs et un CTO, nous sommes partis sur des technologies fiables, connues et pour lesquelles il est facile de recruter tout en respectant nos critères de qualités.

VueJS / Web Component (lit-element)
Java 11
Gitlab : gestion de code et ci/cd
Datadog : collecte et analyse des logs applicatives / monitoring [peut être remplacé par Elastic Stack]
Clever Cloud : gestion de l'infrastructure
Izanami : Configuration partagée, features flipping
Warp10 : Base de données de séries temporelles
Cellar / AWS S3 : stockage de fichiers
SonarCloud : Analyse qualité du code

Cet article vous a intéressé, vous avez envie d'en savoir plus ou par rapport à vos besoins ?

N'hésitez pas à nous envoyer un mail à contact@avalon-lab.coop

Server-Sent Events démystifiés, avec un cas concret.

Jean-François Le Foll — Wed, 11 Mar 2020 16:18:28 +0000

Préface

Avant d'aller plus loin, expliquons d'abord ce que sont les Server-sent Events (SSE pour les intimes).

Il s'agit d'un canal unidirectionnel permettant au serveur d'envoyer des messages à un navigateur.

C'est une techno ancienne, qui date de 2009-2010 et est disponible au grand public depuis les versions 6 de Chrome et Firefox, mais qui a été un peu mise de coté à l'arrivée des WebSockets.

Objectif ?

Le but de cette démo est de construire un cas concret d'utilisation de SSE.
Beaucoup d'articles ou de démos que j'ai pu trouver ne montrent guère autre chose qu'un event pré-construit envoyé à intervalle régulier, pas grand-chose à voir avec la réalité.

Dans cette démo, nous allons construire une API Rest, qui poussera un message dans un RabbitMQ en mode Fan-out.
De l'autre coté, nous aurons un serveur nodejs qui écoutera les messages et poussera un SSE au bon client de la webapp servi par le nodejs.

Dans l'objet poussé sur l'endpoint, nous avons un client ID, ce qui permet d'avoir plusieurs onglets ouverts sur la web app et ainsi voir que les SSE arrivent seulement au bon client.

Le code :

L'API Rest

Je ne vais pas entrer ici dans les détails de l'API Rest, c'est une API Java (Jooby 2) qui sert de producer RabbitMQ.

La Web App

Il s'agit d'une simple page html avec un Web Component (les dépendances sont chargées directement avec Pika, cela peut prendre quelques secondes).

Pour se connecter à un endpoint SSE, rien de plus simple, il suffit de définir un EventSource qui prend en paramètre l'url de la source.

const sseSource = new EventSource("/event-stream/" + this.clientId);

Dans notre cas, nous ajoutons dans l'url le clientId du client connecté.

Sur cet objet EventSource nous allons venir définir un event listener, le but est de ne réagir qu'aux messages de type notif :

    sseSource.addEventListener("notif", e => {
      this.count = this.count + 1;
      this.notifications = [...this.notifications, e.data];
    });

Ce code nous permet d'incrémenter un compteur et d’alimenter un tableau avec le message de l’événement.
C'est tout pour la partie front.

La partie serveur NodeJs

1) Le point d'entrée SSE

Ici on utilise ExpressJS car il n'y rien de particulier à faire pour mettre en place la ressource SSE :

app.get("/event-stream/:clientId", (req, res) => {
  let clientId = req.params.clientId;

  res.writeHead(200, {
    "Content-Type": "text/event-stream",
    "Cache-Control": "no-cache",
    Connection: "keep-alive"
  });
  res.write("\n");

  connections[clientId] = res;

  console.log("Connection open for client : " + clientId);

  req.on("close", () => {
    delete connections[clientId];
  });
});

Ici nous définissons notre ressource GET "/event-stream/:clientId" avec un paramètre clientId qui nous permet de stocker l'objet response sur lequel envoyer les messages :

    connections[clientId] = res;

Mais avant de stocker cette réponse, il faut la "configurer" pour le SSE :

  res.writeHead(200, {
    "Content-Type": "text/event-stream",
    "Cache-Control": "no-cache",
    Connection: "keep-alive"
  });

Pour résumer cette partie, à chaque fois qu'un client fait un GET sur notre ressource SSE, nous stockons dans un objet sont clientId et l'objet response afin de lui pousser des messages ultérieurement.

2) Le consumer RabbitMQ

Afin de pouvoir se connecter sur le RabbitMQ, nous allons avoir besoin de la dépendance vers la librairie amqplib

   const amqp = require("amqplib/callback_api"); // => fonctionne avec des callback
// ou
   const amqp = require("amqplib");  // => fonctionne avec des promesses

Au démarrage du serveur nodejs, on ouvre une connexion vers RabbitMQ

amqp.connect("amqp://localhost", (error0, connection) => {})

Dans cette connexion, on va créer un channel sur notre Exchange et une Queue (Cf dépôt Github pour le code de cette partie).

Ce qui nous intéresse ici, c'est de voir comment on consomme les messages.

      channel.consume(
        q.queue,
        msg => {
          if (msg.content) {
            let data = JSON.parse(msg.content.toString());

            console.log("New message for client : " + data.clientId);
            let clientRes = connections[data.clientId];

            if (clientRes) {
              clientRes.write(`event: notif\n`);
              clientRes.write(`data: ${data.content}\n\n`);
            }
          }
        },
        {
          noAck: true
        }
      );

On va parser le message pour en récupérer le contenu, grâce au clientId du message, on récupère notre objet response qui correspond.
Si elle existe, on vient écrire une première ligne avec le type d'événement clientRes.write('event: notif\n'); (pour rappel notre front n'écoute que les messages notif).
Puis une seconde ligne avec le contenu du message clientRes.write('data: ${data.content}\n\n');

Et voilà, nous avons poussé notre message dans notre stream d'événements.
Le front réagi, incrémente le compteur et affiche le message !

J'espère que maintenant l'utilisation des SSE est un peu plus claire et concrète pour vous aussi :)

Le code de la démo complète est disponible sur GitHub :

Avalon-Lab / realtime-webapp-sse-rabbitmq

Demo WebApp temps réel avec SSE et RabbitMQ

Retour sur SoCraTesDay à Rennes

Jean-François Le Foll — Wed, 06 Nov 2019 14:56:36 +0000

Vendredi 14 juin, j'ai eu la chance de participer à la première SoCraTesDay à Rennes.

Un forum ouvert d'une journée, autour du développement logiciel, des tests, de la qualité du code et du software craftsmanship.

Un forum ouvert ? Qu'est-ce que c'est ?

Un forum ouvert est une façon de structurer une conférence, sans speakers, où les participants construisent eux-mêmes leurs programmes en fonction de leurs connaissances et de ce qu'ils ont envie d'apprendre / échanger.

Une conférence dont vous êtes le héros !

Chacun affiche le(s) sujet(s), dont il a envie de parler sur un tableau (appelé Marketplace), aux intersections entre des créneaux horaires et des espaces nommés.

Marketplace du SoCraTes Rennes :

Liquid error: internal

Cet "agenda" continu de se construire au fil de la journée. En fonction des discussions, de nouveaux post-it vont être ajoutés pour approfondir certains sujets par exemple ou parce qu'une session a fait émerger une nouvelle idée à sur laquelle un groupe a envie de discuter.

Les règles de ce genre d'événement sont assez simples. En plus du respect et de la bienveillance, on retrouve également :

Quand c'est fini, c'est fini : il est important, à la fin de son créneau horaire, de s'arrêter pour laisser la place au groupe suivant. Ça ne veut pas dire pour autant qu'il faille arrêter la discussion, au contraire, il suffit simplement de trouver un espace libre pour continuer
La loi des deux pieds : à tous moments, vous êtes libre de suivre vos deux pieds pour quitter une session afin de rejoindre une autre session ou autre.

SoCraTesDay, on y parle de quoi ?

Et bien c'est ça qui est vraiment intéressant c'est qu'on y parle de tout ce dont les participants ont envie.

Personnellement, j'ai tendance à découper les sujets en trois catégories.

La technique, les outils

Lors de ce SoCraTest, il y a eu des sessions d'introductions à ELM et Rust, des katas de refacto de code legacy, des discussions autour des backends js, du code source de spring boot, de la gestion des logs avec ELK.

La conception, l'architecture, les méthodes

Il y a des sessions sur le BDD (pas les bases de données, mais le Behaviour Driven Development), sur le DDD en mode introduction sur les concepts stratégiques puis comment démarrer concrètement après, sur le TDD (voilà on fait le tour des xDD ;) ), sur les archis hexagonales, les archis micro-frontend, sur les tests e2e, sur la stabilité des logiciels, sur l'agilité (notamment sur les Scrum Masters qui ne font pas de dev).

La pratique, le métier, l'éthique

Enfin, il y a eu des discussions autour de la veille, du bonheur au travail, de qu'est-ce qu'un bon développeur, sur le mentoring, alternative au salariat ? (indépendant, monter sa boite), sur l'impact écologique des logiciels et le low tech et un retour d'expérience sur une organisation horizontale.

À quoi a ressemblé ton SoCraTesDay ?

Le temps de discuter un peu, de regarder la construction du market place, je suis arrivé sur la fin de la discussion concernant le principe de micro-frontend.

J'ai enchaîné ensuite sur la session DDD que j'avais proposé, car c'est mon intérêt du moment, remettre le métier du client au cœur de notre pratique et de notre code, parler le même langage que l'expert métier, sont des choses que je trouve importantes et presque toute ma veille du moment tourne autour de ce sujet.

Cette session était plutôt basée sur les concepts stratégiques : comment exprimer les domaines, contextes métiers, notamment via des Event Storming. Elle a suscité une deuxième session, plus "tactique" où on a parlé d'User Stories Mapping, de slicing horizontal, d'architecture à Uses Cases.

J'ai terminé la matinée par les sessions sur les Object Calisthenics et comment construire une roadmap dans une approche MVP.

L'après-midi, j'ai participé à la session sur les alternatives au salariat. Le groupe était assez hétérogène avec des salariés de boites classiques, de boites "un peu plus ouvertes", des indépendants (ou ex-indé) et moi en SCOP.

On a eu beaucoup d'échanges très constructifs, des retours d'expériences enrichissants car on n'avait pas tous le même vécu, rencontré les mêmes problématiques.

Au-delà du market place, il y a aussi toutes les discussions impromptues dans l'espace commun, l'occasion de faire plein de rencontres intéressantes.

En conclusion ?

Il s'agissait de ma seconde journée de forum ouvert après NewCrafts Bordeaux de l'année dernière et je dois dire que j'apprécie vraiment beaucoup ce format de conférence qui est vraiment basé sur les discussions, les échanges contrairement à une conférence traditionnelle où on écoute un speaker pendant 45 minutes.

Rendez-vous à NewCrafts Bordeaux en octobre maintenant ;)

Article publié originellement sur Medium

Qui sommes-nous ?

Jean-François Le Foll — Wed, 06 Nov 2019 14:32:23 +0000

Nous sommes un studio de développement logiciel.

Nous sommes trois développeurs passionnés qui travaillent ensemble depuis déjà plusieurs années et qui ont décidé de monter leur structure afin de mettre en pratique leur conception du métier de développeur et de la façon de construire des logiciels.

Nous considérons qu'apprendre est notre métier, apprendre de nouvelles technologies mais également une ouverture d'esprit et une curiosité pour comprendre le métier de nos interlocuteurs et échanger avec eux. Au fil des années nous avons travaillé dans des domaines très variés et fait de nombreuses rencontres humaines : pour nous, c'est aussi ce qui rend notre travail intéressant.

Que fait-on ?

Nous réalisons vos projets logiciels avec vous, en mettant en place une co-construction itérative et agile, basée sur les principes d'eXtrem Programming et du Software Craftsmanship.

Nous vous accompagnons également vos équipes sur la mise en place de bonnes pratiques agiles et techniques issues d'XP (développement itératif, livraison constante de valeur, TDD, pair programming, ...).

Pour nous, la meilleure façon de construire un logiciel passe par une bonne communication entre les différents acteurs ainsi que par la mise en place d'équipes de développeurs auto-organisés, responsables, ayant le contrôle/pouvoir sur leur travail de tous les jours.

En nous basant sur ce principe qui nous est cher, nous nous sommes constitués sous forme de Société COopérative et Participative (SCOP), afin de laisser à chacun la possibilité de prendre part aux décisions de l'entreprise, dans la transparence la plus totale.

Jean-François, Mathieu, Jérémy.

Article publié originellement sur Medium