Bonjour mes beautés.
Hier, en développant le client Busy React, j’ai réalisé que mon approche comportait deux failles critiques.
Le mauvais framework
1. React, c’est tout du magique, ce qui va totalement à l’encontre de ma religion du code. C’est une leçon que j’ai apprise à la dure il y a 18 ans. Le magique est TOUJOURS mauvais. Vouloir faire le malin, c’est être dangereux, et je refuse de le faire. Si un code ne peut pas être lu et compris simplement pour ce qu’il est, d’un seul coup d’œil, sans manuel, c’est que ce code n’est pas écrit correctement. Il y a un vrai binaire entre le juste et le faux ici, il le faut.
Donc React est le mauvais outil pour le job.
Et puis, j’aime beaucoup le JavaScript moderne. Et je ne pense pas avoir besoin d’un framework JS standardisé quand mon outil de développement (celui que j’utilise pour construire tout ça) est entraîné sur l’histoire des pratiques de codage humaines.
Laisser le système de plugins assembler l’UI
2. J’ai passé une semaine à bâtir ce système de plugins vraiment élégant. Il est parfait. Léger cognitivement, direct, intuitif. Des plugins petits, bien contenus, découplés, qui séparent clairement les responsabilités, démontrent des principes de conception et d’implémentation cohérents, s’étendent et se retravaillent entre eux, et s’intègrent sans couture dans un système central composé de dix fichiers qui ne changent jamais.
Quand vous verrez avec quelle fluidité ça tourne, et à quel point c’est facile à gérer et à comprendre, vous allez en tomber à la renverse. La beauté et la simplicité du truc sont incroyables.
Alors pourquoi j’essaie d’écrire une UI monolithique unique qui englobe tout ça sans parler à l’architecture de plugins elle-même ?
Eh bien, c’est une erreur de conception stupide.
Clairement.
En réalisant ça, j’ai étendu le système de plugins pour gérer l’UI dans le cœur, en faisant l’assemblage de l’UI avec les mêmes pratiques que pour le reste du système.
Maintenant, quand Busy build, il assemble la structure de l’UI centrale depuis le système cœur, et les modules ont des UI avec des manifestes d’UI qui expliquent au système cœur où ils sont placés et comment ils sont configurés.
Les responsabilités sont gérées un peu plus efficacement, et ça permet des différences dans l’organisation des modules, si jamais quelqu’un veut en écrire pour le futur.
Voyez les modules comme les bras, les jambes et les ordinateurs portables qu’on donne à ces agents LLM pour leur permettre d’agir sur le monde réel.
Suivre la donnée à travers l’application
Aussi, fini les tests unitaires stupides.
Pourquoi mon cerveau s’obstine-t-il à me dire qu’on a besoin de tests unitaires ? Lol
Les tests unitaires verrouillent l’architecture et ralentissent la cadence de développement, sans pour autant démontrer que votre code fonctionne. Votre code peut être structurellement correct et cassé en même temps. Les tests unitaires ne sont pas fiables, parce que des développeurs peu scrupuleux peuvent les régler pour qu’ils passent toujours, et ils ne résolvent pas le problème que vous essayez de résoudre en les utilisant.
Donc là aussi, c’est la mauvaise approche.
À la place, je codifie en utilisant des tests de flux et je fais des tests d’intégration dans mon processus. Je suis la donnée dans des morceaux spécifiques de l’application quand je veux les tester. Je la passe par des scénarios pour lesquels je sais qu’on a codé, et je regarde la donnée entrer, être traitée et ressortir de l’autre côté. Bah oui.
Ça marche bien pour moi jusqu’ici, mais je devrai peut-être revoir ma stratégie de test plus tard.
C’est une expérience en cours.
La suite bientôt.