Discussion :

[berceker united]

Bonjour
Actuellement je suis sur un projet qui sera gratuit et les sources seront visible. Dans ma stratégie je souhaite donner un maximum d'information concernant l'application c'est à dire. Toute la doc objet via phpdocumentor. Model de données, explication précis sur certain élément, FAQ complete. Bref je veux limite que le developpeur se sente à l'aise. Néanmoins, je me pose la question que beaucoup d'application gratuite et ouvert ne sont pas très bavard coté doc. Mise à part comment faire ceci cela mais lorsqu'il y a des modif à fair il faut retrousser ses manches et fourrer son nez pour comprendre et dans mon idée de départ je souhaitais éviter cette étape et que je puisse l'expliquer avant toute chose. Y a t'il une raison à ce que certain soit peut bavard sur ça ? L'envie qu'il y en ait que ne puisse pas trop pomper le code ? ou autre?
Mon idée de départ c'est que je ne veux pas que le mec galère pour comprendre la logique. Malgré que je fasse les choses proprement et dans une certaine logique.

[maximenet]

utilise tu le modele MVC ? un framework déjà existant ?
Où te sert tu de ta propre logique ? auquel cas il sera déjà peut etre plus difficile d'y fourré son nez

[berceker united]

utilise tu le modele MVC ? un framework déjà existant ?
Où te sert tu de ta propre logique ? auquel cas il sera déjà peut etre plus difficile d'y fourré son nez

Je n'utilise pas de framework existante et c'est sur ma propre logique dont je pense qu'il il faut avoir un certain niveau en objet pour comprendre la logique de l'application.

[maximenet]

euhhh ... bé justement, faire de l'objet ne veux pas forcément dire architecture de code propre et logique.

M'enfin je suis sur que tu sera nous faire quelque chose de bien présenté, maintenant perso je ne serai te dire pourquoi certains ont du mal avec l'aidre qu'ils apportent à leur logiciel open source, peut etre parce que çà demande du temps aussi

[wamania]

Salut

Les prog comme phpDocumentator, javadoc ou doxygen ont été ecrit pour palier le manque de document des développeurs, mais je crois que c'est plus un moyen de s'affranchir de quelque chose de pompeux.
Au final, je dirais qu'une doc style javadoc est utile à 20% de la compréhension d'un script.

Si on a inventé de la paperasse lourde (spécification fonctionnelle, opérationnelle, cahier des charges, manuel développeur, manuel utilisateur, rapport de tests....), c'est qu'il y a une demande pour cette doc.

Bref, mes docs à moi sont presque toujours quelques pages synthétisant ce que je veux faire, ce que j'utilise, comment j'ai découpé mes blocs fonctionnels....plutôt qu'un paquet de fonction et de classe.

Cependant, certains groupes, dont PEAR utilise la génération de doc automatique et ont des docs très riche, mais leur fichier PHP contient en gros 2/3 de commentaires, ce que je trouve soulant personnellement.

[berceker united]

euhhh ... bé justement, faire de l'objet ne veux pas forcément dire architecture de code propre et logique.

M'enfin je suis sur que tu sera nous faire quelque chose de bien présenté, maintenant perso je ne serai te dire pourquoi certains ont du mal avec l'aidre qu'ils apportent à leur logiciel open source, peut etre parce que çà demande du temps aussi

Je suis bien daccord avec le premier point car j'ai déjà subit ceux qui pensait avec cette logique et je devais travailler avec leur merde et c'est justement pour avoir subit ça que je ne souhaite faire la même chose au autre. J'en avait marre de chercher comment il fonctionnaient aussi bien dans OSCommerce, Spip, PhpBb. Je souhaite pas faire du code "Pure énergie" mais qu'ils comprennent dans quel logique que ça été fait donc en donnant un maximum d'information. Une doc complete. Je me force à tous commenter avec les balises phpdoc. Schéma, Dessin, Dossier, etc...

[berceker united]

Salut

Les prog comme phpDocumentator, javadoc ou doxygen ont été ecrit pour palier le manque de document des développeurs, mais je crois que c'est plus un moyen de s'affranchir de quelque chose de pompeux.
Au final, je dirais qu'une doc style javadoc est utile à 20% de la compréhension d'un script.

Si on a inventé de la paperasse lourde (spécification fonctionnelle, opérationnelle, cahier des charges, manuel développeur, manuel utilisateur, rapport de tests....), c'est qu'il y a une demande pour cette doc.

Bref, mes docs à moi sont presque toujours quelques pages synthétisant ce que je veux faire, ce que j'utilise, comment j'ai découpé mes blocs fonctionnels....plutôt qu'un paquet de fonction et de classe.

Cependant, certains groupes, dont PEAR utilise la génération de doc automatique et ont des docs très riche, mais leur fichier PHP contient en gros 2/3 de commentaires, ce que je trouve soulant personnellement.

C'est le dernier point que je veux éviter. Bien souvent le commentaire est compréhensible pour celui qui l'a développé.

[maximenet]

et tu en ai où dans l'avancement de ton projet ? %tage ?

héhé veux le voir ce fameux CMS e-commerce révolutionnaire

[berceker united]

et tu en ai où dans l'avancement de ton projet ? %tage ?

héhé veux le voir ce fameux CMS e-commerce [B]révolutionnaire /B]

Tu veux me mettre la pression là . Je suis sur la gestion de l'information et les risques de colisions. Je develope lentement parce que je documente en même temps et je suis que sur la phase de la gestion des produits en sachant qu'il y en 5 au total. Produit, Log, Commande, Utilisateurs, CMS.

