Julien Leicher | Artisan développeur durable

Premier mois en tant que Staff Engineer !

Mon, 24 Mar 2025 00:00:00 GMT

Après avoir décidé de mettre fin à mon aventure entrepreneuriale en ce début d’année, j’ai donc rejoins la société Attineos le 24 Février dernier en tant que Staff Engineer (je vous explique en quoi ça consiste juste après).

Pourquoi repartir dans une société de services alors que je cherchais plutôt un client final me direz-vous ? Et bien tout simplement parce que le poste qui m’a été proposé me collait comme un gant !

Cerise sur le gâteau, je retrouve d’anciens collègues que j’apprécie énormément et avec qui je suis ravi de pouvoir travailler de nouveau.

C’est quoi ça Staff Engineer ?

C’est compliqué ! La fiche de poste qu’on m’a présenté était très vaste et contenait pas mal de choses, allant de l’expertise technique à l’avant-vente.

Au final, en lisant des articles, en regardant des vidéos et en comparant le tout avec ce que je fais au quotidien, je m’aperçois que le rôle est vraiment dépendant de l’entreprise dans lequel il est pratiqué.

Sur mon premier mois par exemple, aucun jour ne s’est ressemblé. J’ai entre autre :

contribué au Wiki interne
participé à de l’avant vente pour apporter des solutions techniques
pratiqué de la revue de code pour proposer des pistes d’améliorations et partager des bonnes pratiques
échangé avec des collègues sur certains points techniques précis
réalisé un POC autour de l’accessibilité et de l’éco-conception
fais de la veille
participé à pas mal de réunions sur tout un tas de sujets

Le moins que l’on puisse dire, c’est que ce fut un premier mois bien chargé ! Et j’ai adoré ! Les semaines qui suivent s’annoncent d’ailleurs tout aussi enrichissantes.

Au final, il s’agit réellement d’un poste à la fois transverse et technique où le planning se construit au gré des besoins de l’entreprise.

À bicyclette…

L’entreprise étant sur Rouen, c’était l’occasion pour moi de réfléchir à un mode de transport en accord avec mes convictions, exit la voiture donc et bonjour les transports en commun !

Sur ce point, j’ai doublement de la chance. D’une part, une gare à 10 minutes de chez moi a ré-ouvert il y a quelques années maintenant et d’autre part, Attineos rembourse 100% des transports en commun.

Pour le moment, le reste du trajet se fait en métro/bus mais bientôt …

Ce sera en vélo ! J’ai eu l’occasion de tester un Brompton grâce au magasin Cyclable le temps d’une journée et en suis tombé amoureux. Du coup… J’ai commandé le mien le soir même !

Pour finir

En conclusion, je suis vraiment satisfait ! À la fois vis à vis du poste mais aussi de l’entreprise dans laquelle règne une bienveillance qui donne envie de tout donner !

Ma veille en 2025

Sat, 08 Mar 2025 00:00:00 GMT

Mes canaux d’informations

Plusieurs canaux me permettent de rester informé sur les sujets qui me tiennent à cœur. Cette partie-là n’a pas particulièrement bougé depuis mon dernier article :

Des flux RSS finement choisis
Des chaînes Youtube spécifiques
Des podcasts
Mastodon
Des bouquins

Je repasse de temps en temps sur mes flux RSS pour être sûr d’avoir toujours du contenu pertinent et d’ajuster les flux suivis.

J’ai abandonné Reddit, beaucoup trop de choses à suivre, trop de sujets clivants ou hype qui me faisait perdre du temps. Au final, j’ai plutôt tendance à chercher des conférences de qualité sur Youtube : Devoxx France, DDD Europe ou NDC Conferences par exemple. Ça fait beaucoup de vidéos, je n’ai évidemment pas le temps de tout regarder mais il y a vraiment des sujets passionnants, bien présentés et avec plus de recul que sur Reddit.

Mes outils

Je n’en avais pas parlé dans mon précédent article mais je me suis pas mal outillé au fil des années.

Fervent défenseur d’auto-hébergement, une grosse partie de mes outils est hébergée sur un VPS Hetzner CX22 sur lequel j’ai installé un YunoHost.

Aujourd’hui j’utilise :

FreshRSS pour les flux RSS, FeedMe sur Android connecté à mon instance.
Wallabag pour mettre de côté les articles / vidéos que je souhaite lire plus tard depuis n’importe quel appareil (remplace petit à petit Shaarli).
Youtube ou NewPipe sur Android.
Obsidian comme base de connaissances. Il n’est pas très fourni pour le moment mais ça s’étoffe. Je ne paie pas d’abonnement pour la synchro entre mes appareils mais synchronise via le plugin Git sur un Gitea hébergé sur Yunohost aussi.
Anki pour me créer des “fiches” et pratiquer l’apprentissage par répétition (pour combler mon âge grandissant 🙂), et du coup j’ai développé un petit plugin pour que certaines notes dans mon Obsidian puissent être envoyées sur mon compte Anki.

La pratique

Là aussi, peu de changements par rapport à 2019, néanmoins, mon Github possède quelques projets plus aboutis que ce que j’avais tendance à faire par le passé.

Je continue à faire énormément d’expérimentations suite à mes différentes lectures et ce blog reste un excellent moyen de partager ce que je découvre. J’aimerais trouver plus de temps pour écrire mais le temps me manque !

Voilà, je crois avoir fait le tour ! Si jamais vous avez des questions, n’hésitez pas à me contacter 😉

Vous n'avez (probablement) pas besoin d'un LLM

Mon, 27 Jan 2025 00:00:00 GMT

Depuis que j’ai suffisamment d’expérience pour m’en sentir légitime, je n’arrête pas de mettre en avant mon pragmatisme, cette capacité à utiliser une approche adaptée et mesurée au problème qu’on cherche à résoudre.

Alors quand j’ai un exemple parfait du contraire et qui en plus essaie de nous vendre l’utilisation inutile d’un LLM, je me dois de sauter sur l’occasion pour préciser le fond de ma pensée.

L’article en question

L’article est publié sur Codrops que je suis depuis longtemps pour sa partie “The Collective” publiée chaque semaine.

Il nous fait part des bienfaits de monitorer les performances d’un site web et d’être prévenu par email lorsque les performances (FCP, LCP et CLS en l’occurrence) passent sous certains seuils et nous propose un petit tutoriel pour créer notre propre agent autonome.

Jusqu’ici, à priori, le but est louable, le tout avec un plan qui ressemble à ceci :

Récupérer les métriques grâce à l’API Lighthouse de Google
Traiter et extraire les métriques pertinentes
Mettre en forme ces données et inclure des actions correctives à mener en cas d’anomalies
Envoyer l’email avec le HTML ainsi constitué

Vous voyez en quoi un LLM va pouvoir nous être utile ici ? Moi non plus.

Et pourtant, directement, on nous dirige vers un lien affilié vers Agent.ai pour commencer ce petit tutoriel.

Laissons de côté la création de l’agent, c’est du détail et passons au vif du sujet.

Les étapes

Récupérer les métriques

Ici pas de mystère, un appel à l’API Lighthouse et on récupère toutes les informations qui nous intéressent.

L’auteur enchaîne avec un petit truncate du retour de l’API qui est plutôt bavarde (bah oui, sinon on risque d’atteindre la limite de contexte du LLM, malin !).

Extraire les métriques pertinentes

C’est là que tout commence à partir en vrille. N’importe quel développeur serait en mesure de traiter le retour de l’API directement en parcourant les données contenues, détecter si les seuils sont dépassés et remettre en forme si nécessaire. Même avec un outil low-code, on pourrait facilement s’en sortir.

