> Je pense que tu n'as pas compris mon commentaire :
> On préfère acheter une bibliothèque payante, fermée mais bien documentée (pour l'utilisation) qu'une bibliothèque libre, code ouvert et peu documentée, parce qu'un développeur qui doit passer des jours à ausculter le code pour comprendre comment ça marche, ça coute cher ....
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.
Et j'ai très bien compris ton commentaire, mais je ne suis pas d'accord.
> Non.
> Ruby on Rails est l'exemple typique de ce que je déplore : on sort une version (notamment la 2.0), et on ne sort pas de doc associée. Quelqu'un qui connait un peu ruby ou rails s'en sort mais je t'assure que quelqu'un qui a voulu se mettre à Ruby lorsque Ruby 2.0 est sorti aurait pu être totalement dégouté de ce langage. D'ailleurs, quand j'allais en cours, il y a plus de 10 ans, on m'a toujours encouragé à écrire un minimum de documentation _avant_ d'écrire mon code, d'écrire par exemple, pour une fonction, les paramètres qu'elle prend, le type et l'utilité de ces paramètres, ainsi que le code retour. On encourage également, dans certaines méthodes de développement, de décrire clairement les classes que l'on crée (notamment à l'aide d'UML), et ce _avant_ de commencer à coder. On encourage aussi à écrire les procédures de test unitaure _avant_ de coder les classes/fonctions (Methodes XP par exemple), et ce n'est pas pour rien.
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.
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.
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).
> Ce n'est pas non plus ce que je leur demande .... mais on peut leur en demander un minimum .... Et pour moi le minimum c'est d'expliquer comment utiliser le code qu'ils ont produit et ce que fait ce code.
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...). 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).
> En fait j'aimerais avoir pour certains projets libre, non seulement le code mais surtout les représentations (UML) de l'ensemble du projet. Mais la on s'éloigne du sujet initial (les bibliothèques) ...
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 et peut tout à fait les inclure là où ils vont, c'est à dire dans une wiki de projet par exemple.
[^] # Re: Wiki-libra?
Posté par Bastes . En réponse au journal Documentation collaborative. Évalué à 2.
> On préfère acheter une bibliothèque payante, fermée mais bien documentée (pour l'utilisation) qu'une bibliothèque libre, code ouvert et peu documentée, parce qu'un développeur qui doit passer des jours à ausculter le code pour comprendre comment ça marche, ça coute cher ....
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.
Et j'ai très bien compris ton commentaire, mais je ne suis pas d'accord.
> Non.
> Ruby on Rails est l'exemple typique de ce que je déplore : on sort une version (notamment la 2.0), et on ne sort pas de doc associée. Quelqu'un qui connait un peu ruby ou rails s'en sort mais je t'assure que quelqu'un qui a voulu se mettre à Ruby lorsque Ruby 2.0 est sorti aurait pu être totalement dégouté de ce langage. D'ailleurs, quand j'allais en cours, il y a plus de 10 ans, on m'a toujours encouragé à écrire un minimum de documentation _avant_ d'écrire mon code, d'écrire par exemple, pour une fonction, les paramètres qu'elle prend, le type et l'utilité de ces paramètres, ainsi que le code retour. On encourage également, dans certaines méthodes de développement, de décrire clairement les classes que l'on crée (notamment à l'aide d'UML), et ce _avant_ de commencer à coder. On encourage aussi à écrire les procédures de test unitaure _avant_ de coder les classes/fonctions (Methodes XP par exemple), et ce n'est pas pour rien.
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.
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.
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).
> Ce n'est pas non plus ce que je leur demande .... mais on peut leur en demander un minimum .... Et pour moi le minimum c'est d'expliquer comment utiliser le code qu'ils ont produit et ce que fait ce code.
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...). 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).
> En fait j'aimerais avoir pour certains projets libre, non seulement le code mais surtout les représentations (UML) de l'ensemble du projet. Mais la on s'éloigne du sujet initial (les bibliothèques) ...
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 et peut tout à fait les inclure là où ils vont, c'est à dire dans une wiki de projet par exemple.