C'est sûr que quand tu travailles sur des projets simples, avec peu de conséquences, et peu d’interactions, se passer de la conception hors code c'est simple et confortable.
J'ai bossé sur des systèmes embarqués (sur des systèmes critiques ou non) et j'ai bien apprécié que le code ne soit pas la seule source de documentation :
Faut définir le lien matériel - chargeur de démarrage / noyau, heureusement que les gars du matériel ne disent pas lis mon schéma électronique pour comprendre exactement ce que je dois faire ;
Le lien noyau (pilotes) avec l'espace utilisateur doit être décrit, qui envoie quoi et quand à l'autre. Ce qui intéresse de part et d'autre c'est l’interaction entre ces composants (les entrées / sorties), pas les rouages internes pour essayer de déterminer les entrées / sorties de chacun ;
Pareil pour la communication entre les applications, ou avec une bibliothèque.
Bref, le code c'est la documentation c'est valable pour un logiciel isolé avec une équipe composée uniquement de codeurs, capable de lire le code ou la documentation générée. Mais ce n'est pas systématique. Quand je code un logiciel qui communique avec celui de mon collègue, j'apprécie de ne pas avoir besoin de connaître en détail son architecture pour savoir ce que je peux lui envoyer et ce que je dois recevoir. Ce qui m'intéresse ce sont les entrées / sorties et c'est tout.
Et la conception, pour des logiciels non enfouis, il y a souvent un non technicien qui va intervenir dans la conception de l'UX par exemple. Son rôle n'est pas de déterminer depuis le code (ou sa documentation) comment ça va s'afficher, les options proposées et autres. Il a besoin de documents qui ne gèrent que cela.
Du coup un document texte et des diagrammes UML c'est utile pour que tout le monde communique sans exclure les non codeurs. Cela me paraît essentiel.
[^] # 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.
C'est sûr que quand tu travailles sur des projets simples, avec peu de conséquences, et peu d’interactions, se passer de la conception hors code c'est simple et confortable.
J'ai bossé sur des systèmes embarqués (sur des systèmes critiques ou non) et j'ai bien apprécié que le code ne soit pas la seule source de documentation :
Bref, le code c'est la documentation c'est valable pour un logiciel isolé avec une équipe composée uniquement de codeurs, capable de lire le code ou la documentation générée. Mais ce n'est pas systématique. Quand je code un logiciel qui communique avec celui de mon collègue, j'apprécie de ne pas avoir besoin de connaître en détail son architecture pour savoir ce que je peux lui envoyer et ce que je dois recevoir. Ce qui m'intéresse ce sont les entrées / sorties et c'est tout.
Et la conception, pour des logiciels non enfouis, il y a souvent un non technicien qui va intervenir dans la conception de l'UX par exemple. Son rôle n'est pas de déterminer depuis le code (ou sa documentation) comment ça va s'afficher, les options proposées et autres. Il a besoin de documents qui ne gèrent que cela.
Du coup un document texte et des diagrammes UML c'est utile pour que tout le monde communique sans exclure les non codeurs. Cela me paraît essentiel.