Mais non ! Ce serait bien trop facile, et pas suffisamment disruptif !

Donnons plutôt un prompt à ChatGPT et serrons les fesses pour qu’il comprenne notre demande :

You are an assistant that extracts relevant information from Lighthouse API results.
Given the following JSON input, extract the specified details and format them in JSON:

Input JSON:

{{sanitizedMetrics}}

### Extract the following details:
1. **Website URL**:
   - The URL of the website being analyzed.

2. **Metrics**:
   - `fcp`: First Contentful Paint (in seconds).
   - `lcp`: Largest Contentful Paint (in seconds).
   - `cls`: Cumulative Layout Shift value.
   - `performanceScore`: Performance score (as a percentage).

3. **Anomalies**:
   - For `fcp`: Return `true` if FCP > 2 seconds, otherwise `false`.
   - For `lcp`: Return `true` if LCP > 2.5 seconds, otherwise `false`.
   - For `cls`: Return `true` if CLS > 0.1, otherwise `false`.

4. **Suggested Actions**:
   - Provide actionable recommendations based on detected anomalies.

### Expected JSON Output Example:

{
  "url": "https://example.com",
  "metrics": {
    "fcp": "2.3",
    "lcp": "1.8",
    "cls": "0.12",
    "performanceScore": "89"
  },
  "anomalies": {
    "fcp": true,
    "lcp": false,
    "cls": true
  },
  "suggestedActions": [
    "Optimize images to improve FCP",
    "Reduce layout shifts by reserving space for ads or images"
  ]
}

Bon ok, je me moque et c’est pas très sympa de ma part. Sauf que quand on connaît un minimum le fonctionnement des LLMs (et au passage, les vidéos de 3Blue1Brown sont top), on voit tout de suite ce qui pourrait mal tourner là dedans et à quel point c’est sous-optimal en terme de resources et de performances.

Faire reposer ne serait-ce que la logique des seuils et le calcul du score de performance dans un prompt me semble personnellement très bancal.

Ici on pourrait me répondre que pour remplir la propriété suggestedActions, cela pourrait effectivement être utile.

Si c’était vraiment le cas, on pourrait sortir les métriques de manière traditionnelle et n’utiliser le LLM que pour cette partie ci. Mais à dire vrai, l’API Lighthouse nous retourne déjà une liste d’actions à entreprendre dans le cas d’anomalies…

Mettre en forme ces données dans un email

Une fois encore, mettre en forme un email à partir d’un modèle et de données, même si ça peut s’avérer frustrant en terme de mise en page, c’est quelque chose qu’on sait faire efficacement dans n’importe quel langage depuis des lustres.

Et une fois encore, l’article repart sur un prompt !

You are an assistant that formats data into a professional and visually appealing HTML email body. Use the following JSON data to create a structured and concise email report in HTML format:

Input JSON:

{{processedMetrics}}

### Instructions:
1. **Greeting and Introduction**:
   - Include a welcoming line and specify the purpose of the email.
   - Mention the website URL as a clickable link.

2. **Metrics Summary**:
   - Use a styled HTML table to display key metrics with two columns: Metric Name and Value.
   - Ensure proper alignment, spacing, and readability.

3. **Highlighted Anomalies**:
   - If anomalies are detected, list them as bullet points.
   - Highlight critical issues using bold text or distinct color.

4. **Suggested Actions**:
   - Present actionable recommendations in a numbered list.

5. **Closing Statement**:
   - Conclude with a polite summary encouraging further action.
   - Sign off with "Best regards" and a placeholder for the team name.

### Requirements:
- Use clean and modern HTML with inline styles for email compatibility.
- Focus on readability with a professional, minimalist design.
- Output **only** the email body in HTML format.

### Example Structure for Output:

<!DOCTYPE html>
<html>
  <body style="font-family: Arial, sans-serif; line-height: 1.6; max-width: 600px; margin: 0 auto; color: #333;">
    <!-- Introduction -->
    <p>Hello,</p>
    <p>Here is the Lighthouse metrics report for your website:
      <a href="https://tympanus.net/codrops/" target="_blank" style="color: #4CAF50; text-decoration: none;">Codrops</a>.
    </p>

    <!-- Metrics Summary -->
    <h2 style="color: #4CAF50; font-size: 20px;">Metrics Summary</h2>
    <table style="border-collapse: collapse; width: 100%; margin-bottom: 20px; border: 1px solid #ddd;">
      <tr style="background-color: #f9f9f9;">
        <th style="text-align: left; border-bottom: 2px solid #ddd; padding: 8px;">Metric</th>
        <th style="text-align: left; border-bottom: 2px solid #ddd; padding: 8px;">Value</th>
      </tr>
      <tr>
        <td style="padding: 8px;">First Contentful Paint (FCP)</td>
        <td style="padding: 8px;">1.804 seconds</td>
      </tr>
      <tr>
        <td style="padding: 8px;">Largest Contentful Paint (LCP)</td>
        <td style="padding: 8px;">2.045 seconds</td>
      </tr>
      <tr>
        <td style="padding: 8px;">Cumulative Layout Shift (CLS)</td>
        <td style="padding: 8px;">0.0006</td>
      </tr>
      <tr>
        <td style="padding: 8px;">Performance Score</td>
        <td style="padding: 8px;">AVERAGE</td>
      </tr>
    </table>

    <!-- Anomalies -->
    <h2 style="color: #FF5722; font-size: 20px;">Anomalies Detected</h2>
    <ul style="padding-left: 20px; margin-bottom: 20px;">
      <li>No anomalies detected for FCP (below 2 seconds).</li>
      <li>No anomalies detected for LCP (below 2.5 seconds).</li>
      <li>No anomalies detected for CLS (below 0.1).</li>
    </ul>

    <!-- Suggested Actions -->
    <h2 style="color: #2196F3; font-size: 20px;">Suggested Actions</h2>
    <p style="color: #555;">No suggested actions. Your website is performing well based on the current metrics!</p>

    <!-- Closing -->
    <p style="margin-top: 20px;">We recommend continuing to monitor these metrics to maintain a great user experience and optimize performance as needed.</p>
    <p style="margin-top: 20px;">Best regards,<br><strong>Your Performance Watchdog</strong></p>
  </body>
</html>

Apprécions qu’au final le template qui nous serait nécessaire pour faire un rendu comme on sait le faire fait lui même parti du prompt…

Rien à ajouter pour l’envoi de l’email, c’est du classique et on peut donc s’arrêter là.

Conclusion

Pour moi cet article reflète bien le soucis avec la hype autour des IA génératives. Ce n’est pas parce qu’on peut le faire avec ce nouvel outil qu’il faut forcément partir sur cette solution.

Sans trop m’avancer, je pense qu’il sera toujours plus efficace de partir sur une solution dite classique si c’est possible. En l’occurrence ici, reposer sur un LLM est un énorme gâchis de ressources et d’argent.

Alors oui, en mettant en place ce genre d’outil, le marketing pourra mettre en avant l’utilisation de l’IA, mais au final la valeur ajoutée sera nulle voire négative.

Il serait préférable de ne réserver ces outils qu’aux problèmes impossibles à résoudre avec des solutions éprouvées, surtout quand on prend en compte l’impact important de ces outils sur notre société.

#OpenToWork

Fri, 17 Jan 2025 00:00:00 GMT

Clap de fin

La décision ne fût pas facile à prendre mais je pense que c’est le bon moment pour mettre un terme à mon aventure en tant qu’indépendant. Après tout, nouvelle année, nouveau départ !

Sur ces cinq années à mon compte, pas de regret, je suis content d’avoir tenter le coup et que ça ait durer tout ce temps. Ces années m’auront permis de prendre un peu de recul et de connaître mes limites.

