Dans l'ingénierie traditionnelle on prend les documents de conception et on construit l'objet, et dans l'informatique on fait exactement la même chose sauf que les documents de conception sont les fichiers sources !
Bah non, la conception n'est pas le code source qui en est une implémentation.
Une spécification, qui est le résultat de la conception, ne peut être exprimée convenablement dans un code source car cela n'est pas son but. Le code source décrit un programme, des algorithmes.
Je veux dire, une spécification, ce n'est pas juste décrire les limites du programmes ou ce qu'il fait. C'est aussi expliquer des choix de conception. Et ça, tu en trouves rarement dans le code source. Et oui, ton produit n'a pas que des limitations techniques (genre le nombre d'imbrications du fichier JSON acceptable), c'est aussi exprimer que le système doit démarrer en moins de 60 secondes, que par défaut on souhaite qu'une certaine interface soit présentée, etc. Décisions qui impactent souvent des non codeurs (ergonomes, client, etc.) et qui ne sont pas dans le code source car son but n'est pas de collecter les comptes rendus de réunion de spécification mais d'expliquer son code.
C'est donc le compilateur qui construit le logiciel et la différence avec l'ingénierie de biens matériels c'est que le temps et le coût de génération sont très petits.
Mouais, concevoir un logiciel un peu conséquent, cela prend des années. Certes le logiciel peut faire des mises à jour progressive, faire des prototypes et tout. Mais un gros projet c'est loin d'être si différent en coût par rapport à la production d'un bien manufacturé.
Puis le début de ta phrase est fausse. Le compilateur transforme le code source en un exécutable exploitable par la machine. Ce n'est pas lui qui conçoit et doit améliorer le logiciel à l'avenir. Si on va dans ton sens, un produit manufacturé n'a pas besoin de spécifications non plus, car comme c'est la chaîne d'assemblage qui réalise le produit final, 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.
[^] # Re: la spec, c'est le code
Posté par Renault (site web personnel) . En réponse à la dépêche Développement très rapide d’applications libres : Extended Man/XML Frames. Évalué à 8.
Bah non, la conception n'est pas le code source qui en est une implémentation.
Une spécification, qui est le résultat de la conception, ne peut être exprimée convenablement dans un code source car cela n'est pas son but. Le code source décrit un programme, des algorithmes.
Je veux dire, une spécification, ce n'est pas juste décrire les limites du programmes ou ce qu'il fait. C'est aussi expliquer des choix de conception. Et ça, tu en trouves rarement dans le code source. Et oui, ton produit n'a pas que des limitations techniques (genre le nombre d'imbrications du fichier JSON acceptable), c'est aussi exprimer que le système doit démarrer en moins de 60 secondes, que par défaut on souhaite qu'une certaine interface soit présentée, etc. Décisions qui impactent souvent des non codeurs (ergonomes, client, etc.) et qui ne sont pas dans le code source car son but n'est pas de collecter les comptes rendus de réunion de spécification mais d'expliquer son code.
Mouais, concevoir un logiciel un peu conséquent, cela prend des années. Certes le logiciel peut faire des mises à jour progressive, faire des prototypes et tout. Mais un gros projet c'est loin d'être si différent en coût par rapport à la production d'un bien manufacturé.
Puis le début de ta phrase est fausse. Le compilateur transforme le code source en un exécutable exploitable par la machine. Ce n'est pas lui qui conçoit et doit améliorer le logiciel à l'avenir. Si on va dans ton sens, un produit manufacturé n'a pas besoin de spécifications non plus, car comme c'est la chaîne d'assemblage qui réalise le produit final, 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.