[rules] Consignes de développement

[remrem]

Après en avoir discuter avec @BoboTiG, il serait bien de mettre en place des consignes de développement, au moins pour la partie core et sur la branche dev, avant de les graver dans le marbre, je propose les points suivants :

1. code commenté par un autre contributeur = pas de suppression

2. ajouter des commentaires au besoin, ne pas hésiter à être bavard dans les sources, exemple :

   /**
   * dev note
   * bout de code pour test, en cas de modification attention à l'impact sur le reste du script
   */

3. Si vous souhaitez supprimer du code et que vous n'avez pas le temps de tester ou que vous ne connaissez pas précisément l'impact de cette suppression, ne le supprimez pas, commentez le ;)

4. mettez en place des fallbacks/test, même sur des choses toutes simples, il vaut mieux un bon die( __file__ .' : '. __line__ ); qu'une erreur php. Si ça passe sur master, ça fera moins paniquer l'utilisateur qui n'est pas habitué ou qui stress à la vue d'une erreur PHP. (pour info, on discute d'un système de gestion/affichage des erreurs)

   if ( !mkdir( '/plante/car/pas/possibl€/' ) ) {
   die( 'fail on create folder. '. __file__ .' : '. __line__ );
   }

5. Si vous n'avez pas le temps de tester comme il faut vos modifications/suppression/ajout, si c'est du POC, dites le dans le PR ou le commit, un homme averti en vaut 10, <- vous l'avez pigée celle-là ?

6. Si possible, en dev, éclatez votre code, la lecture en sera facilité, le debug aussi, par exemple : strpos('http:',explode('/',html_entities(trim($url),ENT_QUOTES,2)['0'])>($pi*($earth/360))); est plus difficile à appréhender correctement du fait qu'il n'est pas très lisible.

7. Pour la branche dev, lorsque la roadmap est accomplie, on freeze (pas d'ajouts de fonctionnalités au core), on se limite au debug, peaufinage, nettoyage (commentaires, code...) et optimisations histoire d'éviter de sortir une version tous les 6 mois

8. versioning, je pense que l'on a tous la même vision du système de versioning, mais bon, histoire de mettre tout le monde au diapason, la version est numéroté tel que : x.y.z pour major.minor.micro

   • major : "rupture", incompatibilité avec les versions précédentes, changement(s) majeur(s)
   • minor : "évolution", ajout de fonctionnalité(s), ne doit pas casser la rétro-compatibilité au sein de major
   • minor : "debug", essentiellement des versions de maintenance et de debug, ne doit pas casser la rétro-compatibilité au sein de micro

Entre développeurs, il peut y avoir des différences de points de vue quant aux conditions de +1 sur major, plus précisément : une rupture point de vue code sans changement des fonctionnalités et interfaces peut être considéré comme une rupture de major, ce qui en terme de code, n'est pas faux, mais en terme d'interface est faux.

(de RemRem) Personnellement, je pense que la v3.7 devrait être la v4.0 (rupture de code), mais BT ayant pour finalité d'être un outil accessible au profane (:D), je pense qu'il ne faut pas adopté mon avis, c-à-d qu'il faut rester au versioning de Mme Michu, le code, elle ne le vois pas, mais l'interface si, et de ce point de vue, il y a évolution, mais pas rupture.

9. Une proposition ?

Qu'en pensez-vous ?

En cas d'ajout/modification de consignes, je modifierai ce commentaire et quand tout sera validé/discuté , on le poussera sur le wiki.

[BoboTiG]

5. :D
6. On peut même éclater le code en prod, un code lisible n'est pas forcément moins performant.
7. Nickel, j'e l'aurai ajouté si tu ne l'avais pas fait.

[remrem]

UPD Ajout du point 8

[BoboTiG]

8. Pas de soucis, on se calque sur SemVer (explication de Sam).

[BoboTiG]

7. Pendant la phase de freeze, je serai chaud à ce qu'on fasse le ménage dans les commentaires, TODO, FIX pour produire une release propre aussi bien niveau code que fonctionnalités.

[remrem]

@BoboTiG 7. Yep c'est ce que j'entendais par "nettoyage" :) j'édite pour être plus précis

[BoboTiG]

Hop, ajouté au Wiki. N'hésite pas à modifier.