Ce que je recherche

Maintenant, place à l’avenir !

J’en parlais déjà dans ma rétrospective mais ce qui me manque le plus et que je souhaite retrouver, c’est avant tout le travail d’équipe.

Moi en quelques mots

Je suis développeur, officiellement depuis l’acquisition de mon diplôme de fin d’étude en 2012, officieusement depuis plus longtemps encore.

J’aime voir les choses prendre forme et résoudre des problèmes métiers complexes grâce à des solutions élégantes et maintenables permettant d’apporter un maximum de valeurs aux utilisateurs.

J’aime expérimenter de nouvelles technologies, de nouvelles approches me permettant d’élargir mes connaissances et d’aborder les problèmes sous différents angles.

J’aime également partager ce que je découvre au fil des années, notamment au travers de ce blog.

Je suis honnête et connaît mes lacunes, je n’ai aucun problème à admettre que j’ai tort ou que je ne maîtrise pas un sujet. C’est pour cette raison que la veille technologique tient une place importante dans ma vie.

Je suis de nature réservée mais ces dernières années ont prouvé que j’étais capable de me dépasser.

Si vous souhaitez en savoir plus sur mes compétences, n’hésitez pas à consulter la page à propos qui fait office de CV. N’hésitez pas à consulter aussi ce site qui reflète à mon sens assez bien ma personnalité.

Ma fiche de poste idéale en 2025

Type de structure : Client final. Étant déjà passé par une ESN et l’auto-entreprenariat, j’aimerai mettre mes compétences directement au service de l’entreprise finale.
Secteur d’activité : Cette question est difficile. Étant préoccupé par les enjeux environnementaux et la place du numérique, une entreprise mettant en avant un numérique responsable serait l’idéal.
Type de poste : Technique avant tout, au sein d’une équipe de taille raisonnable. De ce côté là rien n’a changé, avec la volonté de faire les choses proprement et surtout de bien comprendre le besoin et le fonctionnel. J’ai une affinité particulière pour le back-end, mais je prends aussi plaisir à développer des interfaces utilisateurs et des applications mobiles.
Technologies : Je suis plutôt polyvalent, en ce moment j’adore le Go pour sa simplicité, mais j’ai fait beaucoup de C# et de Typescript jusqu’ici. Les autres langages ne sont pas rédhibitoires mais il faudra compter un temps de formation.
Rythme de travail : 2 jours de TT, le reste en présentiel. Pas de full-remote.
Localisation : Dans un rayon de 30km autour de Bourg-Achard (ce qui couvre notamment Rouen, Pont-Audemer, Brionne).
Salaire : Raisonnable. Oui ce n’est pas précis mais ça dépend de tellement de paramètres…

Comme il s’agit d’un idéal, je suis bien évidemment prêt à faire des concessions en fonction de la proposition.

Si vous pensez que nous pourrions collaborer ensemble, n’hésitez pas à me contacter ! Et sinon, n’hésitez pas à partager ce post 😉.

Ce n'est pas un échec, c'est juste que ça n'a pas marché

Mon, 16 Dec 2024 00:00:00 GMT

D’un point de vue activité professionnelle, l’année 2024 a été, il faut le dire, mauvaise. Comme d’habitude chez moi, baisse d’activité = moments de doute, syndrome de l’imposteur et autres joyeusetés.

Alors bien sûr, je pourrais broyer du noir dans mon coin, mais je préfère admettre mes difficultés afin d’y voir plus clair et de préparer la suite. Allons-y !

Un début d’année au ralenti

En début d’année, je n’ai pas spécialement cherché de nouvelles missions. J’avais encore quelques paiements qui devaient arriver suite à ma mission de fin d’année donc j’étais plutôt tranquille de ce côté là.

Côté perso, la maison de mon défunt père a été vendue ce qui a permis de clôturer la succession. Hasard ou non, cette période a coïncidé avec quelques problèmes de santé qui ont entaché ma motivation.

Afin de me remotiver, j’ai repris timidement la course à pied et consacré pas mal de temps à mon petit projet du moment. Comme à mon habitude, je continuais en parallèle ma veille technologique.

Les beaux jours

En Juin, toujours très peu d’activité, principalement des missions d’audit de quelques jours et quelques prises de contact mais rien n’ayant débouché sur un contrat. Je restais tout de même attentif aux éventuelles missions sur les plateformes freelance mais je constatais que la demande était beaucoup plus faible qu’à l’accoutumée.

Pratiquant le VTT depuis très longtemps, j’ai décidé de me faire plaisir et d’acquérir à cette période le petit Gravel de chez Intersport : le Nakamura ALLROAD 250.

Comme l’activité était toujours très calme, j’ai profité des beaux jours pour rôder mon nouveau vélo 😁 et passer du temps en famille !

Quand vient la fin de l’été

Forcément, avec si peu d’activité, remise en question de mon approche et de mes compétences avec un soupçon de culpabilité à avoir autant profiter de l’été pendant que certains se démenaient au travail.

À ce moment, j’essaie tant bien que mal de trouver une mission mais ça ne mord pas, l’activité semble être au ralenti ou peut-être est-ce moi ?

J’en profite tout de même pour migrer mon site de îles vers Astro et changer de style au passage.

Connaissant la demande pour le C# dans ma région, je me remets également à jour sur le langage avec quelques petits projets et conférences bien choisies.

En Novembre, petit passage comme tous les ans à Codeurs en Seine, l’occasion de revoir pas mal de monde !

Un constat s’impose

Désormais nous sommes en Décembre et il est temps de faire le bilan de cette année.

Il me semble évident aujourd’hui que si je n’ai trouvé que peu de missions, c’est en grande partie de ma faute. D’une part la prospection reste un exercice difficile pour moi et d’autre part, la motivation n’y était pas non plus.

Pour ce dernier point, les raisons sont multiples :

l’essor de l’IA et cette volonté maladive de vouloir à tout prix nous la vendre à toute les sauces en omettant volontairement tous ses aspects négatifs (comme toute techno, il y’a des cas d’usage intéressants, mais il faut faire preuve de discernement)
la situation politique de la France, ridicule au possible
la situation mondiale, les guerres (je n’ai pas eu le courage de regarder le documentaire sur Gaza d’Aymeric Caron en entier), la trajectoire des différents gouvernements, …

En bref, le fait que l’avenir soit si incertain.

D’un autre côté, après en avoir échangé avec d’autres personnes dans le milieu, je ne suis pas le seul à avoir constaté un marché moins dynamique que d’habitude.

Jusqu’ici, depuis que je suis indépendant, je n’ai pas spécialement eu à chercher de missions. On me contactait directement via le bouche-à-oreille pour me proposer du travail et ça m’allait très bien.

Et maintenant ?

Même si cette cinquième année est singulière, force est d’admettre que je me pose beaucoup de questions.

Ma passion pour le code bien fait, orienté métier, est intacte. J’aime trouver des solutions élégantes, approfondir mes connaissances et les partager et cette année n’a pas fait exception. Même si pour le coup, c’était principalement sur des projets personnels.

Mais faire partie d’une équipe me manque. En tant qu’indépendant, j’ai souvent l’impression d’être un outsider (ce qui n’est pas entièrement faux).

Peut-être est-il temps de clore ce chapitre et de commencer une nouvelle aventure ?

seelf v2.0.0 🍾 !

Fri, 19 Apr 2024 00:00:00 GMT

Étant donné que ce début d’année est professionnellement très calme, je ne me suis pas laissé abattre et ai profité de ce temps disponible pour d’une part accentuer ma veille, et d’autre part travailler sur un projet qui me tient à cœur, j’ai nommé seelf, quelle surprise !

