Oui, après tout certains considèrent que les tests unitaires sont de la documentation, et certains disent qu'il faut absolument faire les tests avant de faire le code.
Il me semble donc intéressant d'envisager d'écrire la documentation avant d'écrire le code... C'est d'ailleurs un peu ce qu'on a fait pour Eiffel : définir la spécification complète du langage avant de l'implémenter... Et si le résultat n'est pas très populaire, je pense qu'on peut objectivement dire qu'il est d'une bonne qualité.
Dans le cadre de ma thèse, je suis amené à m'intéresser aux "entités" tournant autour des logiciels (libres, surtout), et à leur co-évolution. J'ai remarqué que ces derniers temps on avait tendance à parler de la documentation comme d'un pilier du logiciel (au même titre que le code source ou les rapports d'erreurs, par exemple), mais qu'elle était généralement négligée et surtout pas sérieusement prise en compte par les outils actuels.
Alors oui, maintenant on peut lancer un wiki/un site web/un planet en rapport avec le logiciel, mais toutes ces informations restent faiblement organisées et intégrées : on ne peut pas clairement et systématiquement associer une documentation avec une fonctionnalité, par exemple. Ce n'est sans doute pas trop grave pour l'utilisateur final, mais dans le cas des logiciels libres, il doit être possible (et normalement c'est espéré) que de nouvelles personnes viennent se joindre à l'équipe de développeurs, que d'autres s'en aillent, ...Bref qu'il y ait un roulement qui oblige une transmission aussi efficace que possible de la "présentation" du projet.
Ce qui serait super, ce serait que les forges intègrent ce genre de chose. La gestion des versions de la doc y serait certes nécessaire, mais de mon point de vue pas tant pour éviter le vandalisme que pour pouvoir marquer une co-évolution entre la documentation et le reste du projet. Imaginez qu'on puisse sans se prendre la tête découvrir en une heure l'évolution du projet et son état actuel, qu'on puisse voir de manière synthétique quels sont les éléments du projet, et à quoi ils servent... Cela faciliterait certainement la vie des nouveaux (et des pas nouveaux aussi, d'ailleurs) développeurs, et l'utilisateur pourrait avoir une documentation à jour, ou à défaut il pourrait déterminer là où elle pêche.
Peut-être que placer l'écriture de la documentation à côté de l'écriture du code source ou de la traduction valoriserait mieux celle-ci, et inciterait davantage de personnes à y participer.
[^] # Re: Peut-être que les développeurs bossent à l'envers ?
Posté par mgoeminne . En réponse à la dépêche Calenco : une solution pour la documentation des projets libres ?. Évalué à 4.
Il me semble donc intéressant d'envisager d'écrire la documentation avant d'écrire le code... C'est d'ailleurs un peu ce qu'on a fait pour Eiffel : définir la spécification complète du langage avant de l'implémenter... Et si le résultat n'est pas très populaire, je pense qu'on peut objectivement dire qu'il est d'une bonne qualité.
Dans le cadre de ma thèse, je suis amené à m'intéresser aux "entités" tournant autour des logiciels (libres, surtout), et à leur co-évolution. J'ai remarqué que ces derniers temps on avait tendance à parler de la documentation comme d'un pilier du logiciel (au même titre que le code source ou les rapports d'erreurs, par exemple), mais qu'elle était généralement négligée et surtout pas sérieusement prise en compte par les outils actuels.
Alors oui, maintenant on peut lancer un wiki/un site web/un planet en rapport avec le logiciel, mais toutes ces informations restent faiblement organisées et intégrées : on ne peut pas clairement et systématiquement associer une documentation avec une fonctionnalité, par exemple. Ce n'est sans doute pas trop grave pour l'utilisateur final, mais dans le cas des logiciels libres, il doit être possible (et normalement c'est espéré) que de nouvelles personnes viennent se joindre à l'équipe de développeurs, que d'autres s'en aillent, ...Bref qu'il y ait un roulement qui oblige une transmission aussi efficace que possible de la "présentation" du projet.
Ce qui serait super, ce serait que les forges intègrent ce genre de chose. La gestion des versions de la doc y serait certes nécessaire, mais de mon point de vue pas tant pour éviter le vandalisme que pour pouvoir marquer une co-évolution entre la documentation et le reste du projet. Imaginez qu'on puisse sans se prendre la tête découvrir en une heure l'évolution du projet et son état actuel, qu'on puisse voir de manière synthétique quels sont les éléments du projet, et à quoi ils servent... Cela faciliterait certainement la vie des nouveaux (et des pas nouveaux aussi, d'ailleurs) développeurs, et l'utilisateur pourrait avoir une documentation à jour, ou à défaut il pourrait déterminer là où elle pêche.
Peut-être que placer l'écriture de la documentation à côté de l'écriture du code source ou de la traduction valoriserait mieux celle-ci, et inciterait davantage de personnes à y participer.