Extrait de la newsletter TLDR Web Dev du 27 août 2025,

React-is-Awful

An AI generated book about React that teaches React and humorously complains about its complexity and design decisions.

Cette courte description a piqué ma curiosité autant pour le côté généré par IA que sur le fond avec un petit bonus pour la plainte humoristique.

Dès le README du dépôt git, le ton est donné :

What You'll Learn

• ❌ Why it exists (Facebook's notification counter was sometimes wrong)
• ❌ The Virtual DOM (a solution to a problem React created)
• ❌ JSX (HTML and JavaScript had a baby nobody asked for)
• ❌ Hooks (functions that remember things, breaking everything functions stand for)
• ❌ useEffect (the footgun you'll shoot yourself with)
• ✅ How to get a job anyway

et ce ton humoristique voire sarcastique se poursuit tout au long du livre et rend sa lecture très amusante ce qui est quand même rare dans un livre technique.

Cet ouvrage a donc, a priori, été généré par une IA générative (Claude) et si ce n'était pas précisé dès le départ, je suis pas certain que je l'aurais remarqué en le lisant. Il y a certes quelques tournures et enchaînements qui semblent un peu maladroits mais on en trouve aussi dans des livres écrits par des humains. Je serais quand même curieux de voir le ou les prompts qui permettent d'obtenir ce résultat.

Sur le fond, le livre vise plutôt juste dans ses critiques de React (en tout cas cohérentes avec ma propre expérience) et dans ses préconisations pour faire avec. Et contrairement à ce que pourrait suggèrer le titre, le livre reconnaît tout de même quelques mérites à React. Il n'y a guère que le chapitre sur les tests qui, certes, pointe un problème réel mais mériterait sans doute un peu plus de nuances. En vrai, ce chapitre pourrait faire l'objet d'un livre entier à lui tout seul 🫠

Bref, React-is-Awful est à la fois un ovni dans le paysage des livres techniques et un bon ouvrage pour approfondir la compréhension de React et des compromis que son usage impose.

Je commence donc par le premier qui me vient à l'esprit que j'aime bien exprimé avec la citation suivante attribuée à Antoine de Saint-Exupéry :

La perfection est atteinte, non pas lorsqu'il n'y a plus rien à ajouter, mais lorsqu'il n'y a plus rien à retirer.

En d'autres termes, je déclare la chasse au superflu ouverte 😃 En pratique, qu'est ce que cela signifie ?

L'application la plus évidente de ce principe consiste à éliminer ce qu'on appelle le code mort (dead code). Il s'agit sans doute de l'un des code smells les plus connus qui désigne le code qui ne peut pas être atteint. Équipé·e d'un bon IDE, de quelques outils d'analyse statique et de bons tests automatisés, il est relativement facile de le détecter et de l'éliminer au niveau d'une fonction ou d'un fichier. En revanche, au niveau d'un projet conséquent avec un peu d'historique (comprendre du code legacy 😜) c'est une autre histoire. Petite anecdote, il y a quelques mois, sur deux projets TypeScript j'ai poussé pour essayer de rationaliser l'usage du mot clé export en introduisant un script dans la CI pour détecter les changements qui incluent des export inutilisés (basé sur ts-unused-export) et pour progressivement éliminer les export inutilisés existants. Cette démarche s'inscrivait déjà dans une volonté de chasser le superflu mais mon but initial était surtout de faciliter le refactoring (sans mot clé export, on est certain d'avoir un périmètre limité au fichier) et au final, cet exercice a permis de déterrer une quantité de code mort plus que conséquente (plusieurs milliers de lignes de code 😮) qui n'était là que être exporté sans être utilisé et qui occasionnait de la confusion et zéro valeur ajoutée. Hop un peu moins de dette technique !

Si on prend un peu de hauteur, appliquer ce principe dans le design d'une API (d'une simple méthode comme d'une API web type REST ou GraphQL) est un bon outil pour s'éviter un peu de complexité. Par exemple, si une méthode accepte des paramètres optionnels mais qu'ils ne sont jamais utilisés ou que cette méthode reçoit un paramètre avec toujours la même valeur ou que sa valeur de retour n'est jamais utilisée vous avez probablement du superflu sous les yeux qui induit une certaine complexité et qui aurait tout intérêt à être éliminé pour améliorer la maintenabilité. On parle parfois de réduire la surface d'API. L'exercice est assez mécanique et d'autant plus simple si on l'applique à la création du code en question. Pour ce qui me concerne, c'est le genre de chose que je fais au fil de l'eau et que je vérifie dans une revue de code.

Si on prend encore un peu plus de hauteur, ce principe s'applique aussi très bien à l'ajout de toute fonctionnalité. Dit autrement, il est toujours intéressant de questionner la solution vis à vis du besoin qu'on cherche à satisfaire pour systématiquement en tirer l'essentiel et surtout en retirer tout le reste. Dans ce contexte, cette démarche permet de restreindre autant que possible le périmètre des changements et encore une fois de réduire la complexité mais également de permettre de se concentrer sur l'essentiel et d'obtenir un résultat satisfaisant le plus rapidement possible et, à partir de là, d'itérer jusqu'à atteindre une solution qui apporte suffisamment de valeur. Toute ressemblance avec l'un des principes du manifeste agile n'est PAS fortuite 😛 :

La simplicité – c’est à dire l'art de minimiser la quantité de travail inutile – est essentielle.

Et puis cette démarche va au delà du code et des fonctionnalités, elle s'applique par exemple très bien au workflow des développeur·ses. Qui n'a jamais subi un workflow (CI, CD, commit hook,…) plus lourd que nécessaire ? Ou à toutes ces réunions qui pourraient être un simple email 🫠 Ici, il s'agit plus d'un potentiel problème d'efficacité au quotidien mais là encore le superflu peut peser lourd.

Bref, sans surprise, identifier et chasser le superflu est un exercice bénéfique pour la qualité d'un projet logiciel et la productivité des développeur·ses. Plus qu'une simple habitude, pour moi, cette démarche doit être active et systématique. Je la considère comme une clé dans l'obtention d'un code maintenable sur le long terme et dans l'efficience au quotidien.

Je suis tombé aujourd'hui sur Quality is systemic de Jacob Kaplan-Moss que je trouve particulièrement juste.

Traduction rapide du premier paragraphe :

La qualité logicielle est plus le résultat d'un système conçu pour produire de la qualité et pas tellement le résultat de performances individuelles. C'est-à-dire : un groupe de programmeurs médiocres travaillant avec une structure conçue pour produire de la qualité produira un meilleur logiciel qu'un groupe de programmeurs fantastiques travaillant dans un système conçu pour d'autres objectifs.

En d'autres termes pour obtenir de la qualité il faut une organisation construite pour la produire. L'auteur donne quelques exemples de caractéristiques systémiques permettant de produire de la qualité :

• une organisation et une culture qui permettent et encouragent l'écriture de bons tests ;
• une culture qui ne pousse pas à mettre en production du code qui n'est pas prêt ou qui est inutile ;
• une cadence de développement qui permet de correctement architecturer le code et de le documenter ;
• un environnement de travail où les personnes se sentent en sécurité et n'hésitent pas à demander de l'aide au besoin ;
• une culture où les échecs sont analysés sans chercher de coupable et où le système est amélioré pour éviter les échecs similaires.

Je trouve ce dernier point particulièrement important. À titre personnel c'est quelque chose que je m'attache à toujours faire mais j'ai vu relativement peu d'organisations où c'était une démarche systématique.

Et il existe probablement des tas d'autres paramètres comme une culture qui permet une forme d'auto-organisation et offre une certaine liberté, une organisation où on ne travaille que sur un seul sujet à la fois ou encore une culture qui célèbre autant voire plus la suppression de code que l'ajout… Tout ceci fait largement écho à Maximiser l'efficacité des développeur·ses sous un angle plus… systémique.

En début d'année, j'ai lu Get Your Hands Dirty on Clean Architecture (Second Edition) de Tom Hombergs. Comme son titre l'indique, ce très bon livre traite de la Clean Architecture et plus particulièrement de l'architecture hexagonale. Tout au long des quelques 140 pages, l'auteur aborde ce type d'architecture sous différents aspects mais il en est un qui revient régulièrement tout en étant le sujet du premier chapitre : la maintenabilité.

Une bonne partie de ce premier chapitre peut se résumer par cette expression pseudo-mathématique :

maintenabilité >>> tout le reste

Dans tout le reste rentrent les qualités qu'on cherche souvent à atteindre dans la construction d'un logiciel par exemple les performances, la scalabilité, la robustesse, la flexibilité et bien d'autres… Et comme l'explique très bien l'auteur, la maintenabilité a ceci de spécial qu'elle est une qualité qui permet d'atteindre toutes les autres. En effet, dès qu'un logiciel est maintenable, il est facile à faire évoluer pour atteindre certaines qualités dès que le besoin émerge. Évidemment, l'ajout de fonctionnalités et la correction des bugs sont également d'autant plus simples que le code est maintenable. En d'autres termes, la maintenabilité aide à la fois à atteindre des objectifs fonctionnels et non fonctionnels.

Je formule généralement cette idée de la manière suivante :

Un bon code est un code facile à changer.

Ni plus, ni moins. Jusque là, rien de très original je crois mais ça va mieux en le disant 😁

Dans ce chapitre, Tom Hombergs pousse la réflexion un peu plus loin et notamment en énonçant ce qui m'apparaît maintenant comme un corollaire :

Whenever we have to decide between multiple options, we can choose the one that makes the code easier to change in the future. No more agonizing between different options. We just take the one that increases maintainability the most.

ce qui peut se traduire par :

Chaque fois que nous devons choisir entre plusieurs options, nous pouvons choisir celle qui rendra le code plus facile à changer dans le futur. Plus besoin de se torturer l'esprit entre différentes options. Nous choisissons simplement celle qui augmente le plus la maintenabilité.

Quand j'ai lu cette partie, je dois dire qu'une petite lumière s'est allumée dans ma tête 💡 J'ai beau être convaincu de l'importance de la maintenabilité depuis de nombreuses années maintenant, je n'avais jamais considéré cette qualité comme une aide à la décision de manière aussi directe. Et forcément, en regardant un peu dans le rétroviseur, je me rends compte qu'appliquer ce principe dans certaines décisions aurait potentiellement mener à de meilleurs choix.

Comme souvent avec ce genre de principe général, il s'agit d'un élément parmi beaucoup d'autres et comme l'indique Tom Hombergs, le bon choix n'est parfois pas celui qui améliore ou conserve la maintenabilité. Néanmoins opter pour ce principe par défaut me semble être une bonne approche.

Et si on les jetait à l'eau refactorisait ? 😀

Dans une revue de code ou en explorant une base code, ces noms là, tout comme dans une certaine mesure les handlers et autres managers, déclenchent systématiquement dans ma tête une petite alarme 🔔 qui appelle à aller regarder de plus près ce qui se cache derrière.

Ces termes sont très génériques même si ils sont souvent accompagnés d'un préfixe, d'un suffixe ou d'un chemin un peu spécifique (encore qu'on a tous dû tomber au moins une fois sur un src/utils.js quand ce n'est pas src/tools/utils.js 😉). Et par conséquent, la ou les responsabilités de ces composants sont loin d'être claires. D'ailleurs, ce genre de composant a une sérieuse tendance à être un fourre-tout avec beaucoup plus qu'une unique responsabilité.

Aussi, quand ce genre de composant occupe une place importante dans le code en terme de quantité de logique, c'est autant de logique qui n'est pas là où elle aurait plus de sens. L'utilisation abusive de ce genre de composant va de pair avec d'autres code smells, notamment :

• des objets anémiques : les objets métiers se retrouvent dépourvus de comportement puisqu'il est relégué dans ces helpers et utils ;
• un manque d'encapsulation : les objets exposent nécessairement plus qu'ils ne devraient pour que ces composants puissent faire leur travail ;
• des abstractions manquantes : là encore, une responsibilité qui pourrait être proprement isolée dans un composant bien nommé se retrouve diluée.

C'est pourquoi, en ce qui me concerne, chaque mention d'un utils ou d'un helper me rend plus que méfiant. Quasiment systématiquement il existe une meilleure solution en terme d'expressivité, de qualité de code et de maintenabilité.

J'ai écrit un petit blabla sur le tout neuf Developers blog de Front-Commerce (oui on a pas vraiment fait dans l'originalité 😉) sur quelques défis lié à l'édition d'un logiciel destiné à être intégré par rapport à d'autres contextes comme le service ou la distribution en SAAS.