Un travail de titan

Cette v2 est le résultat d’un travail acharné de plusieurs mois, notamment en terme de documentation.

Autant de temps car pour ceux qui ont l’occasion de travailler sur des projets perso, vous savez probablement à quel point il est difficile de mener à bout un projet dont vous êtes (quasi) le seul à vous préoccuper et de conserver la motivation nécessaire à son avancée tout en étant extrêmement exigeant envers vous-même.

Néanmoins, mon objectif est atteint et je suis on ne peut plus fier du résultat !

Les nouveautés

Faisons un petit tour rapide de cette nouvelle version.

Gestion des cibles de déploiement

Jusque ici, vous pouviez déployer vos applications uniquement sur le serveur sur lequel était installé seelf. Désormais, il est possible de configurer des hôtes distants sous forme de cibles de déploiement !

Une fois une cible créée, il vous est possible de configurer une application afin de déterminer, pour chaque environnement (production et staging), sur quelle cible elle sera déployée.

Ça n’a l’air de rien comme ça, mais cela permet tout un tas de nouveaux cas d’utilisation !

Je me suis au passage pas mal pris la tête sur tout ce qui pouvait mal se passer lors de l’utilisation de cibles distantes : cible indisponible ponctuellement, supprimée, nettoyage lors du changement de cible et j’en passe.

Un logo !

Comme vous l’avez sans doute constaté dans les captures ci-dessus, seelf possède désormais un logo réalisé par mes soins. Je ne suis pas trop mécontent du résultat, là aussi 😁.

Une documentation dédiée

Jusqu’ici, la documentation n’était qu’un simple fichier Markdown à la racine du dépôt Github.

Désormais, seelf possède une vraie documentation dédiée, beaucoup plus fournie même s’il reste encore des choses à ajouter / affiner au cours du temps.

Et tout un tas de petites choses …

Redéploiement automatique en cas de changement de configuration, possibilité de changer l’URL d’une cible sans redéployer les applications liées, page de visualisation des tâches asynchrones et possibilité d’en annuler certaines, et bien sûr de la refacto en grande pompe pour toujours rendre le changement et l’évolution du code plus simple et ainsi préparer la suite.

Voilà qui fait un peu le tour de cette nouvelle version, n’hésitez pas à jeter un coup d’œil à la toute nouvelle documentation, de mettre une étoile sur le dépôt Github ou bien un petit upvote sur Reddit 😉.

Et si vous avez besoin d’un développeur pour votre prochain projet, n’hésitez pas à prendre contact, je suis disponible !

Modéliser des agrégats grâce au pattern "Decider"

Fri, 08 Mar 2024 00:00:00 GMT

Ce n’est un secret pour aucun d’entre vous, j’aime l’approche orientée métier dans le développement logiciel, ça a totalement changé ma manière de développer. Alors quand je découvre un pattern qui va dans ce sens, je suis bien obligé d’en parler !

Il était une fois…

J’aime beaucoup le langage Typescript. Quand j’ai un POC ou un Kata à réaliser, je me tourne souvent vers ce langage pour son côté très dynamique et son système de types poussé (en attendant que je sois prêt à passer sur un langage totalement fonctionnel 😁).

Seulement quand je l’utilise pour quelque chose de plus sérieux, notamment pour une application spécifique dans laquelle j’ai envie de conserver cette approche orientée métier, j’ai beaucoup plus de mal.

Pourquoi donc me direz-vous ? Et bien tout simplement car les classes sont bien souvent délaissées au profit de structures de données plus simple (à base de {}), en bien ou en mal, là n’est pas la question et qu’en se faisant, on perd le contrôle sur la cohérence de l’objet.

Toujours est-il que partir dans le sens contraire peut vous poser bien des soucis, notamment lors de l’intégration avec d’autres librairies pour la persistance où ce genre de choses, vous amenant à tordre votre classe ou créer des représentations intermédiaires.

Admettons que je décide de réaliser une application de gestion de tâches, on va faire très très simple ici :

type Task = {
  title: string;
  done: boolean;
};

Dans la plupart des applications qu’on peut trouver en Typescript (sur Github principalement), peu de personnes se soucient des mutations de ce type Task et il ne sera pas rare de voir un task.done = true; directement dans un handler HTTP. Alors ça fonctionne, mais imaginez la même chose sur une application plus complexe et sur la maintenabilité à plus ou moins long terme (sans parler du peu d’expressivité de cette modélisation)…

Le pattern “Decider”

Ce pattern, découvert via la conférence de Jérémie Chassaing, va vous permettre de conserver cette approche centrée sur les données mais en y ajoutant l’expressivité d’un modèle orienté métier.

Définition

Un Decider possède 4 propriétés :

une fonction decide : à partir d’une commande et d’un état détermine les événements produits,
une fonction evolve : à partir d’un état et d’une liste d’événements (générés précédemment), génère un nouvel état,
un initialState qui permet de savoir d’où on part,
une fonction isTerminal : à partir d’un état, détermine si l’état final est atteint, et que par conséquent, l’objet ne sera plus jamais modifié (permet par exemple de disposer l’objet).

Transposé en Typescript, on aura quelque chose dans ce genre là :

type Decider<Command, Event, State> = {
  decide: (cmd: Command, state: State) => Event[];
  evolve: (state: State, event: Event) => State;
  initialState: State;
  isTerminal: (state: State) => boolean;
};

Si on reprend notre exemple de gestion de tâches, on va alors pouvoir réfléchir en commandes, états et événements :

// Ici j'utilise un namespace mais on pourrait définir un fichier task.ts et exporter les membres.
namespace Task {
  // L'état en readonly, impossible de le modifier sans passer par le decider
  export type State = Readonly<{
    title: string;
    done: boolean;
  }>;

  // Les différentes commandes possible sur notre tâche, la propriété `type` sert de discriminant
  export type Command =
    | {
        type: "Create";
        title: string;
      }
    | {
        type: "ChangeTitle";
        title: string;
      }
    | {
        type: "MarkAsDone";
      };

  // Les événements, au passé, la propriété `type` en discriminant aussi
  export type Event =
    | {
        type: "Created";
        title: string;
      }
    | {
        type: "TitleChanged";
        title: string;
      }
    | {
        type: "MarkedAsDone";
      };

  // Et enfin notre decider, qui prend les décisions métiers et lèvent les événements appropriés et s'occupe de modifier l'état
  export const decider: Decider<Command, Event, State> = {
    decide: (c, s) =>
      match(c, {
        Create: (c) => {
          if (s.title) {
            throw new Error("Task already created");
          }
          return [{ type: "Created", title: c.title }];
        },
        ChangeTitle: (c) => {
          if (s.done) {
            throw new Error("Task is done");
          }
          return [{ type: "TitleChanged", title: c.title }];
        },
        MarkAsDone: (_) => (s.done ? [] : [{ type: "MarkedAsDone" }]),
      }),
    evolve: (s, e) =>
      match(e, {
        Created: (e) => ({ ...s, title: e.title }),
        TitleChanged: (e) => ({ ...s, title: e.title }),
        MarkedAsDone: (_) => ({ ...s, done: true }),
      }),
    initialState: { title: "", done: false },
    isTerminal: (s) => s.done,
  };
}

// Petits utilitaires pour éviter les switch un peu cracra et assurer l'exhaustivité des cas

type ExtractCallbacks<Input extends { type: string }, Output> = {
  [K in Input["type"]]: (_: Extract<Input, { type: K }>) => Output;
};

function match<Input extends { type: string }, Output>(
  cmd: Input,
  cases: ExtractCallbacks<Input, Output>
): Output {
  return cases[cmd.type as keyof typeof cases](
    cmd as Extract<Input, { type: Input["type"] }>
  );
}

