Oui, enfin, en même temps, prendre les entreprises en exemple, c'est plutôt utopique aussi. Ce que j'ai beaucoup vu en SSII c'est :
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 ....
Je prends un exemple (que j'aime vraiment pratiquer) : Ruby. La clarté du langage aide à commenter peu en conservant une bonne lisibilité (du moment qu'on évite de coder à la perl ou à la C). Dans ce cas, cependant, l'ouverture et la lecture du code rebutant toujours le débutant, il est positif de temps en temps de faire une explication pour débutants sur un site du projet, mais overkill et épuisant de faire une documentation exhaustive de tous les cas possibles.
On est pas obliger d'expliciter tous les cas possible. Cependant ce qui pour moi constitue un bon exemple de documentation bien faite (mais pas parfaite) c'est par exemple la documentation de VBA dans Excel.
Tu as une aide et une explication sur les fonctions, les paramètres qu'elles prennent ainsi qu'un exemple d'utilisation. Tu n'as pas un exemple sur tous les cas d'utilisation, mais suffisamment pour comprendre comment ça marche.
Non, la raison principale pour laquelle le LL a mauvaise presse devant une entreprise, c'est surtout parce que :
- on ne le paye pas (en licences) et que tout ce qui n'est pas cher est suspect de ne pas fonctionner
- c'est un royaume de bidouilleurs et tout ce qui se bidouille c'est pas fiable
- on n'a personne à attaquer en justice ou sur lequel faire pression quand on n'est pas content sinon soi-même
C'est vrai mais ce n'est pas la seule raison : voir plus haut.
Je vais prendre un autre exemple Ruby : Rails. La doc de base est extrêmement bien faite
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.
Bien sûr, tôt ou tard les développeurs doivent être dans la boucle, mais il ne faut pas leur demander d'assurer tout le travail de documentation quel que soit le projet, sinon le développeur, il s'étiolle.
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 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) ...
[^] # Re: Wiki-libra?
Posté par totof2000 . En réponse au journal Documentation collaborative. Évalué à 2.
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 ....
Je prends un exemple (que j'aime vraiment pratiquer) : Ruby. La clarté du langage aide à commenter peu en conservant une bonne lisibilité (du moment qu'on évite de coder à la perl ou à la C). Dans ce cas, cependant, l'ouverture et la lecture du code rebutant toujours le débutant, il est positif de temps en temps de faire une explication pour débutants sur un site du projet, mais overkill et épuisant de faire une documentation exhaustive de tous les cas possibles.
On est pas obliger d'expliciter tous les cas possible. Cependant ce qui pour moi constitue un bon exemple de documentation bien faite (mais pas parfaite) c'est par exemple la documentation de VBA dans Excel.
Tu as une aide et une explication sur les fonctions, les paramètres qu'elles prennent ainsi qu'un exemple d'utilisation. Tu n'as pas un exemple sur tous les cas d'utilisation, mais suffisamment pour comprendre comment ça marche.
Non, la raison principale pour laquelle le LL a mauvaise presse devant une entreprise, c'est surtout parce que :
- on ne le paye pas (en licences) et que tout ce qui n'est pas cher est suspect de ne pas fonctionner
- c'est un royaume de bidouilleurs et tout ce qui se bidouille c'est pas fiable
- on n'a personne à attaquer en justice ou sur lequel faire pression quand on n'est pas content sinon soi-même
C'est vrai mais ce n'est pas la seule raison : voir plus haut.
Je vais prendre un autre exemple Ruby : Rails. La doc de base est extrêmement bien faite
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.
Bien sûr, tôt ou tard les développeurs doivent être dans la boucle, mais il ne faut pas leur demander d'assurer tout le travail de documentation quel que soit le projet, sinon le développeur, il s'étiolle.
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 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) ...