Traduction libre de l'introduction:

Pour l'essentiel, Front-Commerce est un logiciel destiné à être intégré par des développeurs pour qu'un marchand puisse vendre des produits à ses clients dans une boutique en ligne à son image et même en s'appuyant sur une infrastructure existante. S'il s'agit probablement de la définition la plus simple de Front-Commerce (plus ou moins celle que j'utilise pour décrire mon travail à ma famille et mes amis 😉), elle cache néanmoins un certain nombre de défis au quotidien.

La suite va vous étonner est disponible dans Some challenges of being the editor of a software intended to be integrated (en anglais).

Voici une traduction de la partie Une journée dans un environnement hautement efficace (qui fait un peu rêver mais c'est plus agréable à lire que l'exemple de basse efficacité 😉):

La développeuse ou le développeur :

• consulte dans l'outil de gestion de projet et assiste au standup où les tâches à accomplir sont sans ambiguïté
• constate que l'environnement de développement a été automatiquement mis à jour, notamment les dépendances sont à jour et cohérente avec la production et les vérifications automatiques sur la CI/CD passent avec succès
• récupère la dernière version du code et fait des changements incrémentaux sur le code qui sont rapidement vérifiés par des tests unitaires et déployés sur un environnement local
• en cas de dépendance avec une autre équipe, la documentation et/ou les spécifications des APIs sont facilement accessibles sur un portail dédié. En cas de nécessité, il ou elle peut facilement et rapidement obtenir de l'aide auprès de ses collègues par exemple sur Slack
• peut se concentrer sur sa tâche pendant plusieurs heures sans interruptions
• peut faire une pause, prendre un café, aller faire un tour à pied ou jouer au tennis de table avec les collègues
• commit les changements dans le code qui sont alors examinés par des tests automatisés avant d'être déployés en production. Les utilisateur·rices reçoivent les mises à jour progressivement, ce processus est monitoré.