Évidemment lors de l’utilisation de ce type de pattern, les effets de bord (persistance, appels externes, …) sont repoussés dans les couches plus hautes, à la manière de mon article précédent et de l’approche Functional Core, Imperative Shell.

Et qui dit fonctions pures, dit testabilité ! En effet, tester le Decider est un vrai jeu d’enfant !

Utilisation

Une fois que vous avez votre Decider, votre code métier donc, écrit, vous n’y touchez plus ! Il ne nous manque q’un élément permettant d’orchestrer le tout et de choisir quoi faire de l’état et des événements.

Par exemple, si on souhaite uniquement manipuler notre decider en mémoire, on peut partir d’une fonction de ce genre :

function inMemory<Command, Event, State>(
  decider: Decider<Command, Event, State>
): (_: Command) => State {
  let state = decider.initialState;

  return (cmd: Command) => {
    const events = decider.decide(cmd, state);
    state = events.reduce(decider.evolve, state);
    return state;
  };
}

Cette fonction pourra s’appliquer sur n’importe quel type de decider :

const taskDeciderInMemory = inMemory(Task.decider);

// Ici tout est typé ! Impossible de passer un `type` qui ne fait pas parti de l'union `Task.Command`
console.log(taskDeciderInMemory({ type: "Create", title: "Acheter du lait" }));
console.log(
  taskDeciderInMemory({
    type: "ChangeTitle",
    title: "Acheter du lait, et des œufs !",
  })
);
console.log(taskDeciderInMemory({ type: "MarkAsDone" }));

// { title: "Acheter du lait", done: false }
// { title: "Acheter du lait, et des œufs !", done: false }
// { title: "Acheter du lait, et des œufs !", done: true }

Envie de persister l’état ailleurs ? De lever les événements dans des Process (cf. la conférence) ? Il suffit d’écrire une alternative à la fonction inMemory ! C’est aussi simple que ça.

Cette approche est d’ailleurs extrêmement pratique si vous pratiquez l’Event Sourcing, il suffit en effet de persister les événements plutôt que l’état et de rappeler la fonction evolve avec le flux d’événements pour réhydrater votre agrégat !

Conclusion

J’ai laissé de côté certains aspects abordés dans la conférence et l’article associé, notamment la composition de plusieurs deciders pour la coordination mais les possibilités sont folles !

Représenter l'unicité dans un domaine pur

Tue, 20 Feb 2024 00:00:00 GMT

Qu’est-ce qu’un modèle de domaine pur ?

Si on reprend la définition d’une fonction pure d’après Wikipédia :

En programmation informatique, une fonction pure est une fonction qui possède les propriétés suivantes :

Sa valeur de retour est la même pour les mêmes arguments (pas de variation avec des variables statiques locales, des variables non locales, des arguments mutables de type référence ou des flux d’entrée).
Son évaluation n’a pas d’effets de bord (pas de mutation de variables statiques locales, de variables non locales, d’arguments mutables de type référence ou de flux d’entrée-sortie).

Pour faire simple, une fonction pure retourne toujours le même résultat si on lui passe les mêmes arguments et ne va pas modifier un état externe quelconque (ce qui inclut l’écriture sur un volume ou une communication réseau).

Dans le cas du DDD, lorsqu’on modélise notre solution, c’est à dire qu’on crée nos entités, nos objets-valeurs, etc…, la pureté du modèle consiste principalement à ne pas appeler de services externes depuis ces objets.

Prenons un cas concret qui devrait parler à tout le monde et qui ne respecte pas cette propriété :

package auth

import "errors"

var ErrEmailShouldBeUnique = errors.New("l'email doit être unique!")

type User struct{
    email string
    // ... Et plein d'autres champs
}

// Abstraction de la couche de persistance
type UserRepository interface {
    IsEmailUnique(email string) bool // Je simplifie et j'omet volontairement le retour des erreurs ici
    // ... Et d'autres méthodes pour persister un User, le récupérer, etc...
}

func Register(repo UserRepository, email string) (*User, error) {
    if !repo.IsEmailUnique(email) {
        return nil, ErrEmailShouldBeUnique
    }

    return &User{
        email: email,
    }, nil
}

Dans cet exemple, je souhaite faire apparaître la règle métier qui est : il ne peut y’avoir qu’un seul utilisateur par adresse mail. Comme il s’agit d’une règle métier, mon souhait est bel et bien de la représenter dans mon domaine.

Pour se faire, je demande donc en paramètre le UserRepository qui me permettra d’aller m’assurer que la condition est validée, dans le cas contraire, je retourne une erreur.

En introduisant l’appel à ce service, je casse la pureté du domaine car un effet de bord (communiquer avec la base de données ici) a été ajouté.

Si je dois tester la fonction Register, il me faudra alors implémenter un test double pour le UserRepository afin de valider les deux sorties possibles.

Le trilemme DDD

Cela dit, ce n’est pas forcément une mauvaise chose et cette solution peut tout à fait être viable !

Comme l’explique Vladimir Khorikov, il s’agit en fait d’un trilemme lorsqu’on modélise avec le DDD.

Ce trilemme met en avant 3 choix qui s’offrent à vous quand vous tentez d’utiliser le DDD pour modéliser votre solution :

Domain model completeness : l’exhaustivité du modèle, absolument toutes les règles se trouvent dans la couche métier,
Domain model purity : le modèle de domaine est dit pur, aucune dépendance vers des services externes (out-of-process) dans le domaine, les appels à effets de bord sont repoussés dans la couche applicative,
Performance : il faut tout de même considérer les performances de notre modèle ce qui implique d’autres choix architecturaux.

Pour revenir sur ce dernier point, on pourrait effectivement charger toute la liste des utilisateurs de notre système, la passer en paramètre de la méthode Register et s’assurer de l’unicité de l’email. De cette manière, on écarte l’effet de bord et on rend notre fonction pure. Cela dit, on comprend très vite que d’un point de vue performance, ce serait absolument catastrophique !

// Aïe ! Imaginer avec des milliers d'utilisateurs !
func Register(email string, allUsers []*User) (*User, error) {
    for _, user := range allUsers {
        if user.email == email {
            return nil, ErrEmailShouldBeUnique
        }
    }

    return &User{
        email: email,
    }, nil
}

Ce trilemme nous dit que parmi ces 3 choix, on ne peut en choisir que 2 et qu’il va donc falloir faire des compromis :

Pousser les lectures/écritures externes en périphérie du domaine (donc plutôt dans la couche applicative), par exemple charger tout en mémoire et le passer au domaine pour valider les règles : exhaustivité et pureté,
Injecter des dépendances de services dans le domaine : exhaustivité et performance
Diviser la prise de décision entre la couche applicative et le domaine : pureté et performance

Et à partir de là, c’est au final à vous de choisir ce qui est le mieux selon votre pratique. Selon l’auteur, il est préférable de favoriser la pureté au détriment de l’exhaustivité (opter alors pour la troisième approche) et de mon côté, je partage plutôt cet avis. Partir sur un modèle plus simple est toujours une bonne chose et vous permet de tester aisément des cas complexes.

Pureté et performance, comment retrouver un peu d’exhaustivité ?

Si j’écris cet article c’est justement car j’ai été confronté à ce choix sur seelf. Depuis le début, j’avais choisi de partir sur un domaine aussi pur que possible pour faciliter la testabilité de l’application.

Seulement, mettre de côté l’exhaustivité du modèle ne me satisfaisait pas vraiment. En lisant les commentaires de l’article cité plus haut, on s’aperçoit qu’on peut rétablir un peu d’exhaustivité y compris en optant pour un modèle pur. Par exemple, si je reprends le code précédent :

