> 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.
On ne doit pas parler de la même chose alors. A volume égal, la doc des méthodes et des objets eux-mêmes, plus tu la détache et plus c'est pénible de la garder à jour, alors que la mettre proprement dans les commentaires prévus à cet effet permet de générer sous différents formats de façon automatisée sans perdre du temps à synchroniser à la main.
Par contre, si à fonctionnalité égale je dois commenter une seule méthode (Ruby) ou 3 méthodes (Java quand il y a plusieurs façons de fournir les paramètres), c'est clair je préfère Ruby.
> 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).
Alors non on n'est pas d'accord. Je ne vois pas en quoi on ne devrait pas documenter une version non stable. Mais je crois que tu veux dire en fait "une version non stable n'a pas à sortir publiquement". Et là, vu que tu adopte un point de vue privateur, oui, c'est logique.
Dans un modèle de développement libre, on peut très bien rendre publiquement disponible même (surtout) les version non stables, en avertissant les visiteurs que la version non stable ne l'est pas encore. C'est comme ça que des utilisateurs peuvent soumettre des patchs pour stabiliser, indiquer les bugs qu'ils trouvent, et aider à évaluer la stabilité de l'ensemble. Aussi, à soumettre des patchs de commentaires pour améliorer la documentation.
Et que tu aies compris quand tu as installé Rails 2.0.0 que c'était une version stable... Comment te dire... Tu as mal compris quelque chose, oui.
>> 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.
Non, je ne caricature pas, je constate. De plus je ne juge pas. C'est normal d'essayer de faire mousser un produit que l'on veut vendre, et c'est normal qu'on lisse les bords et qu'on arrondisse les coins, voir qu'on mette de la poussière sous le tapis quand il y en a qu'on n'a pas le temps de vider, tout le monde le fait, ce n'est pas l'apanage des SSII et Windows ou Borland ne sont pas en reste. De toute façon ce n'est pas un crime et ça peut être réparé discrètement ensuite à coups de patchs.
Et surtout, ce n'est pas une décision volontaire d'un dirigeant ou des développeurs, c'est un sous-produit du modèle en cascade "on livre pour quand c'est demandé / quand le marché est réceptif" comme le fait de soumettre des versions non stable est un sous-produit du modèle itératif "on livre petit à petit jusqu'à ce que ça fonctionne bien et quand ça fonctionne bien on appelle ça stable jusqu'à la prochaine stable".
> 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.
Sinon tu as des outils pour prendre les commentaires et faire les jolies pages HTML lisibles / cherchables avec le code caché tant que tu ne veux pas le voir, avec Ruby ça s'appelle RDoc, avec Java JavaDoc, avec PHP, PHPDoc (c'est dingue, on dirait presque qu'ils se sont concertés). Ils peuvent par exemple prendre le README et en faire une jolie page de garde avec des titres et tout.
Avec ça, tu rajoutes un wiki sur ton site, où tu mets des schémas globaux, des explications sur les principes importants, des tutoriaux pour les tâches courantes, et n'importe qui peut s'y retrouver. Le point positif, c'est que c'est moins lourd et chiant à maintenir qu'une documentation complètement séparée du code, parce que quand on change la signature d'une méthode qui a un commentaire, on pense plus facilement à changer le commentaire et c'est moins pénible que de repasser sur toute la doc et tout le code pour voir les choses qui ont changé après coup.
> 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é ....
A mon avis oui, tu as assez peu de recul sur Ruby on Rails, probablement parce que tu as attaqué Rails sans avoir au préalable un peu creusé Ruby. C'est ce qui fait que oui, il faut généralement un bouquin pour attaquer parce que sinon c'est un trop grand pas à franchir.
C'est un peu comme vouloir apprendre le calcul intégral sans savoir faire d'additions, soustractions, multiplications, etc., c'est pas strictement impossible mais il va falloir beaucoup potasser et tu vas trouver ça beaucoup plus compliqué.
Ensuite, je pense que si je voulais attaquer le développement d'un jeu en 3D avec directX en C++, j'aurais quand même intérêt d'avoir des bases de C++ avant d'attaquer l'API directX par la face nord, API bien foutue ou pas.
Et puis franchement, commencer dans n'importe quelle API en plongeant direct dans l'API sans chercher des autres sources (tutos, blogs, forums de développeurs, etc.) c'est quand même un peu suicidaire non, à moins de déjà maîtriser à mort le sujet.
> 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 ....
En Java oui, puisque le Java est fortement typé, que d'écrire du code prends beaucoup de temps, qu'il y a beaucoup de répétitions inutiles (méthodes paravent, polymorphisme par clonage de signatures, répartition de responsabilités en multipliant le nombre de classes ...), ce qui oblige à faire des architectures de classes apriori pour faire en sorte que tout colle bien ensuite, ce qui plombe les projets parce que tout ne se passe jamais vraiment comme c'était prévu au départ (le client change d'avis, l'équipe avait mal compris / interprété, une contrainte technique force à considérer un cas imprévu...). C'est bureaucratique, lourd, et généralement ça tue l'esprit d'initiative chez les gens qui vont devoir développer derrière les architectes qui on fait les plans. Bof.
Maintenant, quand le langage n'est pas une carapace handicapante, comme en Ruby (typage dynamique "... alors pour moi c'est un canard", possibilité d'ajouter des comportements factorisés dans la définition de classe ou même à la volée grâce aux modules, etc.), on n'a pas besoin de tout penser avant de se mettre à coder, on peut commencer en itératif en définissant des lignes générales, prototyper jusqu'à obtenir un modèle convenable, casser le prototype et réaliser l'itération avec tests et factoriser ensuite. Et la collaboration se passe bien s'il y a communication, proximité, tests automatisés et confiance, ces 4 éléments sont nécessaires et c'est non-négociables par contre.
Il faut faire confiance apriori en sa capacité à trouver une solution pour chaque problèmes qui se présenteront en route, mais que l'on parte avec un plan rigide et sur-développé comme en Java ou une direction globale précise mais une ligne souple comme en Ruby, on arrive au même point au final et il y aura des embûches en cours de route de toute façon (le meilleur plan du monde n'est qu'un plan, la réalité a souvent tendance à le contredire).
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.
Plein de projets libres le font, au contraire, mais ils ne sont pas forcément toujours très connus / reconnus par les utilisateurs. Github par exemple propose de base un wiki pour chaque projet.
Au hasard dans ceux que j'utilise et que je lis beaucoup :
- Rails (beaucoup de tutos sont justement sur la Wiki)
- Shoes (toolkit graphique Ruby)
- Inkscape
- Ubuntu
> 2/ Sinon, encore de la dispersion :
> - Readme
> - code source
> - wiki projet
> - les forums
> - les FAQ
> - un bouquin qui fait la glue avec ça ...
Attends, tu mélanges tout là.
Le README ça va avec le code source, et ça peut être inclu dans la doc généré, généralement d'ailleurs ça fait la première page de doc générée automatiquement depuis les sources.
Un wiki projet c'est pour trouver les bases pour commencer, ça n'a rien à voir avec les sources et c'est normal, le but n'est pas d'aller au fond des choses mais de présenter une vue d'ensemble et des "portes d'entrées" dans les concepts principaux. C'est normal que ça ne soit pas intégré à la doc de l'API plus complète, moins didactique, plus directe, plus "sèche" (moins d'exemples pas à pas). Les FAQ ça s'intègre très bien aux wiki, c'est même limite la meilleur façon de les case.
Les forums officiels c'est là pour mettre en relation une question précise avec une réponse précise, quand une question - réponse revient souvent c'est une bonne idée de la faire remonter vers la wiki, ou dans la doc quand c'est un trou. C'est un autre média, ça n'a rien à voir, et rien n'empêche de le mettre sur un même nom de domaine que le site de l'API et du code par exemple.
Les forums officieux, les bouquins, c'est pas maîtrisable par les responsables du projet, chacun fait ce qu'il veut et encore heureux.
Bref, de tous ces différents médias, les "officiels" sont tous groupables sous un même nom de domaine commun, et les "officieux" font leur vie. En même temps c'est plutôt bien de disperser les médias officieux, ça diffuse l'information, ça donne des droits d'auteur à des auteurs de livres, quand ils sont bons, ça fait bloguer les blogueurs.
> 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.
Ok, je ne sais pas toi, mais moi la dernière fois que j'ai consulté la MSDN je m'y suis perdu et je n'ai pas trouvé la réponse après une soirée, j'ai laissé tomber. Comme quoi c'est aussi subjectif, et qu'un outil demande un temps de prise en main de toute façon et quel qu'il soit.
> 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 ....
Rien ne l'empêche, mais c'est pas forcément une bonne idée, tout comme celle qui voudrait que les tests sont fait au début et n'évoluent pas ensuite. On ne sait pas de quoi demain sera fait, il vaut mieux écrire les tests et les commentaires peu de temps avant le code, et les faire évoluer quand le code évolue pour mieux convenir aux besoins.
Considérer la programmation d'une façon verticale (on descend d'une vérité mathématique absolue jusqu'à lui donner corps) me semble être une erreur. Je préfère l'approche "biologique", on prend un problème, on le résout, on consolide, on livre, on prend de l'expérience, on réitère. C'est plus "darwinien" (le meilleurs finit pas survivre et transmet ses caractéristiques aux suivants), et moins "immanent" (la perfection existe au-delà de notre royaume, mais on doit s'en approcher quel que soit le prix).
> 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.
Je ne le prend pas comme une insulte, mais plutôt comme un point de vue biaisé concernant le mode de fonctionnement de projets libres. C'est pourquoi je défend mon point de vue jusqu'à changement de celui-ci et / ou fin de la discussion.
Je ne suis pas un zélote d'un fonctionnement ou l'autre (même si je préfère moi me trouver dans un mode de fonctionnement itératif, c'est un choix personnel, que je défend mais que je n'impose pas), chacun peut mieux convenir selon la situation. Par contre, appliquer un modèle ou l'autre a des conséquences sur le format de la documentation officielle et de l'information en général, et attaquer l'api d'un projet libre avec les apriori d'un projet privateur n'a pas de sens, et ne peut que te mener à l'échec et à la frustration, l'inverse est vrai aussi.
> 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 ....
Justement, pourquoi faire uniforme ? Est-ce que le monde sera plus beau et plus vivable quand on vivra dans des petites cases de béton de taille réglementaire, avec le choix de la couleur intérieure parmis les couleurs réglementaires, avec les meubles et la décoration à choisir dans les meubles et les décorations standards ?...
Le libre c'est la liberté d'expérimenter comme on le sent, c'est valable aussi pour la documentation. C'est un modèle vivant, presque organique, qui peut donner des bases stables (après tout, l'évolution naturelle a bien donné à l'essentiel des espèces vivantes une même base standard, l'ADN, il n'y a pas de raison que la liberté de création en informatique ne puisse pas reposer sur des standards quand ils sont plus adaptés) mais pas indépassables le jour où on trouve une meilleur idée. Vouloir mettre tout dans des cases bien propres c'est le mirage un peu schizo d'un Descartes qui pensait les animaux comme des machines biologiques déterminées en même temps que "Je pense donc je suis". La vie ne rentre pas dans des petites cases, ou alors avec un truc coupant bien aiguisé...
[^] # Re: Wiki-libra?
Posté par Bastes . En réponse au journal Documentation collaborative. Évalué à 3.
On ne doit pas parler de la même chose alors. A volume égal, la doc des méthodes et des objets eux-mêmes, plus tu la détache et plus c'est pénible de la garder à jour, alors que la mettre proprement dans les commentaires prévus à cet effet permet de générer sous différents formats de façon automatisée sans perdre du temps à synchroniser à la main.
Par contre, si à fonctionnalité égale je dois commenter une seule méthode (Ruby) ou 3 méthodes (Java quand il y a plusieurs façons de fournir les paramètres), c'est clair je préfère Ruby.
> 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).
Alors non on n'est pas d'accord. Je ne vois pas en quoi on ne devrait pas documenter une version non stable. Mais je crois que tu veux dire en fait "une version non stable n'a pas à sortir publiquement". Et là, vu que tu adopte un point de vue privateur, oui, c'est logique.
Dans un modèle de développement libre, on peut très bien rendre publiquement disponible même (surtout) les version non stables, en avertissant les visiteurs que la version non stable ne l'est pas encore. C'est comme ça que des utilisateurs peuvent soumettre des patchs pour stabiliser, indiquer les bugs qu'ils trouvent, et aider à évaluer la stabilité de l'ensemble. Aussi, à soumettre des patchs de commentaires pour améliorer la documentation.
Et que tu aies compris quand tu as installé Rails 2.0.0 que c'était une version stable... Comment te dire... Tu as mal compris quelque chose, oui.
>> 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.
Non, je ne caricature pas, je constate. De plus je ne juge pas. C'est normal d'essayer de faire mousser un produit que l'on veut vendre, et c'est normal qu'on lisse les bords et qu'on arrondisse les coins, voir qu'on mette de la poussière sous le tapis quand il y en a qu'on n'a pas le temps de vider, tout le monde le fait, ce n'est pas l'apanage des SSII et Windows ou Borland ne sont pas en reste. De toute façon ce n'est pas un crime et ça peut être réparé discrètement ensuite à coups de patchs.
Et surtout, ce n'est pas une décision volontaire d'un dirigeant ou des développeurs, c'est un sous-produit du modèle en cascade "on livre pour quand c'est demandé / quand le marché est réceptif" comme le fait de soumettre des versions non stable est un sous-produit du modèle itératif "on livre petit à petit jusqu'à ce que ça fonctionne bien et quand ça fonctionne bien on appelle ça stable jusqu'à la prochaine stable".
> 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.
Sinon tu as des outils pour prendre les commentaires et faire les jolies pages HTML lisibles / cherchables avec le code caché tant que tu ne veux pas le voir, avec Ruby ça s'appelle RDoc, avec Java JavaDoc, avec PHP, PHPDoc (c'est dingue, on dirait presque qu'ils se sont concertés). Ils peuvent par exemple prendre le README et en faire une jolie page de garde avec des titres et tout.
Avec ça, tu rajoutes un wiki sur ton site, où tu mets des schémas globaux, des explications sur les principes importants, des tutoriaux pour les tâches courantes, et n'importe qui peut s'y retrouver. Le point positif, c'est que c'est moins lourd et chiant à maintenir qu'une documentation complètement séparée du code, parce que quand on change la signature d'une méthode qui a un commentaire, on pense plus facilement à changer le commentaire et c'est moins pénible que de repasser sur toute la doc et tout le code pour voir les choses qui ont changé après coup.
> 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é ....
A mon avis oui, tu as assez peu de recul sur Ruby on Rails, probablement parce que tu as attaqué Rails sans avoir au préalable un peu creusé Ruby. C'est ce qui fait que oui, il faut généralement un bouquin pour attaquer parce que sinon c'est un trop grand pas à franchir.
C'est un peu comme vouloir apprendre le calcul intégral sans savoir faire d'additions, soustractions, multiplications, etc., c'est pas strictement impossible mais il va falloir beaucoup potasser et tu vas trouver ça beaucoup plus compliqué.
Ensuite, je pense que si je voulais attaquer le développement d'un jeu en 3D avec directX en C++, j'aurais quand même intérêt d'avoir des bases de C++ avant d'attaquer l'API directX par la face nord, API bien foutue ou pas.
Et puis franchement, commencer dans n'importe quelle API en plongeant direct dans l'API sans chercher des autres sources (tutos, blogs, forums de développeurs, etc.) c'est quand même un peu suicidaire non, à moins de déjà maîtriser à mort le sujet.
> 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 ....
En Java oui, puisque le Java est fortement typé, que d'écrire du code prends beaucoup de temps, qu'il y a beaucoup de répétitions inutiles (méthodes paravent, polymorphisme par clonage de signatures, répartition de responsabilités en multipliant le nombre de classes ...), ce qui oblige à faire des architectures de classes apriori pour faire en sorte que tout colle bien ensuite, ce qui plombe les projets parce que tout ne se passe jamais vraiment comme c'était prévu au départ (le client change d'avis, l'équipe avait mal compris / interprété, une contrainte technique force à considérer un cas imprévu...). C'est bureaucratique, lourd, et généralement ça tue l'esprit d'initiative chez les gens qui vont devoir développer derrière les architectes qui on fait les plans. Bof.
Maintenant, quand le langage n'est pas une carapace handicapante, comme en Ruby (typage dynamique "... alors pour moi c'est un canard", possibilité d'ajouter des comportements factorisés dans la définition de classe ou même à la volée grâce aux modules, etc.), on n'a pas besoin de tout penser avant de se mettre à coder, on peut commencer en itératif en définissant des lignes générales, prototyper jusqu'à obtenir un modèle convenable, casser le prototype et réaliser l'itération avec tests et factoriser ensuite. Et la collaboration se passe bien s'il y a communication, proximité, tests automatisés et confiance, ces 4 éléments sont nécessaires et c'est non-négociables par contre.
Il faut faire confiance apriori en sa capacité à trouver une solution pour chaque problèmes qui se présenteront en route, mais que l'on parte avec un plan rigide et sur-développé comme en Java ou une direction globale précise mais une ligne souple comme en Ruby, on arrive au même point au final et il y aura des embûches en cours de route de toute façon (le meilleur plan du monde n'est qu'un plan, la réalité a souvent tendance à le contredire).
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.
Plein de projets libres le font, au contraire, mais ils ne sont pas forcément toujours très connus / reconnus par les utilisateurs. Github par exemple propose de base un wiki pour chaque projet.
Au hasard dans ceux que j'utilise et que je lis beaucoup :
- Rails (beaucoup de tutos sont justement sur la Wiki)
- Shoes (toolkit graphique Ruby)
- Inkscape
- Ubuntu
> 2/ Sinon, encore de la dispersion :
> - Readme
> - code source
> - wiki projet
> - les forums
> - les FAQ
> - un bouquin qui fait la glue avec ça ...
Attends, tu mélanges tout là.
Le README ça va avec le code source, et ça peut être inclu dans la doc généré, généralement d'ailleurs ça fait la première page de doc générée automatiquement depuis les sources.
Un wiki projet c'est pour trouver les bases pour commencer, ça n'a rien à voir avec les sources et c'est normal, le but n'est pas d'aller au fond des choses mais de présenter une vue d'ensemble et des "portes d'entrées" dans les concepts principaux. C'est normal que ça ne soit pas intégré à la doc de l'API plus complète, moins didactique, plus directe, plus "sèche" (moins d'exemples pas à pas). Les FAQ ça s'intègre très bien aux wiki, c'est même limite la meilleur façon de les case.
Les forums officiels c'est là pour mettre en relation une question précise avec une réponse précise, quand une question - réponse revient souvent c'est une bonne idée de la faire remonter vers la wiki, ou dans la doc quand c'est un trou. C'est un autre média, ça n'a rien à voir, et rien n'empêche de le mettre sur un même nom de domaine que le site de l'API et du code par exemple.
Les forums officieux, les bouquins, c'est pas maîtrisable par les responsables du projet, chacun fait ce qu'il veut et encore heureux.
Bref, de tous ces différents médias, les "officiels" sont tous groupables sous un même nom de domaine commun, et les "officieux" font leur vie. En même temps c'est plutôt bien de disperser les médias officieux, ça diffuse l'information, ça donne des droits d'auteur à des auteurs de livres, quand ils sont bons, ça fait bloguer les blogueurs.
> 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.
Ok, je ne sais pas toi, mais moi la dernière fois que j'ai consulté la MSDN je m'y suis perdu et je n'ai pas trouvé la réponse après une soirée, j'ai laissé tomber. Comme quoi c'est aussi subjectif, et qu'un outil demande un temps de prise en main de toute façon et quel qu'il soit.
> 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 ....
Rien ne l'empêche, mais c'est pas forcément une bonne idée, tout comme celle qui voudrait que les tests sont fait au début et n'évoluent pas ensuite. On ne sait pas de quoi demain sera fait, il vaut mieux écrire les tests et les commentaires peu de temps avant le code, et les faire évoluer quand le code évolue pour mieux convenir aux besoins.
Considérer la programmation d'une façon verticale (on descend d'une vérité mathématique absolue jusqu'à lui donner corps) me semble être une erreur. Je préfère l'approche "biologique", on prend un problème, on le résout, on consolide, on livre, on prend de l'expérience, on réitère. C'est plus "darwinien" (le meilleurs finit pas survivre et transmet ses caractéristiques aux suivants), et moins "immanent" (la perfection existe au-delà de notre royaume, mais on doit s'en approcher quel que soit le prix).
> 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.
Je ne le prend pas comme une insulte, mais plutôt comme un point de vue biaisé concernant le mode de fonctionnement de projets libres. C'est pourquoi je défend mon point de vue jusqu'à changement de celui-ci et / ou fin de la discussion.
Je ne suis pas un zélote d'un fonctionnement ou l'autre (même si je préfère moi me trouver dans un mode de fonctionnement itératif, c'est un choix personnel, que je défend mais que je n'impose pas), chacun peut mieux convenir selon la situation. Par contre, appliquer un modèle ou l'autre a des conséquences sur le format de la documentation officielle et de l'information en général, et attaquer l'api d'un projet libre avec les apriori d'un projet privateur n'a pas de sens, et ne peut que te mener à l'échec et à la frustration, l'inverse est vrai aussi.
> 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 ....
Justement, pourquoi faire uniforme ? Est-ce que le monde sera plus beau et plus vivable quand on vivra dans des petites cases de béton de taille réglementaire, avec le choix de la couleur intérieure parmis les couleurs réglementaires, avec les meubles et la décoration à choisir dans les meubles et les décorations standards ?...
Le libre c'est la liberté d'expérimenter comme on le sent, c'est valable aussi pour la documentation. C'est un modèle vivant, presque organique, qui peut donner des bases stables (après tout, l'évolution naturelle a bien donné à l'essentiel des espèces vivantes une même base standard, l'ADN, il n'y a pas de raison que la liberté de création en informatique ne puisse pas reposer sur des standards quand ils sont plus adaptés) mais pas indépassables le jour où on trouve une meilleur idée. Vouloir mettre tout dans des cases bien propres c'est le mirage un peu schizo d'un Descartes qui pensait les animaux comme des machines biologiques déterminées en même temps que "Je pense donc je suis". La vie ne rentre pas dans des petites cases, ou alors avec un truc coupant bien aiguisé...