Tu prends mes commentaires un peu trop au pied de la lettre .....
Payer ne te donne pas de garantie que ce soit propre et clair, juste une personne à blâmer si ça ne l'est pas et l'impression d'avoir un levier. Tu peux avoir du propre et du clair aussi bien en libre qu'en non-libre et le crade et pas clair n'est pas l'apanage du libre non plus.
Là n'est pas la question : tu sépares la doc du code et cette approche est bien plus rapide que de tout mettre dans le code. Après si quelqu'un veut vendre ses bibliothèques, il a intéret à bien écrire sa doc .... Après je t'accorde que payer n'est pas en soi une garantie d'avoir une documentation de qualité, mais souvent ça aide (tout dépend aussi à qui tu t'adresses, mais c'est un autre pb).
Et j'ai très bien compris ton commentaire, mais je ne suis pas d'accord. La réponse que tu as apporté ne le laissait pas paraitre ....
Mais tu compares des choses non comparables, les n° de version ne veulent pas dire la même chose en libre et en privateur
Dans le cas de Ruby ou de Rails, par exemple, les numéros de version se lisent :
x.y.z où x représente un très gros changement fondemental de l'API, y un apport de nouvelles fonctionalités majeurs ou des changements importants mais pas critiques, et x des changements mineurs ou des bugkills. Rien ne te garantis que la version 2.0.0 soit plus stable qu'une version 1.8.7 ou 0.1.23, je dirais même que la version 2.0.0 a beaucoup plus de chances d'être bugée, sa documentation incomplète ou à revoir par endroits. Dans ce cas, il vaut mieux rester une version en arrière de la pointe si tu veux de la stabilité et de la doc lisse.
Je suis d'accord avec toi sur le fait qu'une version non stable n'a pas à être documenté, je parle de version stable. Et lorsque j'ai installé Rails 2, c'était une version considérée comme stable ( ou j'ai mal compris quelque chose).
Dans ce cas, il vaut mieux rester une version en arrière de la pointe si tu veux de la stabilité et de la doc lisse.
C'est ce que j'ai fait .... et ça s'est plutot bien passé (je ne reviendrai plus au PHP).
Dans le cas d'un modèle privateur, puisque c'est un produit que l'on vend, on ne sort une nouvelle version qu'une fois que tout est lisse, arrondi, calé, ou du moins que les bugs sont cachés sous le tapis, et on lui met un gros numéro bien flamboyant pour dire "tadaaaaaa". Ici ça ne sert à rien d'être une version en dessous de la pointe, puisque la pointe n'est pas disponible avant d'être stabilisée.
Tu caricatures ..... Je ne suis pas spécialiste Microsoft, ou Borland, mais je me rappelle que lorsque je faisais du développement Windows, l'API était sufisamment bien documentée pour pouvoir s'en sortir dans la plupart des cas .... Toi tu me parles de développements fait à l'arrache par une sSII pour un projet spécifique, et la je te l'accorde les SSII ne sont pas toujours des modèles dans le genre.
En général les fichiers README sont là pour ça, et le commentaire aussi, en tout cas en Ruby (je n'ai pas fait beaucoup de C, VB, ou autres langages "chiants" en dehors du Java et du PHP...).
On en revient à ce que je disais plus haut : lire les commentaires parsemés dans le code, ca coute cer en temps à un développeur, bien plus qu'une aide en ligne à la "VBA" .... Apres entre le README qui indique comment installer, le README qui indique comment l'utiliser, etc .... c'est pas simple de s'uy retrouver.
Après il y a des gens qui ne lisent pas les readme ou les commentaires (en Ruby on génèrent les docs facilement à partir des commentaires, et comme contrairement à Java on ne fait pas plein de méthodes creuses qui appellent en fait une autre méthode qui fait vraiment le boulot, c'est moins fatiguant).
Je n'ai pas encore assez de recul sur Ruby et Rails pour répondre, mais ce n'est malhereusement le cas que d'une infime partie des projets libres. Pour beaucoup, la seule doc est le code ..... Et puis pour Ruby et rails en particulier il est difficile de s'y mettre sans un bon bouquin à côté ....
Enfin, si tu veux de la méthodologie XP avec tests validés avant commit tu peux difficilement accuser Rails de ne pas être à la pointe de cette pratique. Pour écrire les tests avant codage, je ne suis pas dans le secret de l'équipe Rails core, mais moi-même en toute honnêteté je ne le fais pas toujours, et il m'arrive de me demander si c'est vraiment si meilleur que de les faire peu de temps après avoir fait une fonctionnalité (mais avant de factoriser bien entendu).
Dans un contexte de travail collaboratif, c'est mieux : tu définis les interfaces avant de les implémenter :ceux qui se basent sur ton travail peuvent travailler sans avoir à t'attendre .... Et tu remarqueras que pour ma part je ne parlais pas de Rails mais que j'étais dans une optique plus globale.
Il n'y a pas que l'UML dans la vie...
Tu parlais d'XP, en XP on travaille beaucoup plus à partir de "stories", on fait des schémas beaucoup plus libres C'était un exemple ..... ne prends pas mes propos au pied de la lettre. Que ce soit UML ou autre chose, ce n'est pas le plus important. JE parle d'UML parce que ç'est un ensemble d'outils normalisés et qui restent assez clair et "universel". Cela dit si chacun utilise sa propre convension, comment veux-tu ensuite regrouper tout ça dans un ensemble cohérent (ce qui était l'objet du fil initial) ...
et peut tout à fait les inclure là où ils vont, c'est à dire dans une wiki de projet par exemple.
1/ D'abord combien de projets le font ? très peu. Et c'est ce que je déplore entre autres.
2/ Sinon, encore de la dispersion :
- Readme
- code source
- wiki projet
- les forums
- les FAQ
- un bouquin qui fait la glue avec ça ...
Et tout ca sans que les développeurs s'impliquent dans la doc (je ne leur demande pas de rédiger de la doc hein) ... En plus chaque projet ou langage utilise ses propres convensions ou format ..... Pour un développeur windows par exemple c'est plus simple : un IDE qui contient l'aide dont il a besoin ....
Si on pouvait arriver à ca je serais hereux .... mais j'y crois pas trop.
3/ Qu'est-ce qui empêche de rédiger de la doc en même temps que les tests ? Pas grand chose puisque les tests sont censé, comme leur nom l'indique, testerles cas d'utilisation. Prendre certains bouts de code développés pour le test comme exemple serait bien pratique ....
Juste un détail : ne prends pas mes commentaires comme si je crachais sur le LL et les développeurs : j'essaie d'être constructif et de mettre en avant les points qui me paraissent négatifs dans le LL, et je serai le premier hereux lorsque ces problèmes auront disparu.
En fait de cette discussion me viennent des idées, mais je ne pense pas que les développeurs s'y plieraient ... Ya qu'a voir les tentatives d'uniformisations telles que LSB ou autres pour se faire une idée ....
[^] # Re: Wiki-libra?
Posté par totof2000 . En réponse au journal Documentation collaborative. Évalué à 2.
Payer ne te donne pas de garantie que ce soit propre et clair, juste une personne à blâmer si ça ne l'est pas et l'impression d'avoir un levier. Tu peux avoir du propre et du clair aussi bien en libre qu'en non-libre et le crade et pas clair n'est pas l'apanage du libre non plus.
Là n'est pas la question : tu sépares la doc du code et cette approche est bien plus rapide que de tout mettre dans le code. Après si quelqu'un veut vendre ses bibliothèques, il a intéret à bien écrire sa doc .... Après je t'accorde que payer n'est pas en soi une garantie d'avoir une documentation de qualité, mais souvent ça aide (tout dépend aussi à qui tu t'adresses, mais c'est un autre pb).
Et j'ai très bien compris ton commentaire, mais je ne suis pas d'accord. La réponse que tu as apporté ne le laissait pas paraitre ....
Mais tu compares des choses non comparables, les n° de version ne veulent pas dire la même chose en libre et en privateur
Dans le cas de Ruby ou de Rails, par exemple, les numéros de version se lisent :
x.y.z où x représente un très gros changement fondemental de l'API, y un apport de nouvelles fonctionalités majeurs ou des changements importants mais pas critiques, et x des changements mineurs ou des bugkills. Rien ne te garantis que la version 2.0.0 soit plus stable qu'une version 1.8.7 ou 0.1.23, je dirais même que la version 2.0.0 a beaucoup plus de chances d'être bugée, sa documentation incomplète ou à revoir par endroits. Dans ce cas, il vaut mieux rester une version en arrière de la pointe si tu veux de la stabilité et de la doc lisse.
Je suis d'accord avec toi sur le fait qu'une version non stable n'a pas à être documenté, je parle de version stable. Et lorsque j'ai installé Rails 2, c'était une version considérée comme stable ( ou j'ai mal compris quelque chose).
Dans ce cas, il vaut mieux rester une version en arrière de la pointe si tu veux de la stabilité et de la doc lisse.
C'est ce que j'ai fait .... et ça s'est plutot bien passé (je ne reviendrai plus au PHP).
Dans le cas d'un modèle privateur, puisque c'est un produit que l'on vend, on ne sort une nouvelle version qu'une fois que tout est lisse, arrondi, calé, ou du moins que les bugs sont cachés sous le tapis, et on lui met un gros numéro bien flamboyant pour dire "tadaaaaaa". Ici ça ne sert à rien d'être une version en dessous de la pointe, puisque la pointe n'est pas disponible avant d'être stabilisée.
Tu caricatures ..... Je ne suis pas spécialiste Microsoft, ou Borland, mais je me rappelle que lorsque je faisais du développement Windows, l'API était sufisamment bien documentée pour pouvoir s'en sortir dans la plupart des cas .... Toi tu me parles de développements fait à l'arrache par une sSII pour un projet spécifique, et la je te l'accorde les SSII ne sont pas toujours des modèles dans le genre.
En général les fichiers README sont là pour ça, et le commentaire aussi, en tout cas en Ruby (je n'ai pas fait beaucoup de C, VB, ou autres langages "chiants" en dehors du Java et du PHP...).
On en revient à ce que je disais plus haut : lire les commentaires parsemés dans le code, ca coute cer en temps à un développeur, bien plus qu'une aide en ligne à la "VBA" .... Apres entre le README qui indique comment installer, le README qui indique comment l'utiliser, etc .... c'est pas simple de s'uy retrouver.
Après il y a des gens qui ne lisent pas les readme ou les commentaires (en Ruby on génèrent les docs facilement à partir des commentaires, et comme contrairement à Java on ne fait pas plein de méthodes creuses qui appellent en fait une autre méthode qui fait vraiment le boulot, c'est moins fatiguant).
Je n'ai pas encore assez de recul sur Ruby et Rails pour répondre, mais ce n'est malhereusement le cas que d'une infime partie des projets libres. Pour beaucoup, la seule doc est le code ..... Et puis pour Ruby et rails en particulier il est difficile de s'y mettre sans un bon bouquin à côté ....
Enfin, si tu veux de la méthodologie XP avec tests validés avant commit tu peux difficilement accuser Rails de ne pas être à la pointe de cette pratique. Pour écrire les tests avant codage, je ne suis pas dans le secret de l'équipe Rails core, mais moi-même en toute honnêteté je ne le fais pas toujours, et il m'arrive de me demander si c'est vraiment si meilleur que de les faire peu de temps après avoir fait une fonctionnalité (mais avant de factoriser bien entendu).
Dans un contexte de travail collaboratif, c'est mieux : tu définis les interfaces avant de les implémenter :ceux qui se basent sur ton travail peuvent travailler sans avoir à t'attendre .... Et tu remarqueras que pour ma part je ne parlais pas de Rails mais que j'étais dans une optique plus globale.
Il n'y a pas que l'UML dans la vie...
Tu parlais d'XP, en XP on travaille beaucoup plus à partir de "stories", on fait des schémas beaucoup plus libres C'était un exemple ..... ne prends pas mes propos au pied de la lettre. Que ce soit UML ou autre chose, ce n'est pas le plus important. JE parle d'UML parce que ç'est un ensemble d'outils normalisés et qui restent assez clair et "universel". Cela dit si chacun utilise sa propre convension, comment veux-tu ensuite regrouper tout ça dans un ensemble cohérent (ce qui était l'objet du fil initial) ...
et peut tout à fait les inclure là où ils vont, c'est à dire dans une wiki de projet par exemple.
1/ D'abord combien de projets le font ? très peu. Et c'est ce que je déplore entre autres.
2/ Sinon, encore de la dispersion :
- Readme
- code source
- wiki projet
- les forums
- les FAQ
- un bouquin qui fait la glue avec ça ...
Et tout ca sans que les développeurs s'impliquent dans la doc (je ne leur demande pas de rédiger de la doc hein) ... En plus chaque projet ou langage utilise ses propres convensions ou format ..... Pour un développeur windows par exemple c'est plus simple : un IDE qui contient l'aide dont il a besoin ....
Si on pouvait arriver à ca je serais hereux .... mais j'y crois pas trop.
3/ Qu'est-ce qui empêche de rédiger de la doc en même temps que les tests ? Pas grand chose puisque les tests sont censé, comme leur nom l'indique, testerles cas d'utilisation. Prendre certains bouts de code développés pour le test comme exemple serait bien pratique ....
Juste un détail : ne prends pas mes commentaires comme si je crachais sur le LL et les développeurs : j'essaie d'être constructif et de mettre en avant les points qui me paraissent négatifs dans le LL, et je serai le premier hereux lorsque ces problèmes auront disparu.
En fait de cette discussion me viennent des idées, mais je ne pense pas que les développeurs s'y plieraient ... Ya qu'a voir les tentatives d'uniformisations telles que LSB ou autres pour se faire une idée ....