func Register(email string, unique bool) (*User, error) {
    if !unique {
        return nil, ErrEmailShouldBeUnique
    }

    return &User{
        email: email,
    }, nil
}

En introduisant le booléen unique, on a repoussé la récupération de cette information dans la couche applicative (via la méthode UserRepository.IsEmailUnique) pour préserver un modèle pur et simple dans notre couche métier. De cette manière, on rétablit une partie de l’exhaustivité qu’on a concédé via notre choix.

On peut aller encore un peu plus loin en définissant un nouveau type qui éliminera les ambiguïtés restantes :

type EmailAvailability bool // On définit un nouveau type

type UserRepository interface {
    GetEmailAvailability(email string) EmailAvailability
}

func Register(email string, available EmailAvailability) (*User, error) {
    if !available {
        return nil, ErrEmailShouldBeUnique
    }

    return &User{
        email: email,
    }, nil
}

De cette manière, à la lecture de la signature de la méthode, on comprend très vite ce qui se passe. Les tests restent extrêmement simples car il suffit de passer true ou false en paramètre et de vérifier les retours. Côté performance, on ne perd rien car c’est l’implémentation du UserRepository qui aura la charge de vérifier l’unicité (via un COUNT si SQL par exemple) et niveau exhaustivité, on conserve une part non négligeable de l’intention originale.

Parfois, les choses sont encore plus compliquées et la règle métier repose sur plusieurs informations que seule la collection d’entités possède.

Dans ce cas, on peut avoir recours à des types plus complexes qu’un simple booléen. Par exemple sur seelf, dans la prochaine version, on pourra déployer des applications sur des instances Docker distantes. L’unicité du nom d’une application est donc fonction du nom de l’application et des différentes cibles configurées. Pour représenter cette complexité, j’ai décidé d’utiliser un bitmask :

type AppNamingAvailability uint8

const (
	AppNamingProductionTargetNotFound AppNamingAvailability = 1 << iota
	AppNamingStagingTargetNotFound
	AppNamingTakenInProduction
	AppNamingTakenInStaging
	AppNamingAvailable
)

type AppsReader interface {
    GetAppNamingAvailability(context.Context, AppName, TargetID, TargetID) (AppNamingAvailability, error)
    // ...
}

func NewApp(
	name AppName,
	production EnvironmentConfig,
	staging EnvironmentConfig,
	createdBy domain.UserID,
	available AppNamingAvailability,
) (app App, err error) {
	if available != AppNamingAvailable {
		return app, ErrInvalidAppNaming
	}

    // ...
}

// Dans la couche applicative, j'utilise `AppsReader.GetAppNamingAvailability`
// et je peux alors retourner une erreur précise à l'utilisateur suivant les
// valeurs du masque.

Grâce à ce bitmask, j’ai la possibilité de savoir pour quelle raison le nom n’est pas disponible ce qui me permet de retourner une erreur plus précise à l’utilisateur au niveau de la couche applicative.

Cette solution n’est évidemment pas parfaite mais permet tout de même de limiter les concessions sur l’exhaustivité du modèle alors pensez-y 😉 !

SvelteKit, seelf et localisation

Wed, 10 Jan 2024 00:00:00 GMT

Le cahier des charges

Première chose à faire, définir le besoin. Pour la localisation de seelf, mon cahier des charges ressemblait donc à ceci :

Pouvoir localiser des messages, des dates, des durées et des nombres
Pouvoir ajouter facilement une nouvelle langue
Ne pas pouvoir utiliser une clé de traduction non définie
Pouvoir paramétrer les traductions lorsque nécessaire

Un besoin au final assez classique quand on parle d’internationalisation. Cela dit, pour ma part, l’un des points essentiels était que le process de build échoue dans le cas de l’utilisation d’une traduction manquante ou mal paramétrée.

Les librairies existantes et leurs limites

La partie frontend de seelf est réalisée avec l’aide du framework SvelteKit en utilisant le langage Typescript. La suite logique était donc de regarder les librairies existantes en terme de localisation avec ce framework.

Un petit tour sur un moteur de recherche me permet de mettre en avant un certain nombre de librairies :

Seulement, aucune ne parvient à me convaincre suffisamment. Pour la majorité de ces librairies, l’interpolation (donc le paramétrage des traductions) me semble bien trop complexe. Par exemple, avec sveltekit-i18n, vous pouvez avoir des chaînes de traduction de ce style :

{
  "placeholder": "Title with {{placeholder}}.",
  "placeholder_with_default_value": "{{placeholder; default:Default value;}}.",
  "modifier": "{{gender; female:She; male:He;}} has a dog.",
  "combined": "You have {{number:gt; 0:{{number}} new {{number; 1:message; default:messages;}}!; default:no messages.;}}"
}

Et même si je comprends l’utilité de cette syntaxe dans le cadre d’un fichier de traduction en JSON, cela restait trop compliqué pour mes besoins. Notons aussi qu’aucun typage n’est disponible avec ce genre de système et que donc, on peut se retrouver à oublier un argument nécessaire à la traduction ou à fournir une valeur du mauvais type.

Autre point intéressant à mentionner, chacune de ces solutions retourne la valeur de traduction sous forme de store svelte ce qui permet de changer à la volée et de manière réactive la langue de l’application. Même si je ne remet pas en cause la performance des stores tels qu’implémentés par Svelte, je trouvais dommage d’en payer le prix sachant que la langue n’est que très rarement changée au sein de l’application. Rafraîchir la page lorsque cela arrive me semblait tout à fait acceptable.

La solution retenue

Vous l’aurez sans doute compris, au final, j’ai préféré partir sur une solution sur-mesure adaptée parfaitement à mes besoins.

J’ai simplifié volontairement les exemples ci-dessous mais vous pouvez retrouver le code complet dans le dépôt Github de seelf.

Le typage des traductions

Comme je le disais au début, le point essentiel était le typage des traductions. Si je traduis (Haha !) ce besoin en Typescript, cela signifie qu’un dictionnaire de traductions est défini comme suit :

/**
 * Les traductions de l'application sont soit des chaînes
 * brutes, soit des fonctions prenant un nombre variable
 * de paramètres et retournant une chaîne.
 */
type Translations = Record<string, string | ((...args: any[]) => string)>;

Et oui, comme l’application utilise déjà Typescript, autant en profiter pour s’appuyer dessus et définir les traductions de l’application dans des fichiers .ts !

Le formatage des dates et nombres

Autre point important, pouvoir localiser des dates et des nombres. Pour se faire, notre service de localisation devra implémenter une petite interface :

type DateValue = string | number | Date;

interface FormatProvider {
  date(value: DateValue): string;
  datetime(value: DateValue): string;
  duration(start: DateValue, end: DateValue): string;
}

Et comme parfois une traduction paramétrée nécessite de formater le même genre de données, on peut venir compléter notre définition de Translations pour que le this de la fonction soit au final un FormatProvider :

/**
 * Désormais si je défini une traduction comme nécessitant un ou plusieurs
 * paramètres, je pourrai utiliser `this.date` ou `this.datetime` pour localiser
 * des données.
 */
type TranslationFunc = (this: FormatProvider, ...args: any[]) => string;
type Translations = Record<string, string | TranslationFunc>;

Les langues (ou locales)

Dernier point du cahier des charges, pouvoir ajouter facilement une nouvelle langue. De la même manière que pour les traductions, les langues sont donc définies par un type :

type Locale<T extends Translations> = {
  code: string;
  displayName: string;
  translations: T;
};