En bref, le développeur ou la développeuse est en capacité de faire des changements incrémentaux dans une journée et peut rentrer à la maison avec la satisfaction d'avoir progressé.

J'ai ajouté du gras sur les parties qui me semblent essentielles. Bien sûr certains aspects dépendent fortement du contexte notamment le déploiement en production et la réception des mises à jour par les utilisateur·rices correspondent bien au développement d'un logiciel de type SaaS moins à un logiciel au sens plus traditionnel du terme.

En résumé, dans un environnement de haute efficacité :

• les tâches à réaliser sont sans ambiguïté, en d'autres termes elles ont été spécifiées et discutées pour avoir pour chacune, une vision claire du problème à résoudre, de la cible et des cas d'utilisation (use cases) et si en plus le périmètre a été réduit à son strict minimum, c'est parfait ;
• les tâches récurrentes et/ou celles où l'intervention humaine n'a aucune valeur ajoutée sont automatisées. Je pense bien sûr aux tests mais également aux mises à jour de dépendances, au déploiement ou encore au formatage du code ;
• l'environnement de travail est performant autant en terme de matériel que sur la plateforme de CI/CD. Le but étant d'avoir un certain confort mais surtout des boucles de feedback les plus courtes possible ;
• chacun·e travaille sur un unique sujet à la fois mais comme une vraie équipe, le multitâche c'est pour les ordinateurs (et encore !) ;
• chacun·e peut se concentrer sans être interrompu ;
• les applications sont monitorées correctement pour détecter au plus vite les soucis et avoir des données d'utilisation réelles et fiables ;
• les développements se font de manière incrémentale ce qui signifie notamment travailler systématiquement sur le plus petit périmètre possible et itérer jusqu'à obtenir un résultat satisfaisant (Better done than perfect) ;
• une certaine autonomie est laissée dans la manière de travailler (outils, rythme,…).

