Procédure usuelle de développement
Ceci est la procédure de développement actuelle:
Discussions
Discussion provenant du
WikiNiChangeLog050:
LordFarquaad, les améliorations sont habituellement discutées préalablement à leur mise en oeuvre (sauf lorsqu'il s'agit de correction de bogues) ; cela dit tes contributions sont de qualité mais un certain nombre me posent question comme : tes pratiques d'indentation de code (il faudrait tous qu'on s'entende une bonne fois pour toutes) ; ton utilisation des guillemets simples mélangés à des guillemets doubles (ne vaut-il pas mieux tout le temps des doubles) ; l'histoire du tracking mérite au moins un mot d'explication (je n'ai pas bien compris) ; cela dit, je préfère qu'on avance comme ça plutôt que rien ne se passe ;)
--
CharlesNepote
- Je m'attendais un peu à ce genre de remarque, mais j'ai préféré faire les modifications directement plutôt que de signaler des bugs et ensuite les corriger directement, mais je peux toujours le faire... [Il faudrait au strict minimum renseigner le log de chaque commit dans le CVS. -- ProgFou - Oui, je sais, je m'en suis rendu compte aussi après coup et DavidDelon m'a d'ailleurs envoyé un mail pour le signaler. D'après lui il y a une commande pour changer cela, mais je dois dire que cela me dépasse un peu... -- LordFarquaad ] Il n'y a pas de grosses modifications au niveau du fonctionnement, mis à part, peut-être, au niveau du rendu interne de la page, lors de l'édition (au niveau du linktracking)... Je me suis dit que, si ça n'allait pas, on aurait qu'à repartir d'une version antérieure, ou modifier les choses qui ne vont pas... Je vais tout de même expliquer mes corrections d'hier dans l'ArchiveRapportsDeBogues, mais pour ce qui est des modifications sur le handler edit, je sais pas du tout où en parler... (aaah, s'il y avait une page pour chaque fichier...) -- LordFarquaad
- Finalement j'ai créé une page au sujet des actions, du linktracking et des modifications que j'ai faites dans le handler edit, voir DevActionsEntetePiedDePageEtLinkTracking. Cela concerne aussi les deux autres fichiers modifiés en fait, les bugs n'étaient pas vraiment en eux-mêmes... Les corrections restent, je pense, tout de même valables; mais il va falloir discuter sérieusement du linktracking... -- LordFarquaad
- Je ne suis pas franchement du même avis [NdA?: celui de CharlesNepote]. L'une des choses qui fait que WikiNi a bonne réputation est justement son développement réfléchi, ÀMHA. Pour l'indentation à son "propre standard personnel", l'une des règles pour du développement collaboratif est de ne pas faire de changement à un niveau général sans le valider ensemble auparavant, enfin il me semblait. -- ProgFou
- Je suis d'accord qu'il est bon de discuter d'abord, mais je dirais qu'en fait il faudrait déterminer les cas où il faut vraiment discuter, et ceux où ce n'est pas vraiment nécessaires. Selon moi:
- Les cas à discuter:
- ajout / suppression de fonctionnalités (principalement les actions, formatters et handlers ainsi que le comportement de ceux-ci...)
- changement dans la modularité
- modifications de fonctionnement, entre autres:
- résultat retourné par les fonctions / méthodes
- type de paramètres des fonctions / méthodes
- ajout / suppression de paramètres pour une fonction / méthode
- ajout / suppression d'une fonction / méthode / classe / propriété d'une classe / constante
- ajout / suppression d'un fichier, découpage d'un fichier en plusieurs
- tout changement au niveau de la base de données
- Les cas à ne pas discuter:
- correction de bugs
- amélioration des performances
- corrections au niveau du respect de la synthaxe de php (principalement pour éviter l'utilisation d'une synthaxe dépréciée)
- (nb.: Je pense que mes corrections des 18 et 19/12/2004 faisaient toutes partie de ces trois cas en fait... peut-être y a-t-il certaines choses qui sont à la limite de ne pas être des bugs, mais voyez tout de même DevActionsEntetePiedDePageEtLinkTracking pour plus d'explications.) -- LordFarquaad
- Je ne suis pas d'accord non plus avec ce découpage de cas à discuter. Selon moi, les seules choses qui n'ont pas besoin d'être discutées sont les corrections syntaxiques ou orthographiques mineures, et encore. Pour tout le reste, il devrait y avoir accord au minimum de deux développeurs, incluant même l'un des fondateurs en cas de modification importante, avec une trace écrite de cet accord dans tous les cas (en général sur wikini.net ou wikini-dev). Ceci même (voir surtout) pour une correction de bogue de sécurité. Une amélioration des performances nécessitant souvent une profonde réflexion, vu qu'elle a rarement une solution unique. La stabilité étant le maître mot. -- ProgFou
- Mais à ce moment là on ne profite plus vraiment du CVS je trouve: si toute correction est sensée être définitive (puisque parfaite) [Pas parfaite, mais non auto-validée. -- ProgFou], alors pourquoi garder les version antérieures ? Je trouve qu'il devrait être possible justement, de commun accord, de révoquer une version et de repartir d'une version plus ancienne. Je trouve que ce que tu proposes est vraiment un frein trop important au développement [Pas quand les développeurs savent communiquer entre-eux. -- ProgFou - Pour l'instant ce n'est pas le cas il me semble... -- LordFarquaad] :
- j'ai l'impression que réunir deux développeurs sur un même sujet est assez difficile, surtout s'il faut que l'un des deux soit un fondateur... [CharlesNepote et moi, au moins, passons régulièrement visiter wikini.net. Pour la notion de fondateur, c'est pour garantir le respect de la PhilosophieDuProjetWikiNi et, de fait, on y fait rarement appel tant qu'on ne s'en écarte pas. -- ProgFou] il y a trop peu de développeurs (et, mis à part avec la mailing list, je ne vois pas trop comment contacter les autres :-S) [Sur wikini.net. -- ProgFou - il me semble que plusieurs développeurs ne passent pas beaucoup sur wikini.net, tant pis pour eux ? Au fait je n'ai pas accès à l'EquipeDeDeveloppement... -- LordFarquaad]. De plus chacun a un peu ses préférences et ne suit donc pas forcément tous les développements... [Cette réflexion ne serait valable que si le code était réparti entre les développeurs par zones de responsabilités, ce qui n'est heureusement pas le cas ; ce serait vraiment freinant pour un projet de cette taille. -- ProgFou - Possible, quoi que je parlais de préférences et non de répartition. Il y a quand même pas mal de développement en cours et ce n'est pas facile de les suivre tous (surtout qu'ils disparaissent souvent dans un trou perdu avant de réapparaitre bien plus tard...). Pour moi le projet n'est pas si petit que ça vu le nombre de choses qu'il y a à faire... -- LordFarquaad]
- actuellement, l'endroit où discuter d'un développement ne me paraît pas du tout clair... En général on crée une nouvelle page, en plaçant un peu des retro-liens là où on peut... il est impossible de dire véritablement quels développements sont en cours: la plupart des pages dont le sujet est le développement et les améliorations sont complètement désordonnées et ne sont pas mises à jour (par exemple EnCoursDeDeveloppement, VosSuggestions, ou même RapportsDeBogues...) [De mon coté je passe par l'analyse des pages modifiées via le TableauDeBordDeCeWiki. Il suffit que tu modifies n'importe quelle page, peu importe son intitulé, pour que j'aille lire ce que tu y as écrit. C'est effectivement ce que je fais en pratique et j'imagine que les autres en font autant. -- ProgFou - Oui, pour ma part je consulte les DerniersChangements et les DerniersCommentaires. Mais tu noteras tout de même qu'il y a beaucoup de sujets de développements qui ne sont plus listés là... (notamment à cause du spam d'ailleurs) A mon sens cela ne suffit donc pas. -- LordFarquaad]
- il est par conséquent difficile de savoir si d'autres gens sont en train de travailler sur le même fichier que celui qu'on voudrait soi-même modifier... [Non. Lire ci-dessus. D'autre part on utilise aussi le courriel et Jabber. Le développement colaboratif est asynchrone par nature. Il faut savoir vivre avec. -- ProgFou - Je trouve qu'il faudrait au moins garder à jour EnCoursDeDeveloppement... -- LordFarquaad]
- (Tiens ce serait encore un avantage de créer une page pour chaque fichier: il suffirait de placer un lien vers la page du fichier qu'on prévoit de modifier, et d'utiliser une ActionBackLinks dans chaque page de fichier pour que n'importe qui puisse facilement voir quels sont les développements en cours par rapport à ce fichier.) [Je serais plus pour la dernière proposition de GarfieldFr : commentaires dans le code. -- ProgFou - Pour la partie documentation je suis d'accord (je l'avais d'ailleurs proposé avant lui...), mais pour les développements en cours ce n'est pas applicable... enfin soit, apparemment l'idée n'a pas de succès, et je trouve aussi que la documentation du code est plus importante. Il faudrait d'ailleurs décider d'une TechniqueDeDocumentationDuCodeSource?. -- LordFarquaad]
- ...
- Je pense qu'il est préférable d'avancer vraiment dans le développement (éventuellement par équipes de deux, ou trois maximum), quite à ce que de mauvaises versions soient réalisées et révoquées. Selon moi une équipe de deux développeurs qui participent vraiment peut modifier à elle seule plusieurs fichiers par semaine (par jour s'ils communiquent suffisemment vite) Ca décuplerait la vitesse de développement de WikiNi, et je pense que ça n'empêcherait vraiment pas de faire de très bonnes choses, au contraire... [Tu liras dans plusieurs pages du site que l'important ici (pour le projet WikiNi) n'est pas d'avancer vite mais d'avancer bien, après avoir bien réfléchi les choses. Il y a aussi des techniques pour avancer vite et pouvoir revenir en arrière, mais ça demande beaucoup de rigueur et surtout de coordination. -- ProgFou - Je crois qu'on pourrait sans problème avancer plus vite tout en avançant bien... Actuellement revenir en arrière n'est pas un problème grâce au CVS, la rigueur et la coordination ne sont pas un problème ici, je pense, si ? Tu pourrais peut-être exposer ces techniques, s'il te plait ? -- LordFarquaad]
- NB.: j'ai écrit tout cela avant de voir ce qui se trouve ci-après en fait... -- LordFarquaad
Je n'ai pas encore tout lu, mais avant d'aller faire dodo, je note une petite pensée avant de l'oublier : il faut trouver un juste équilibre permettant :
- un développement qui avance, sans frustrer les gens qui désirent aller plus vite
- un développement respectueux du consensus et encadré par quelques règles : trop de règles n'est pas bon non plus, attention
Nos procédures doivent être légères et nous devons aussi faire confiance au bon jugement de chacun. Et puis n'oublions pas que l'un des principes essentiels du développement coopératif et des wikis en particulier c'est le regard bienveillant qu'il faut apporter à chaque pierre apportée à l'édifice (les anglophones parlent du fameux
WikiLove? ; ça m'amusait au départ, mais je crois que c'est beaucoup plus important qu'on ne le pense).
--
CharlesNepote
Pour ma part j'ai toujours un regard très critique quand il s'agit des fondations de l'édifice. Les développeurs
WikiNi ont aussi une responsabilité envers la communauté de ses utilisateurs : celle de garantir un édifice stable dont les pierres sont solidaires. Mes critiques n'ont pas pour objectif de freiner les bonnes idées, mais de les encadrer pour garantir les objectifs principaux qui sont clairement exprimés dans la
PhilosophieDuProjetWikiNi. --
ProgFou
Je suis plutôt de l'avis de
CharlesNepote: l'équipe de développement est suffisemment restreinte que pour pouvoir faire confiance à tous ses membres. [D'un autre côté je dirais que j'ai peut-être été inclus trop vite dans celle-ci (c'est vrai, vous ne me connaissez à peine...)] Je pense que quand on fait partie d'une équipe de développeurs, il faut savoir ce qu'on fait et qu'on a sa part de responsabilité. Partant de ce principe, on peut avoir confiance en l'équipe et, comme le dit
CharlesNepote, au bon jugement de chacun. Discuter de tout c'est un peu comme si on prenait les développeurs pour des enfants qui ont, par leur manque d'expérience, besoin de beaucoup de réflexion en commun pour prendre de bonnes décisions... et en général d'une autorité supérieure pour déterminer que la décision est prise. (dans le cas présent: un fondateur ?...)
- D'une part, personnellement, je n'accorde pas ma confiance d'office : avec moi il faut faire ses preuves. Mais ça c'est mon opinion personnelle et je ne suis pas fondateur de WikiNi. -- ProgFou
- Oui c'est ce que je dis à mon sujet, mais les autres développeurs n'ont-ils pas fait leurs preuves ? N'as-tu pas confiance en toi ? -- LordFarquaad
- D'autre part, il ne faut pas confondre collaboration avec hiérarchie. Ce que je demande c'est de la collaboration via discussions et non pas de devoir valider tout ce qui doit passer dans le CVS (ça ne m'intéresserait pas). C'est la même différence qu'entre les pommes et les idées : si on échange nos pommes on reste chacun avec une pomme, mais si on échange nos idées on gagne des idées en plus. Sur la question du fondateur, j'y tiens dans le sens suivant : les fondateurs sont ceux qui ont eu l'idée du projet, ce sont eux qui ont inventé sa philosophie et il est donc logique qu'ils en soient les gardiens. Je fais appel à eux quand j'ai un doute sur un éventuel débordement de mes idées qui ferait s'écarter le projet de sa philosophie fondamentale. -- ProgFou
Personnellement, quand je vois une amélioration quelconque à faire, j'ai souvent des idées qui surgissent quant au code à écrire, et si je ne les applique pas directement, je risque de les oublier...
- J'ai aussi ce problème, mais ça c'est un problème intérieur que chacun de nous doit résoudre à sa façon ; mais en premier lieu, on ne doit jamais le faire subir aux autres. Ma méthode est de développer une version personnelle de WikiNi sur un de mes serveurs et de transférer petit à petit tout ce que j'ai développé vers le projet WikiNi lui-même. C'est mon équilibre, à toi de trouver le tien, mais le CVS de WikiNi n'est pas une plateforme d'expérimentations, enfin ÀMHA... -- ProgFou
- Je ne suis pas trop d'accord avec le terme "faire subir", dans le sens où si les autres ne sont pas d'accord, revenir en arrière ou apporter d'autres modifications ne pose vraiment aucun problème. Sinon ta technique de développement semble assez bonne, mais je trouve tout de même dommage que les autres ne puissent pas forcément voir quelles modifications tu as faites chez toi... cf ce que tu dis ci-dessous -- LordFarquaad
Par ailleurs je préfère voir une ou plusieurs réalisations concrètes sur base desquelles discuter, que de discuter longuement sur ce qu'on pourrait éventuellement faire (ce qui finit parfois par être oublié dans un coin perdu...) --
LordFarquaad
- Pour ça il faudrait peut-être relancer l'idée d'une branche de test. Mais moi je considère qu'un bon développeur doit être à même de discuter les choses sans les implémenter immédiatement, sinon on les appelle à juste titre des "pisseurs de code". Et quand des tests à court terme s'imposent, on devrait les faire sur un ou plusieurs sites de test. C'est mon opinion et je la défendrai jusqu'à ce que la majorité en décide autrement. -- ProgFou
- Je suis partant pour la branche de test. Discuter c'est bien, mais il y a tout de même des limites (qu'elles soient dans le temps ou dans les possibilités de discussions). Selon moi il arrive toujours un moment où il faut essayer quelques lignes de code pour voir ce que donne ce dont on est en train de parler, et comparer les solutions (quand il y en a plusieurs). De plus les discussions ne mettent pas toujours en avant les limites du langage de programmation ou de ce dont on dispose déjà... L'important dans les discussions, je pense, c'est surtout d'avoir une maquette du comportement que devra avoir le bout de programme à écrire, c'est d'ailleurs exactement ce qui est décrit en haut de cette page... Le problème sur WikiNI.net c'est que les discussions n'en finissent pas et que personne n'ose vraiment se lancer dans le développement... (surtout parce que personne ne sait quand il peut se lancer...) Je pense qu'il faut tout de même un responsable pour chaque développement, qui puisse ainsi décider que les discussions ont assez duré (notemment en imposant une échéance) et se lancer dans le développement en lui-même. Ensuite il faut voir si elle peut placer ce qu'elle a fait directement sur le cvs, ou si elle doit d'abord proposer son code pour validation. C'est la technique que j'aimerais employer dans les PropositionsDEvolutionDeLActionListPages, et je pense que cela peut être vraiment efficace. -- LordFarquaad
Je pense qu'il serait bon d'avoir un troisième avis sur toutes ces discussions, et aussi de faire un résumé des idées principales... (par exemple chacun pourrait noter les siennes, non pas dans le but d'en discuter encore, mais plutôt de donner un aperçu de ce qui a été dit) --
LordFarquaad