Lors de la définition de la langue par défaut (l’anglais sur seelf), j’ai donc un fichier en.ts qui ressemble grosso modo à ça :

const translations = {
  // (...)
  "auth.signin.title": "Sign in",
  "auth.signin.description":
    "Please fill the form below to access your dashboard.",
  "deployment.details_tooltip": (deployNumber: number) =>
    `View deployment #${deployNumber} details and logs`,
  // (...)
} satisfies Translations;

export default {
  code: "en",
  displayName: "English",
  translations,
} as const satisfies Locale<typeof translations>;

Le mot-clé satisfies apparu dans la version 4.9 de Typescript me permet de m’assurer que les traductions respectent les valeurs possibles (chaîne ou fonction) sans pour autant modifier le type de translations.

Quand je défini une nouvelle langue, il me suffit donc de m’assurer que les clés de traductions respectent le type défini par typeof translations dans le fichier en.ts. Par exemple pour le français, on a le fichier fr.ts :

/**
 * Représente les clés de traduction propres à l'application,
 * `en` étant l'import du fichier `en.ts`
 */
type AppTranslations = (typeof en)["translations"];

export default {
  code: "fr",
  displayName: "Français",
  translations: {
    // (...)
    "auth.signin.title": "Connexion",
    "auth.signin.description":
      "Remplissez le formulaire ci-dessous pour accéder au tableau de bord.",
    "deployment.details_tooltip": (deployNumber: number) =>
      `Voir les détails et logs du déploiement #${deployNumber}`,
    // (...)
  },
} as const satisfies Locale<AppTranslations>;

Grâce à tous ces types, je m’assure que les langues définies possèdent toutes les clés ainsi que les mêmes paramètres que la langue par défaut. Impossible donc d’oublier de traduire une clé ou de se tromper dans les types de paramètres.

Le service de localisation

Dernière étape et non des moindres, utiliser tout ce qu’on a vu précédemment et venir traduire toute l’interface. Pour se faire, j’ai donc un service de localisation respectant encore une fois une petite interface :

// Extrait toutes les clés d'un certain type
type KeysOfType<O, T> = {
  [K in keyof O]: O[K] extends T ? K : never;
}[keyof O];

// Extrait le type des arguments d'une fonction
type TranslationsArgs<T> = T extends (...args: infer P) => string ? P : never;

// Le service de localisation (simplifié pour l'article ici)
interface LocalizationService<T extends Translations> extends FormatProvider {
  translate<TKey extends KeysOfType<T, string>>(key: TKey): string;
  translate<TKey extends KeysOfType<T, TranslationFunc>>(
    key: TKey,
    args: TranslationsArgs<T[TKey]>
  ): string;
}

class LocalizationServiceImplementation<T extends Translations>
  implements LocalizationService<T> {
  /** Implémentation du service en utilisant les services fournis dans Intl ;) */
}

/**
 * Plus loin, une implémentation de LocalizationService<AppTranslations>
 * est exportée et donc disponible au sein de l'application avec quelque chose
 * dans ce genre.
 */
export default new LocalizationServiceImplementation<AppTranslations>();

Et c’est là que la magie opère. Grâce au type KeysOfType<>, je m’assure que si la traduction est une fonction (KeysOfType<T, TranslationFunc>) alors des paramètres doivent être fournis et posséder le bon type, et grâce au T extends Translations, le premier argument de la fonction translate doit être une clé valide.

Côté page ou composant, il nous suffit alors d’importer le service qui implémente cette interface et d’utiliser la fonction translate :

<script lang="ts">
  import l from '$lib/localization';
</script>

<p>{l.translate('auth.signin.title')}</p>
<p>{l.translate('deployment.details_tooltip', [42])}</p>

Petit bonus, la plupart du temps dans des applications multi-langues, il est difficile de savoir si une propriété d’un composant doit être une clé de traduction ou bien une chaîne déjà localisée. Avec l’approche exposée ici, j’ai un type AppTranslationsString qui me permet de typer certaines propriétés pour rendre le tout explicite :

<script lang="ts">
  // Où AppTranslationsString = KeysOfType<typeof en['translations'], string>
  import l, { type AppTranslationsString } from '$lib/localization';

  export let label: AppTranslationsString;
</script>

<button on:click>{l.translate(label)}</button>

Conclusion

Alors bien sûr tout n’est pas encore parfait. J’aimerai par exemple avoir un chargement des langues uniquement si elles sont utilisées par l’utilisateur pour éviter de charger des traductions inutiles.

Cela dit, je voulais partager avec vous cette petite solution qui me semble élégante et un peu à contre-courant.

Cette solution sur-mesure m’a effectivement évité d’avoir à faire des concessions sur mon cahier des charges en prenant une solution existante qui aurait été perfectible.

Analyse statique et génération de code

Mon, 20 Nov 2023 00:00:00 GMT

Il y a quelques semaines, poussé par ma curiosité, j’ai assisté à un live d’Alexandre Soyer intitulé Coder avec l’IA - Comment gagner 4h par jour avec L’IA, un titre accrocheur s’il en est ! En tant que développeur·se, force est d’admettre que l’IA est effectivement un enjeu important et qu’il vaut mieux s’y préparer et s’adapter.

J’utilise d’ailleurs depuis quelques mois Github Copilot et il faut bien avouer qu’il me fait gagner un sacré paquet de temps (même si le flou autour des données collectées reste questionnable).

Bref, revenons à nos moutons. Alex a avancé pas mal de points sur le métier de développeur·se et le code que nous produisons et à quel point écrire une grosse partie de notre code est un jeu d’enfant pour une IA. Après tout il ne s’agit que de texte avec un vocabulaire restreint.

Malgré tout, je pense que nous sommes tous d’accord pour admettre qu’écrire du code ne représente qu’une fraction de notre métier. On passe tout autant de temps, voir plus, à comprendre le problème, élaborer une solution et anticiper les erreurs. Je partage l’avis d’Alex sur le fait que l’IA ne sera qu’un outil de plus pour optimiser une partie de notre travail et non pas le remplacer.

En revanche, il y’a un point qui me fait réfléchir et qui rejoint une réflexion que j’ai depuis quelques temps :

On fait souvent des trucs pas compliqué, mais complexe

— Alexandre Soyer

Le constat

Je ressens la même chose, comme il le dit « On fait souvent les mêmes trucs, projet après projet », « 50% de notre temps, c’est : CRUD, formulaires, requêtes HTTP, tableaux, API GET, POST », etc…

Ce qui reste paradoxal car en tant que développeur·se, nous sommes extrêmement friands de tout ce qui nous évite de nous répéter et nous fait gagner du temps. Nous aimons la simplicité, surtout quand il s’agit de glue code, du code qui est nécessaire mais dont on préférerait se passer et encore plus ne pas avoir à maintenir.

Du coup, une fois un problème considéré comme résolu, la solution devrait pouvoir être intégrée sans aucun effort. Gérer l’authentification, la pagination, l’affichage de tableaux, la validation des formulaires, l’exposition et la documentation d’une API REST, etc…, toutes ces choses qu’on retrouve de manière systématique.

Et pourtant, en 2023, on est encore loin d’avoir atteint quelque chose de satisfaisant.

Alors bien sûr, il existe des frameworks à la pelle, des librairies, des approches, des patterns mais commencer un nouveau projet reste quelque chose de laborieux et ce constat peut être fait côté back ou front, peu importe.

IA pas de soucis

Badum tssss

Du coup forcément, 2023 oblige, nous avons enfin la solution à tous nos maux : l’IA ! Avant ça nous avions des outils de scaffolding mais ce n’était pas assez disruptif.