Cette liste ressemble à de l'enfonçage de portes ouvertes et pourtant, pour ce qui me concerne, je crois pas avoir un connu d'environnement qui cochait toutes les cases même si en général, mais pas toujours, la dynamique était plutôt dans le bon sens.

Bref, tout ceci touche à ce qu'on appelle parfois la Developer eXperience (DX) et qui, bien trop souvent, n'est pas prise en compte suffisamment sérieusement.

Voici un résumé des principales idées du livre « Clean Code: A Handbook of Agile Software Craftsmanship » de Robert C. Martin (Uncle Bob).

Du code est propre (clean) si il peut être compris facilement - par chaque personne de l'équipe. Un code propre (Clean code) peut être lu et amélioré par un·e développeur·se autre que la personne qui l'a écrit. Avec la compréhensibilité vient la lisibilité, la facilité à changer, l'extensibilité et la maintenabilité.

Règles générales

1. Suivez des conventions reconnues.
2. Keep it simple stupid. Plus simple est toujours mieux. Réduisez la complexité autant que possible.
3. Règle du boy scout : laissez le camp plus propre que l'état dans lequel vous l'avez trouvé.
4. Lors de résolution d'un problème, toujours chercher et trouver la cause racine.
5. Suivez le principe de moindre surprise.
6. DRY : ne vous répétez pas, et mais attention à l'interprétation de ce principe.

