il suffit de regarder la conf des machines outils, leur code source, la liste des matières premières et hop tu as tout ce qu'il faut ! C'est ridicule.
Je ne pense pas que ce que dise Uncle Bob est ridicule, vu les ouvrages de référence qu'il a écrit (Clean Code, principe SOLID, etc.).
Si on déroule l'analogie, la conf des machines outils et les programmes d'usinage peuvent être comparés à la mécanique interne du compilateur : l'utilisation d'un arbre syntaxique abstrait ou d'une représentation bytecode intermédiaire par exemple. Chaque compilateur a son fonctionnement propre, et chacun produira à peu près la même sortie à partir du même code source, de la même façon qu'à partir d'un plan de conception on produira à peu près toujours la même pièce même avec des machines différentes ou des procédés de fabrication différents.
Comme toute analogie, elle a ses limites, mais elle me parait légitimer le code en tant que document de référence qu'il faut garder le plus lisible possible.
[^] # Re: la spec, c'est le code
Posté par mzf (site web personnel) . En réponse à la dépêche Développement très rapide d’applications libres : Extended Man/XML Frames. Évalué à 2.
Je ne pense pas que ce que dise Uncle Bob est ridicule, vu les ouvrages de référence qu'il a écrit (Clean Code, principe SOLID, etc.).
Si on déroule l'analogie, la conf des machines outils et les programmes d'usinage peuvent être comparés à la mécanique interne du compilateur : l'utilisation d'un arbre syntaxique abstrait ou d'une représentation bytecode intermédiaire par exemple. Chaque compilateur a son fonctionnement propre, et chacun produira à peu près la même sortie à partir du même code source, de la même façon qu'à partir d'un plan de conception on produira à peu près toujours la même pièce même avec des machines différentes ou des procédés de fabrication différents.
Comme toute analogie, elle a ses limites, mais elle me parait légitimer le code en tant que document de référence qu'il faut garder le plus lisible possible.