J'aime bien l'analogie avec un bâtiment, ça semble en effet plus proche de ce qu'on devrait faire dans le logiciel.
Le code source, ça serait donc l'équivalent des plans d'architecte.
La grosse différence, c'est que passer du code source au binaire prend au pire quelques heures (sur un très gros projet). Du coup, mettre le truc en production et continuer à faire des changements ensuite ne pose pas de problèmes, on peut facilement générer de nouvelles versions.
Par contre, en faisant ça on peut avoir plein d'autres problèmes (migrations de schémas de bases de données, ce genre de choses).
Mais pour revenir à l'exemple de la construction d'un aéroport qui a été mentionné plus haut: je ne crois pas que l'architecte se lance tête baissée dans la réalisation des plans. Je ne crois pas non plus que le plan donne toutes les informations. Par exemple, il n'indiquera pas le nombre de passagers par jour attendus, ce qui est quand même un élément important pour comprendre les choix qui ont été faits. Ou le type d'avions qu'on veut pouvoir accepter (la piste d'atterrissage est trop courte pour un A380: est-ce que c'est un problème?)
Changer ces données en cours de projet et essayer de modifier les plans pour correspondre, c'est pénible et compliqué. Même en ignorant la partie "compilation" ou construction du bâtiment à partir des plans. Au bou d'un moment, l'architecte en a marre que son client change d'avis tout le temps et il n'a pas envie de jeter ses plans et de tout recommencer une 15ème fois. C'est là que la qualité du travail fourni baisse.
Existe-t-il un atelier pour le développement très rapide de plans d'aéroports? Comment fait-il pour prendre en compte toutes les contraintes? (les montagnes ou buildings ou zones résidentielles à proximité, etc). Est-ce que ça marche aussi si on veut construire un port maritime ou une gare? ou un supermarché?
[^] # Re: la spec, c'est le code
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Développement très rapide d’applications libres : Extended Man/XML Frames. Évalué à 4. Dernière modification le 26 octobre 2017 à 11:18.
J'aime bien l'analogie avec un bâtiment, ça semble en effet plus proche de ce qu'on devrait faire dans le logiciel.
Le code source, ça serait donc l'équivalent des plans d'architecte.
La grosse différence, c'est que passer du code source au binaire prend au pire quelques heures (sur un très gros projet). Du coup, mettre le truc en production et continuer à faire des changements ensuite ne pose pas de problèmes, on peut facilement générer de nouvelles versions.
Par contre, en faisant ça on peut avoir plein d'autres problèmes (migrations de schémas de bases de données, ce genre de choses).
Mais pour revenir à l'exemple de la construction d'un aéroport qui a été mentionné plus haut: je ne crois pas que l'architecte se lance tête baissée dans la réalisation des plans. Je ne crois pas non plus que le plan donne toutes les informations. Par exemple, il n'indiquera pas le nombre de passagers par jour attendus, ce qui est quand même un élément important pour comprendre les choix qui ont été faits. Ou le type d'avions qu'on veut pouvoir accepter (la piste d'atterrissage est trop courte pour un A380: est-ce que c'est un problème?)
Changer ces données en cours de projet et essayer de modifier les plans pour correspondre, c'est pénible et compliqué. Même en ignorant la partie "compilation" ou construction du bâtiment à partir des plans. Au bou d'un moment, l'architecte en a marre que son client change d'avis tout le temps et il n'a pas envie de jeter ses plans et de tout recommencer une 15ème fois. C'est là que la qualité du travail fourni baisse.
Existe-t-il un atelier pour le développement très rapide de plans d'aéroports? Comment fait-il pour prendre en compte toutes les contraintes? (les montagnes ou buildings ou zones résidentielles à proximité, etc). Est-ce que ça marche aussi si on veut construire un port maritime ou une gare? ou un supermarché?