[wamania]

C'est le dernier point que je veux éviter. Bien souvent le commentaire est compréhensible pour celui qui l'a développé.

D'ou l'intéret de présenter une vue d'ensemble la plus large possible. J'ai fait un stage hautement technique à la fin de mes études, et bah quand j'ai présenté mon travail à l'équipe, me suis fait lyncher. Zont rien compris, et pourtant, c'est leur domaine.
Du coup, ils m'ont forcé à écrire des docs et à les faire valider par des non connaisseurs (ma mère comprise ).

Et franchement, faire des docs sur des analyseurs de données de simulateurs militaires compréhensible pour sa mère, c'est de l'entraînement...militaire

[berceker united]

Exacte
En faite, Il y a trois types de doc. Utilisation de l'application, utilisation technique pour développeur et documentation des classes & cie. J'avais dans l'idées de l'éditer comme un livre.

[ozzmax]

D'ou l'intéret de présenter une vue d'ensemble la plus large possible. J'ai fait un stage hautement technique à la fin de mes études, et bah quand j'ai présenté mon travail à l'équipe, me suis fait lyncher. Zont rien compris, et pourtant, c'est leur domaine.
Du coup, ils m'ont forcé à écrire des docs et à les faire valider par des non connaisseurs (ma mère comprise ).

Et franchement, faire des docs sur des analyseurs de données de simulateurs militaires compréhensible pour sa mère, c'est de l'entraînement...militaire

Mais du coup, si l'utilisté de la doc de berceker united est pour l'open source donc un utilisateur qui souhaite réutiliser le code ou encore modifier des module ou en rajouter...est ce que la doc est pour cet utilisateur...?

Je ne crois pas que c'est un manuel d'emploi comme la doc que tu as du faire...et pour avec sa mere comme validation, de mon coté ce serait assez pénible

Enfin, comme résumé la doc, j'en crois 2 type..la doc d'implentation..un peu comme un fichier d'aide où il faut utiliser le langage du commun des mortel au lieu du langage technique Et il y a la doc de programmeur ou tu peux épargner un peu la d'explication, car si un développeur utilise ton api en but de réutilisation de code, il doit connaitre la prog ainsi pouvoir imager la logique utiliser derriere l'application

Mais comme berceker united...le 3e type serait la description des classe et ses méthodes... Je la regroupais dans le 2e type...car monsieur et madame tout le monde n'utilisent pas ce genre de doc...ben du moins pas ma mere...

[berceker united]

disons que le but premier c'est que s'il souhaite modifier le contenu ou appporter des contribution qu'ils puisse y avoir les moyen et non pas dans le but de récuperer u code. Je suis pas l'abbé Pierre du dev.

[ePoX]

...Y a t'il une raison à ce que certain soit peut bavard sur ça ? L'envie qu'il y en ait que ne puisse pas trop pomper le code ? ou autre?....

Aucune idée.

..... Je suis pas l'abbé Pierre du dev.

Pourtant j'ai cru... Si tu veux faire de l'open source tu devras bien te faire à l'idée que tu auras des gens qui vont te pomper, faire du fric sur ton appli, et d'autres qui au contraire auront ta démarche et en feront profiter le projet.

Faut pas trop réver à ce niveau la d'après moi.

[berceker united]

Aucune idée.


Pourtant j'ai cru... Si tu veux faire de l'open source tu devras bien te faire à l'idée que tu auras des gens qui vont te pomper, faire du fric sur ton appli, et d'autres qui au contraire auront ta démarche et en feront profiter le projet.

Faut pas trop réver à ce niveau la d'après moi.

En faite, je voulais dire par là que le code est ouvert mais je n'expliquerais pas comment j'ai fais telle ou telle chose en précision. J'expliquerais seulement comment arriver à ce resultat. J'ai prévus aussi de livrer seulement la source non commenté dans les fichiers.

[ePoX]

....J'expliquerais seulement comment arriver à ce resultat. J'ai prévus aussi de livrer seulement la source non commenté dans les fichiers.

Moi ce que je ne comprend pas la, c'est que la valeur de ton appli elle se situe dans les possibilités qu'à l'utilisateur final, ou le développeur final.
Pas dans les lignes de codes qui servent à produire ce résultat.

Et je ne pense pas que tu ais révolutionné les méthodes de développement à un point que tu ais besoin de *protéger* les basements de l'appli en ne les commentant pas. Je dirais même au contraire, fais en profiter la communauté pour que celle ci en sorte grandissante, et ton appli aussi. Plus simple elle sera à appréhender, plus tu augmenteras tes chances de rassembler autour de ton projet une communauté dédié.
Et cette communauté bien driver saura faire évoluer ton appli dans la meilleure des voie.

non ?

[berceker united]

Je crois que je me suis un peut mal expliqué. Je veux pas faire le radin je voulais dire que les commentaires ne seront pas là pour expliquer chaque bout de code que je fais. Comme c'est entierement objet le commentaire seront transposé via phpdoc. Avant d'expliqué le code je préfère expliquer comment le tous s'articule après le code en lui même n'a rien de révolutionnaire. Quand je disais que je ne suis pas l'abbé pierre du dev c'est dans le sens ou je ne vais pas expliquer comment je fais pour le lire le contenu d'un répertoire.

[ePoX]

Ah oué... mais la sa relève du bon sens et des capacités de lecture du développeur mdr

[berceker united]

Disons que mon but avoué c'est de le forcer à lire la doc avant qu'il foure son nez dans le code.