07. Méthodologie
Notre première bonne pratique concerne la communication au sein du groupe, nous avons décidé d’utiliser discord pour centraliser toutes nos communications, un channel discord a été créé pour chaque membre du groupe, celui-ci indique dans son channel lorsqu’il commence une nouvelle fonctionnalité, les autres membres peuvent lui poser des questions sur ses fonctionnalités sur son channel, cela permet une meilleure visibilité des informations et questions au sein du groupe.
Avec cette méthode, tous les membres du groupe savent sur quoi les autres personnes travaillent et peuvent suivre l'évolution de l'avancement.
Plusieurs autres salons textuels ont été créés pour pouvoir rassembler nos sources, formations et aide sur une catégorie spécifique du projet.
A chaque début de sprint, une nouvelle catégorie est créée avec comme titre le numéro du sprint, 4 salons sont présents dans cette catégorie, pour rassembler les informations en lien avec ce sprint.
Des moments de travail ensemble sont établis : tous les mercredis, tous les membres du groupe se retrouvent pour travailler sur le discord. Les membres du groupe n'ayant pas cours, nous profitons d'avoir cette journée libre pour être le plus productif possible. Il s'agit la de l'unique moment de travail définit.
Pour le reste du temps, les membres du groupe travaillent quant ils veulent, en indiquant sur le discord la partie sur laquelle il produise du travail (wiki, raspberry, configuration du serveur, code, documentation,...)
De ces réunions (prévue ou non), nous mettons en commun nos connaissances afin de pouvoir nous entraider dans l'apprentissage des différents langages, différents aspects techniques et permettre à tous les autres de savoir nous suivre dans le développement de ce dernier.
En cas de soucis, la personne ayant des difficultés poste un message sur notre discord auxquels les membres de l'équipe répondent afin de lui permettre de résoudre ses soucis
Nous avons décidé d'utiliser Visual Studio Code comme éditeur de code car tous les membres du groupe sont habitués à travailler avec celui-ci, de plus il semble être l'éditeur de code le plus utilisé ce qui le rend plus fiable à nos yeux.
Notre code est découpé en plusieurs fonctionnalités différentes, pour chacune de ces fonctionnalités une User Story est décrite dans les backlogs. Au moment du développement de chaque User Story, une nouvelle branche est créée sur lequel tout le code de cette US sera regroupé. Nous développons les fonctionnalités au fur et à mesure. Nous réalisons régulièrement des commits afin de pouvoir récupérer de manière simple un même code sur plusieurs appareils et une fois les tests unitaires de la fonctionnalités réussis, nous mergons le code afin de l'ajouter à la base commune de notre application.
Une base commune a été crée avec un code lié à la base de données et de laquelle nous pouvons effectuer les opérations CRUD : Un frontend pouvant être lancé, les données de ce dernier envoyés sur la backend qui lui même enregistre les données en base de données. Nous avons également une API afin de pouvoir réaliser tous ceci
Quand une fonctionnalité est finie, nous réalisons un rebaseavec le code du main afin de produire un nouveau main avec les fonctionnalités ajouter par la User Story.
Le linter utilisé est un linter réact installable sur Visual Studio Code : eslint.
D'avantage de détail dans le "ReadMe" du module eslint :
Nous utilisons git afin de push notre code, pour récupérer le code et de mettre ce dernier en commun. Il s'agit d'un outil très intéressant afin de nous faciliter le travail quand à la gestion de notre code.
Dans le passé, nous n'utilisions que l'interface web de git, Github, pour centralisé notre code. Nous avons rapidement rencontré les limites d'utilisation de ce dernier.
Le fait que la gestion des nodes_modules soit très compliqué et le fait qu'on doive utiliser git nous a forcé à utiliser git en ligne de commande.
Nous avons donc créé pour chaque US une branche dans laquelle les membres du groupe travaillant sur cette US spécifique peuvent push leur code. Par la suite, si nous devons travailler sur une nouvelle US, nous faisons un rebase, c'est à dire qu'on remet à jour avec la branche principale "main".
À la fin de la production de la fonctionnalité, nous pushons sur la branche spécifique à la US sur laquelle on travaille et on ouvre une pull request. Ensuite, d'autres personnes du groupe (reviewers) vont inspecter le code et accepter ou non du push sur la branche "main".
Pour travailler sur une nouvelle US, nous avons clone le repo sur notre ordinateur local et nous faisons un git checkout de la US. Puis on rebase avec le main, après nous pouvons enfin commencer la US.
De plus, chaque matin, nous faisons un git rebase main si jamais quelqu'un a fini une pull request et que le main a changé pour nous mettre à jour.