Creation and Curation; Greppability is an underrated code metric; How to Fix a Bug, Tests, Hypotheses, Timeboxes; What Really Makes Toyota’s Production System Resilient
Who knows, maybe with a digital world filled with low-quality garbage we’ll find refuge in old-school printed magazines.
Ça parle bien sûr de GenAI. Longue vie à la curation !
It turns out that splitting up, or dynamically constructing identifiers is a bad idea
Un court article. Aucune citation particulière, tout se trouve dans les titres intermédiaires. Ce n'est pas que l'article est particulièrement éclairant, mais "chaines" à rendre "greppable" peut servir d'aide mémoire. J'ai souvent beaucoup bénéficié d'un nommage homogène et explicite pour des audits de code. Mais, sur ma dernière mission, j'ai eu d'autant plus besoin de telles caractéristiques pour faire émerger un schéma d'architecture d'un ensemble de 50 microservices (chacun dans son repository git). Parce que certaines chaines étaient répétées avec la même structure, j'ai pu faire émerger un fichier au format c4 model qui m'a généré le schéma en question (et m'a de fait réaliser qu'on était dans une belle galère).
Seul point de l'article qui m'hérisse les poils :
You’re better off biting the bullet and returning the object directly
Comment casser un découplage utile. C'est une bonne façon de se faire très mal sur la durée.
“There is never enough time to do it right, but there is always enough time to do it over.”
— John W. Bergman
That said, I find that for complicated bugs, this process avoids a lot of diving into the wrong rabbit holes, chasing wild geese, doggedly unnecessarily rewriting entire chunks of code with your head in the sand. Instead of these animal metaphors, you can be rational about bugs. The group mind identifies better hypotheses; priorities and timeboxes avoid getting into a flow state for the wrong hypothesis.
Démarrer par un test je l'avais, mais pas tout le process qui suit. L'idée de faire échouer à la CI par un test, je dirais que ça dépend aussi de la criticité : si le bug provoque un incident en prod, alors peut être qu'on voudrait explicitement arrêter d'empiler du code, arrêter le flux de production, le temps de résoudre le problème ? Ça m'a fait penser aux chaines de production Toyota, qu'on arrête quand il y a un problème dans la production, et où l'amont, l'aval et d'autres services peuvent rejoindre le groupe pour aider à apprendre et résoudre le problème.
The Toyota Production System is an organizational culture as much as it is a factory operating system. Its core philosophy — to motivate and develop people so that they can surface and solve problems quickly and build a culture of continuous improvement — obviously extends beyond the company’s own walls to include its suppliers.
Ce que je retiens : Le système socio-technique (gens, software, hardware d'usine) n'est pas seulement conçu pour un résultat de production, mais aussi et peut-être surtout pour l'apprentissage à atteindre de meilleurs résultats de production.