L’IA va donc se charger d’écrire ce code laborieux pour nous, en voilà une bonne idée ! De cette manière, nous pourrons nous concentrer sur le code métier, propre à notre problème, augmenter notre vélocité et proposer plus de valeur à nos utilisateurs (vous n’avez pas une impression de déjà vu ?) !

Mais ne peut-on pas aller encore plus loin ?

Personnellement, je pense que concernant ce code si trivial, ce code nécessaire mais sans grande valeur fonctionnelle, nous pouvons faire mieux. De mon point de vue, on pourrait même s’en passer ou en tout cas le rendre invisible pour ne plus s’en préoccuper.

Prenons un exemple simple que je trouve assez parlant, mais gardez en tête que le principe s’applique quelque soit le langage. Nous avons donc ci-dessous un code classique tiré de l’exemple Swagger de NestJS.

import { Injectable, Body, Controller, Get, Param, Post } from "@nestjs/common";
import {
  ApiBearerAuth,
  ApiOperation,
  ApiResponse,
  ApiTags,
  ApiProperty,
} from "@nestjs/swagger";
import { IsInt, IsString } from "class-validator";

class Cat {
  /**
   * The name of the Cat
   * @example Kitty
   */
  name: string;

  @ApiProperty({ example: 1, description: "The age of the Cat" })
  age: number;

  @ApiProperty({
    example: "Maine Coon",
    description: "The breed of the Cat",
  })
  breed: string;
}

class CreateCatDto {
  @IsString()
  readonly name: string;

  @IsInt()
  readonly age: number;

  @IsString()
  readonly breed: string;
}

@Injectable()
class CatsService {
  private readonly cats: Cat[] = [];

  create(cat: CreateCatDto): Cat {
    this.cats.push(cat);
    return cat;
  }

  findOne(id: number): Cat {
    return this.cats[id];
  }
}

@ApiBearerAuth()
@ApiTags("cats")
@Controller("cats")
export class CatsController {
  constructor(private readonly catsService: CatsService) {}

  @Post()
  @ApiOperation({ summary: "Create cat" })
  @ApiResponse({ status: 403, description: "Forbidden." })
  async create(@Body() createCatDto: CreateCatDto): Promise<Cat> {
    return this.catsService.create(createCatDto);
  }

  @Get(":id")
  @ApiResponse({
    status: 200,
    description: "The found record",
    type: Cat,
  })
  findOne(@Param("id") id: string): Cat {
    return this.catsService.findOne(+id);
  }
}

On a là quelque chose d’ultra commode. Un modèle, un service, un contrôleur. Le service nous retourne un DTO lors de la lecture et on expose tout ça via une API REST. Je vous passe toute la partie configuration du conteneur d’injection de dépendances.

D’ores et déjà, on peut remarquer des choses assez étonnantes : findOne(@Param("id") id: string), @IsString() readonly breed: string;, même si on comprend pourquoi ces annotations sont nécessaires, notre code est noyé sous tout un tas de considérations d’infrastructure, qui répète souvent des choses qu’on peut déduire des types eux-mêmes.

Si on prend de la hauteur, ce que nous voulons ici, en tant que développeur·se web, c’est bien exposer des cas d’utilisations métier et les rendre accessibles depuis l’extérieur, ici sous forme d’API REST mais cela pourrait prendre une autre forme, ça n’a pas d’importance.

Au final, ne serait-il pas plus logique d’avoir quelque chose dans ce genre :

class Cat {
  /**
   * The name of the Cat
   * @example Kitty
   */
  name: string;

  /**
   * The age of the Cat
   */
  age: number;

  /**
   * The breed of the Cat
   */
  breed: string;
}

class CreateCatDto {
  readonly name: string;
  readonly age: number;
  readonly breed: string;
}

class CatsService {
  private readonly cats: Cat[] = [];

  /**
   * Create cat.
   */
  create(cat: CreateCatDto): Cat {
    this.cats.push(cat);
    return cat;
  }

  /**
   * Find a cat by its id.
   */
  findOne(id: number): Cat {
    return this.cats[id];
  }
}

Nous pourrions nous contenter d’écrire ce code strictement nécessaire à l’accomplissement de notre métier et ensuite, s’appuyer sur un générateur pour produire la partie manquante en se basant à la fois sur les composants du langage utilisé (ici Typescript), comme par exemple les types, les commentaires de code, quand c’est nécessaire quelques annotations ou doc tags et pourquoi pas des conventions utilisées dans l’équipe (nommage, emplacement des fichiers, etc…).

Analyse statique et parsing du code

Ce qu’il faut bien comprendre, c’est que quand je parle de générer du code, il ne s’agit pas de le faire écrire par une IA, je parle bien d’une génération déterministe à base d’analyse statique du code comme on sait le faire depuis longtemps. Ce code généré ne ferait plus réellement parti de notre base de code comme avec les outils de scaffolding et pourrait évoluer au gré du temps, nécessitant uniquement une mise à jour puis re-génération sur notre projet facilitant ainsi sa maintenance.

Dans mon exemple au dessus, je pourrai par exemple demander à cet outil de me générer soit une API REST, soit un outil en ligne de commande permettant d’appeler les méthodes create et findOne de mon service, soit totalement autre chose.

Via l’analyse statique et le parsing du code, je peux déduire quels sont les paramètres attendus, les retours, la documentation et même les dépendances de mon service et comment les construire.

Adapter les outils à nos pratiques et non l’inverse

Le but serait de pouvoir configurer cette génération, non pas avec un fichier de configuration comme on en voit souvent (yaml, toml, json, …), mais avec un fichier qui utiliserai le même langage que la cible de génération, permettant ainsi de tirer parti des fonctionnalités de l’IDE.

Cette configuration de la génération pourrait permettre à une équipe de s’approprier l’outil et mettre en place des conventions réutilisées de projet en projet pour un maximum d’efficacité.

Par exemple, une équipe pourrait configurer l’outil pour que toutes les classes terminant par Service et possédant une méthode publique create aboutissent à une méthode POST sur une route /api/{nom de la classe sans le suffixe Service} en utilisant la documentation du code pour générer les spécifications OpenAPI.

Suite à la commande de génération, le serveur web serait alors prêt, documenté, monitoré, configurable, les services correctement instanciés suivant leurs dépendances sans d’autre intervention de la part de l’équipe et sans au final avoir à se préoccuper de ce qui a été généré.

Formidable ! Je signe où ?

Cela peut sembler utopique mais il existe déjà pas mal d’outils qui font des choses dans le même état d’esprit. Par exemple, on a des générateurs pour construire du code à partir d’une spécification OpenAPI, ce qui nous permet d’être sûr que les URLs sont les bonnes et que les types utilisés aussi.

En Typescript, on sait générer un validateur Zod depuis des types Typescript. Prisma génère le code typé nécessaire aux interactions avec une base de données depuis un schéma défini.

Cependant, il s’agit toujours d’initiatives isolées pour des briques spécifiques.

Le seul projet qui se rapproche de ce que j’ai réellement en tête est Encore qui, en Go, vous permet d’écrire des cas d’utilisations, de les exposer, d’appeler d’autres services distribués facilement, de gérer la configuration, le monitoring, des tâches Cron et de provisionner toute votre infrastructure en se basant sur votre propre code et en générant tout ce qui est nécessaire pour que votre application fonctionne.

De mon côté, je me suis amusé à faire quelques expérimentations en Go juste pour valider la faisabilité technique mais je n’ai aucun doute sur le fait qu’on pourrait imaginer quelque chose de malléable et d’extensible pour couvrir tous les besoins triviaux qu’on a de projet en projet.

La tâche est bien évidemment colossale mais est-ce qu’il ne s’agirait pas là d’un futur souhaitable ?