07. Méthodologie - Iziclock/T304-Projet-Integration_IziClock GitHub Wiki

Méthodologie

Bonnes pratiques

  • Commenter le code en Français
  • Code en Anglais ; Commentaires en Français
  • CamelCase pour nom de variables et de fonctions (Première lettre en majuscule pour les classes)
  • Commits en Anglais et en utilisant la méthodologie Graphite (voir README)
  • Noms de branches significatifs en Anglais et en camelCase.
  • A la fin de chaque message de commits, Ajouter '#' suivi du numéro d'issue lié.
  • Chacun ne peut être assigné qu'à une tâche en même temps (sauf US perso)

Code

Frontend

  • Tous les composants sont regroupés dans un dossier "components". Pour créer un composant, ionic generate component components/<componentName>.
  • Tous les services sont regroupés dans un dossier "services". Pour créer un composant, ionic generate service services/<serviceName>.
  • Tous les pipes sont regroupés dans un dossier "pipes". Pour créer un composant, ionic generate pipe pipes/<pipeName>.
  • Chaque interface a un fichier propre dans le dossier 'interfaces'.
  • Chaque interface est créé et géré par une classe. Toutes les classes sont regroupées dans un dossier 'classes'.
  • Chaque page a un dossier à part entière.

Linter utilisé : ESLint

Backend

  • Chaque groupe de routes est défini par un fichier propre dans un dossier à l'intérieur du dossier 'routes'. Chacun de ces packages a une méthodes Routes qui regroupe les routes du groupe.
  • La documentation du serveur est rédigé grâce à Swagger. Celui-ci nécessite une documentation de chaque route.

Linter utilisé : Go possède un Linter intégré

Git

Dans le cadre de ce projet, nous avons choisi d'utiliser le workflow Git flow.

1.1. Explication

Git flow impose l'utilisation de plusieurs branches comme "main", "develop". Une branche supplémentaire est créé à partir de la branche "develop" à chaque fois qu'on travaille sur une nouvelle fonctionnalité. Une fois que l'implémentation de la fonctionnalité est terminée, on peut merge la branche créé spécialement pour l'implémentation de la fonctionnalité avec la branche "develop". La branche "develop" peut seulement être merge avec la branche "main" lorsque celle-ci possède une version fonctionnel et stable de l'application. La branche "main" sera celle qui sera en production constante.

Git flow est une manière de travailler en groupe pour implémenter au fur et a mesure chaque fonctionnalité. Son utilisation est très intéressante car elle permet au groupe de chacun travailler efficacement sur une fonctionnalité sur une branche unique. Il est important de bien maitriser des outils comme merge et rebase pour utiliser ce workflow.

1.2. Justification

Nous avons choisi d'utiliser ce workflow car il permet de collaborer facilement ensemble et de facilement savoir qui travaille sur quoi à tout moment. C'est important pour nous car nous sommes 8 dans le groupe et ce workflow nous permet donc de bien structurer la répartition du travail. Chacun peut travailler sur une fonctionnalité en y créant une branche associée. On peut également travailler sereinement sur notre branche, et donc sur notre fonctionnalité tout en étant sûr de ne pas gâcher le travail d'un autre.

Gestionnaire de temps

Nous n'allons pas utiliser de gestionnaire de temps. D'après les expériences globales de l'équipe, les membres ont tendance à oublier d'activer ou désactiver le gestionnaire de temps ce qui faute les chiffres récupérés. La solution adopté est donc de mettre à jour le temps au fur et à mesure dans le GitHub Project pour chaque tâches effectuées. La méthode est moins précise mais moins demandant en ressources.

⚠️ **GitHub.com Fallback** ⚠️