Règles de design

1. Gardez les données configurables (par exemple les constantes) à hauts niveaux. Elles devraient être faciles à changer.
2. Préférez le polymorphisme aux if/else ou switch/case.
3. Évitez la sur-configurabilité et tout ce qui n'a pas prouvé sa nécessité.
4. Utilisez l'injection de dépendances.
5. Suivez la loi de Déméter : une classe ne devrait connaître que ses dépendances directes.

Astuces pour la compréhensibilité

1. Soyez cohérent. Si vous faites quelque chose d'une certaine manière, toutes les choses similaires devraient être faites de la même manière.
2. Utilisez des noms de variables explicites.
3. Encapsulez les conditions limites : elles sont compliquées à suivre. Il vaut mieux les isoler à un endroit.
4. Préférez des value objects spécifiques plutôt que des types primitifs
5. Évitez les dépendances logiques : n'écrivez pas de méthodes qui dépendent d'autre chose dans la même classe.
6. Évitez les conditions négatives.

Règles de nommages

1. Choisissez des noms descriptifs et sans ambiguïté.
2. Faites des distinctions qui ont du sens.
3. Utilisez des noms prononçables.
4. Utilisez des noms cherchables.
5. Remplacez les nombres magiques par des constantes bien nommées.
6. Évitez d'ajouter des préfixes ou des informations sur les types.

Règles relatives aux fonctions

1. Courtes.
2. Ne fait qu'une chose et la fait bien.
3. Utilisez des noms descriptifs.
4. Préférez les avec le moins d'arguments possibles, idéalement pas plus de 3.
5. Sans effet de bord.
6. N'utilisez pas de flag : écrivez plutôt plusieurs méthodes sans ce type d'argument.

Règles relatives aux commentaires

