Bonnes pratiques - miguel-antoons/projet_webdev GitHub Wiki

Bonnes pratiques

Chacun respecte les avis des autres, si il n’est pas d’accord avec quelque chose il le cite sans attaquer les autres,
Il est préférable de résoudre des gros malentendus par réunion et non par texte,
Au moins une réunion par semaine, le mardi après-midi, sera organisé pour s’assurer que tout se passe bien,
On s’aide entre nous, si quelqu’un a des difficultés et qu’il a besoin d’aide, on tente de l’aider un maximum,
On se tient aux décisions prises lors des réunions que tout le monde a accepté,
On accorde de l’attention aux détails et la finition, que ça soir au niveau du code, de l’interface, des fichiers dans le wiki ou dans le Trello ou autre,
Quand on veut faire des modifications sur un produit créé par quelqu’un d’autre, on lui communique d’abord et on demande son accord.

Lorsqu’on commence une tâche technique, on la déplace depuis la colonne ToDo vers la colonne Doing,
On indique notre nom sur la tâche qu’on est entrain de faire,
Si on prend une tâche technique de la colonne ToDo et qu’il reste moins de 5 tâches dans la colonne, on veille à ré-remplir la colonne ToDo en découpant une user story en tâches techniques,
Lorsqu’on rajoute une user story ou une tâche technique, on veille à ce que le titre soit clair et que la description soit complète,
Quand on termine une tâche, on oublie pas de la mettre dans la colonne testing,
On déplace pas les étiquettes appartenant aux autres sans leur autorisation,
On ne déplace les tâches vers la colonne Done que si ils ont été validés par leur responsable et par le coach,
On n’oublie pas de numéroter les user story et tâches techniques qu’on ajoute sur Trello.

On décrit ce qui a changé lors des commits de façon a pouvoir les distinguer d’autres commits,
Pour sa branche sur la branche test on respecte bien la procédure suivante :

On commit et push les derniers changements de notre branche,
On pull la branche test de façon à la mettre à jour localement,
On merge la branche test dans notre branche personnelle,
On résout les éventuels conflits et dans ce cas on refait le merge,
On merge notre branche personnelle dans la branche test, ce qui devrait se passer sans trop de problèmes vu qu’on a déjà résout les conflits,
On commit et on push les modifications sur la branche test.

On évite de push des dossiers inutiles sur GitHub, tels que les venv Python, le dossier node-modules ou autres,
On ne push une fonction sur la branche main que lorsqu’elle a été validé par son responsable,
On met régulièrement à jour les fichiers contenant les informations pour le lancement du projet (requirements.txt, package.json, README.md, ...),
On respect l’organisation des fichiers décidé lors du début de projet,
On effectue des commits réguliers de ce qu’on a écrit comme code,
On essaye de commenter notre code de façon à ce qu’il soit clair même pour quelqu’un qui voit le code pour la première fois,
Avant de commit un code, on vérifie si ce code fonctionne bien et qu’il ne pose pas de problèmes autre part.