diff --git a/content/newsletter/craft-letter-21.md b/content/newsletter/craft-letter-21.md new file mode 100644 index 0000000..7058ae2 --- /dev/null +++ b/content/newsletter/craft-letter-21.md @@ -0,0 +1,93 @@ +Title: Lettre n°21 — 27 avril 2026 +Date: 2026-04-27 09:00 +Category: Newsletter +JsonLD: + + +## Édito + +Vous avez pu remarquer un problème lors de la publication de la newsletter #19, qui a été envoyée un vendredi au lieu du lundi. J’avais oublié de cliquer sur un bouton pour l’envoi, et ne m’en suis rendu compte que quelques jours plus tard. C’est un des rares points que je n’ai pas encore automatisés. C’est comme pour le développement, il y a toujours des améliorations à apporter au processus. + +À propos d’améliorations : sur [le site](https://www.craftletter.fr) sur lequel vous pouvez retrouver tous les numéros, il est dorénavant possible de créer des liens vers chacun des sujet évoqués. Merci à Luc, qui m’a guidé vers la solution ! + + +## Générer des cartes + +Felix Turner explique comment [générer de superbes cartes](https://felixturner.github.io/hex-map-wfc/article/)🇬🇧 à base d’hexagones, avec des routes, des étendues d’eau, des arbres, des bâtiments, du relief… Il ne rentre pas dans les détails très techniques, car le sujet est complexe, mais explique néanmoins les difficultés qu’il a rencontrées et comment il s’en est sorti. Cliquez sur _Build All_ dans [la démo](https://felixturner.github.io/hex-map-wfc/)🇬🇧 pour voir le résultat. + +## Une migration sans interruption de service qui divise par 6 la facture d’hébergement + +Isa Yeter décrit toutes les étapes que son équipe a suivies pour [migrer un service](https://isayeter.com/posts/digitalocean-to-hetzner-migration/)🇬🇧 comportant 30 bases de données MySQL, 34 serveurs Nginx, une version obsolète de Linux, un serveur Neo4J, des instances de Gitlab et Gearman —le tout sans interruption de service. En passant d’un hébergeur US à un hébergeur européen, ils ont divisé leur facture par six. + +## TruffleRuby, un Ruby plus performant + +Ruby est un langage sympathique, mais dont les performances sont faibles en comparaison de celle des langages compilés. [TruffleRuby](https://github.com/truffleruby/truffleruby)🇬🇧 est une implémentation alternative de Ruby, basée sur GraalVM, qui améliore significativement la rapidité d’exécution du code, tout en étant compatible avec Ruby 3.4. + +## Comment mener 2000 développeurs vers du numérique responsable ? + +Tristan Nitot a imaginé la loi d’EROOM, qui, à l’opposé de la loi de MOORE, vise à optimiser les logiciels pour qu’ils tirent un meilleur parti du matériel. L’objectif de cette loi est de réduire le renouvellement incessant du matériel informatique et l’impact environnemental considérable qui en découle. + +Avec Romain Taillade, ils expliquent [comment cette démarche a été mise en oeuvre chez Décathlon](https://blog.octo.com/la-duck-conf-2026-comment-mener-2000-developpeurs-vers-du-numerique-plus-responsable)🇫🇷. La [vidéo de leur intervention](https://www.youtube.com/watch?v=3Xtvw8LdYWg&list=PLXlbmbYadKH4bFiVhW9-VEG6pC7rOyBic)🇫🇷 est également disponible. + +## Les nouveautés de Git 2.54 + +[La version 2.54](https://github.blog/open-source/git/highlights-from-git-2-54/)🇬🇧 de Git introduit la commande `git history`, une alternative plus simple à `git rebase -i` pour corriger un commentaire ou diviser un commit en deux. Avec cette version, il devient aussi possible de configurer des hooks communs à tous vos projets. + +## Code for Thought + +Peter Schmidt anime [Code for Thought](https://pweschmidt.github.io/offerings/CodeForThought/)🇬🇧, un podcast dans lequel il reçoit des chercheurs ou chercheuses en développement logiciel. Il a la particularité d’être trilingue : en fonction des invité·es, les épisodes sont en anglais, en allemand, ou en français. + +## Ce qu’Async promettait, et ce qu’il a délivré + +Josh Segall compare des solutions que des designers de langages ont apporté au problème de l’exécution concurrente de code : les threads, les callbacks, les promesses (*Promise/Future*), et Async / Await. Il montre comment [chacune de ces solutions simplifie l’écriture par rapport à la précédente, mais introduit de nouveaux problèmes](https://causality.blog/essays/what-async-promised/)🇬🇧. + +## Pourquoi je n’enchaîne plus tout en JavaSscript +Math Smith trouve que les [enchaînements de fonction en JavaScript](https://allthingssmitty.com/2026/04/20/why-i-dont-chain-everything-in-javascript-anymore/) 🇬🇧 peuvent s’avérer contre-productifs dès qu’il y en a plus de deux. Il décrit les patterns qu’il emploie pour rendre le code plus compréhensible. + +## Les lois de l’ingénierie logicielle + +Milan Milanovic a compilé et détaillé [les lois](https://lawsofsoftwareengineering.com/) 🇬🇧 empiriques qui régissent le développement logiciel : loi de Conway, optimisation prématurée, théorème de CAP… Certaines lois se renforcent mutuellement, tandis que d’autres se contredisent. Pour chacune, il résume ce qu’il faut en retenir, donne des exemples, rappelle son origine et fournit des pointeurs vers des lectures complémentaires. + +Sur le même sujet, Stéphane Trebel, a donné [une conférence](https://www.youtube.com/watch?v=h3-5pjQaKz8)🇫🇷. + +## Comment gérer la dette technique ? + +Milan Milanovic —encore lui !— revient sur le concept de [dette technique, explique pourquoi il est important de la traiter, et comment faire](https://newsletter.techworld-with-milan.com/p/how-to-deal-with-technical-debt)🇬🇧. + +L’accumulation de dette technique ralentit les équipes de développement. Elle provoque frustration et burnouts parmi les développeurs, mais les équipes produit n’en tiennent pas toujours compte. + +Le principal problème c’est que la dette technique est un concept abstrait. Il est donc nécessaire de la rendre explicite et visualisable. Et comme elle est inévitable, il faut mettre en place une stratégie pour la réduire. +### Les types de dette technique + +Milan distingue huit catégories principales de dette technique : + +* mauvaise **qualité du code** : pas clair, complexe, mal conçu, trop commenté ; +* **tests** insuffisants ou ne respectant pas la pyramide des tests ; +* **couplage** entre les modules ; +* **dépendances et outils** obsolètes ; +* **process manuels** (build, déploiement…); +* **architecture** inexistante ou inadaptée ; +* manque de **documentation** ; +* absence de **partage des connaissances**. + +### Comment mesurer la dette technique ? + +Milan définit le ratio de dette technique comme le rapport entre le coût de la correction d’une application et le coût de son développement. S’il est supérieur à 5%, le logiciel est en mauvais état. Au-delà de 50%, il faut se poser la question d’une réécriture ou d’un abandon du logiciel. + +Les outils d’analyse statique, les métriques DORA (Accelerate), la couverture de code par les tests fournissent des indicateurs sur le niveau de dette. Ils peuvent être complétés par des sondages réguliers de l’équipe technique, à qui l’on demande de la noter de 1 à 10. Comme souvent, c’est la variation au fil du temps qui est intéressante, plus que la valeur absolue. + +### Comment lutter contre la dette technique ? + +Il faut prioriser, parmi les problèmes identifiés par l’équipe, ceux qui impactent des développements en cours ou à venir, et qui s’aggravent au fil du temps. + +Milan Milanovic recommande la stratégie suivante : + +1. rendre les problèmes visibles et compréhensibles par tous, notamment avec des graphiques ; +2. identifier clairement les responsabilités ; +3. prioriser les tâches en fonction de leur impact ; +4. allouer du temps à la correction de la dette technique, en fonction de son importance. Cela va de la règle du boy scout, à la mise en place d’une équipe, en passant par l’allocation de journées dédiée ; +5. mesurer les progrès à l’aide de métriques. + +### Comment éviter la création de la dette technique ? + +La solution de Milan consiste à appliquer les pratiques de l’eXtreme Programming et du Software Craft, comme le refactoring permanent, le TDD, le pair-programming… et à choisir une architecture en fonction des résultats souhaités. diff --git a/content/pages/index.md b/content/pages/index.md index c75b8ba..2127bc7 100644 --- a/content/pages/index.md +++ b/content/pages/index.md @@ -1,14 +1,14 @@ Title: Accueil -Date: 2026-04-20 09:00 +Date: 2026-04-27 09:00 URL: save_as: index.html Category: Home -JsonLD: { "@context": "https://schema.org", "@type": "WebPage", "name": "Accueil", "description": "Lettre de veille technologique en développement logiciel", "image": [ "https://www.craftletter.fr/images/craftletter.svg" ], "datePublished": "Mon Apr 20 2026 09:00:00 GMT+0200 (Coordinated Universal Time)", "author": { "@type": "Person", "name": "Pascal Le Merrer", "url": "https://www.linkedin.com/in/pascal-le-merrer/" } } +JsonLD: { "@context": "https://schema.org", "@type": "WebPage", "name": "Accueil", "description": "Lettre de veille technologique en développement logiciel", "image": [ "https://www.craftletter.fr/images/craftletter.svg" ], "datePublished": "Mon Apr 27 2026 09:00:00 GMT+0200 (Coordinated Universal Time)", "author": { "@type": "Person", "name": "Pascal Le Merrer", "url": "https://www.linkedin.com/in/pascal-le-merrer/" } } -# La [lettre n°20]({filename}/newsletter/craft-letter-20.md) est parue ! +# La [lettre n°21]({filename}/newsletter/craft-letter-21.md) est parue ! La Craft Letter est une newsletter hebdomadaire dans laquelle je partage des articles issus de ma veille technologique. Vous y trouverez des articles relatifs au développement logiciel d'une façon générale, qu'il soit front-end, back-end ou autre. Mais aussi des articles consacrés à l'architecture logicielle, la méthodologie, les outils, des projets open source, des conférences... @@ -37,6 +37,7 @@ Pour savoir qui je suis, ou pourquoi j'écris cette lettre, je vous invite à vo # Archives +* [Lettre n°21]({filename}/newsletter/craft-letter-21.md) * [Lettre n°20]({filename}/newsletter/craft-letter-20.md) * [Lettre n°19]({filename}/newsletter/craft-letter-19.md) * [Lettre n°18]({filename}/newsletter/craft-letter-18.md)