1. Essayez d'écrire du code expressif ne nécessitant pas de commentaire. Si c'est impossible, prenez le temps d'écrire un bon commentaire.
2. Ne soyez pas redondant (par exemple : i++; // increment i).
3. N'ajoutez pas de bruit évident.
4. N'utilisez pas les commentaires de fermeture de bloc (par exemple : } // end of function).
5. Ne commentez pas de code. Supprimez ce code.
6. Utilisez des commentaires pour expliquer l'intention.
7. Utilisez des commentaires pour avertir des conséquences.

Structure du code source

1. Séparez les concepts verticalement.
2. Le code lié devrait apparaître dense verticalement.
3. Déclarez les variables à proximité de leurs usages.
4. Les fonctions dépendantes les unes des autres devraient être à proximité.
5. Les fonctions similaires devraient être à proximité les unes des autres.
6. Placez les fonctions dans la direction descendante.
7. Gardez les lignes courtes.
8. N'alignez rien horizontalement.
9. Utilisez des espaces pour associer des choses liées et dissocier des choses liées faiblement.
10. Ne cassez pas l'indentation.

Objets et structures de données

1. Cachez les structures internes.
2. Devraient être petits.
3. Ne font qu'une chose.
4. Possèdent un petit nombre de variables d'instance. Si votre classe a trop de variables d'instance, il est probable que votre objet fasse plus qu'une chose.
5. Une classe de base ne devrait rien connaître de ses classes dérivées.
6. Il vaut mieux avoir plusieurs fonctions que de passer du code à une fonction pour qu'elle choisisse un comportement.
7. Préférez des méthodes non statiques.

Tests

1. Un concept par test.
2. Rapides.
3. Indépendants.
4. Répétables.
5. Auto validants.
6. Utiles.
7. Lisibles.
8. Faciles à lancer.
9. Utilisez un outil de génération de couverture de code.

Indicateurs d'un code pas terrible (Code smells)

1. Rigidité : le logiciel est difficile à faire évoluer. Une petite modification peut causer une cascade de changements.
2. Fragilité : le logiciel dysfonctionne en plusieurs endroits en réponse à un unique changement.
3. Immobilité : vous ne pouvez pas réutiliser une partie du code dans d'autres projets car cette opération est risquée ou nécessite un grand effort.
4. Complexité inutile.
5. Répétition inutile.
6. Opacité : le code est difficile à comprendre.

Gestion des erreurs

1. Ne mélangez pas la gestion des erreurs et le code.
2. Utilisez des Exceptions au lieu de renvoyer des codes d'erreurs.
3. Ne retournez pas null, n'utilisez pas null non plus.
4. Lancer des exceptions avec du contexte.

L'abstraction comme outil de diminution de la charge cognitive

Cet énoncé peut sembler contre-intuitif et pourtant l'abstraction peut être un outil au service d'une certaine simplification :

Une bonne abstraction, en éliminant le besoin de connaitre les détails d’implémentation, est un outil particulièrement puissant pour diminuer la charge cognitive. Attention à ne pas créer des abstractions inutiles, ou d'abstraire trop tôt certains concepts : l’over-ingénierie n’est jamais très loin. Et vous vous retrouvez avec la situation inverse de celle que vous espériez.

Comme toujours dans le monde du développement, tout est question de dosage et surtout de compromis dont les termes doivent être compris et choisis au lieu d'être subis.

Combattre la complexité au lieu de la célébrer

Ce point est pour une bonne part une question d'état d'esprit.

[…] des intervenants qui se vantent d’avoir réussi à construire des systèmes aussi compliqués […]

Malheureusement, ce que ces gens prouvent, c’est qu’ils sont capables de travailler dans un contexte de très forte charge cognitive.

Et ce faisant, ils compliquent d’autant plus le travail de leurs futurs collègues en les obligeant à devoir absorber une plus grande charge cognitive pour pouvoir intervenir sur le projet.

Tout le problème réside dans le fait que la complexité est à la fois très attrayante intellectuellement et particulièrement gênante sur le long terme dès qu'il s'agira de maintenir et de faire évoluer un bout de code trop complexe.

Cette partie me rappelle une citation assez célèbre de Brian Kernighan. Je ne sais pas si il faut vraiment être deux fois plus intelligent·e pour débugguer un bout de code que pour l'écrire initialement, en revanche, je suis certain que la corrélation est forte entre l'intelligence mise dans l'écriture initiale et celle nécessaire à la sur la maintenance.

Et un peu hors-sujet :

• Ce que vous ne voyez pas (fr) : La France devient-elle un état policier ?

(En plus du flux RSS global, les billets veille et uniquement ceux là sont listés dans le flux RSS correspondant)