01 - Revue de code d'une autre équipe

Votre objectif

Effectuer des revues de code dans le projet d'une autre équipe et vous familiariser avec leur projet dans le but de vous préparer à votre ESP.

N'attendez pas à la dernière minute pour faire cette tâche puisque l'équipe pour qui vous faites la revue de code devra effectuer les correctifs. Elle doit avoir le temps d'apporter les correctifs nécessaires.

Détails de la tâche

Valant pour 10% de la note finale, vous avez à faire la revue du projet d’une autre équipe. Cette revue vous permettra, entre autres, de mieux comprendre le projet en préparation à votre ESP.

Cette revue se fait individuellement. Étant donné que le but ultime de cet exercice est de vous familiariser avec le code pour votre ESP, il est recommandé de couvrir autant de code que possible.

Plusieurs membres de l'équipe peuvent donc couvrir la même partie de code ou le même document. Il est par contre important de ne pas indiquer la même erreur plusieurs fois. Il est donc de votre devoir de réviser ce qui a été trouvé précédemment. Si vous trouvez un problème qui a précédemment été identifié dans une autre section, vous pouvez créer une nouvelle issue.

Pour vous aider à vous coordonner, vous devrez créer un fichier de travail (ex.: Google Sheet/Excel) indiquant clairement quelles parties de code, ou quels documents vous avez évalués, que vous ayez ou non trouvé une issue dans cette partie.

Finalement, afin de noter les problèmes, vous devez créer des issues dans le dépôt Gitlab du projet de l’autre équipe sous le tag revue. Il est important que le tag soit utilisé afin d'identifier clairement ces issues. Autrement, elles pourraient ne pas être corrigées.

Exemples de problèmes que vous pouvez relever (il peut y en avoir d’autres, ne pas vous limiter à cette liste!):

• Non-respect des standards du langage
• Bug
• Problème d'affichage empêchant le fonctionnement
• Faille de sécurité
• Problème de performance important
• Validations manquantes
• Mauvaise procédure d’installation et/ou de configuration
• ...

Procédure

1. Relevez les problèmes rencontrés dans le projet et créez des issues sur GitLab

2. Utiliser l’étiquette (label) revue pour identifier les issues que vous créez.

3. Utiliser une description standardisée. La description de l'issue doit utiliser le gabarit suivant:

   ## Description
   
   (Décrire le problème de façon concise.)
   
   ## Étapes pour reproduire
   
   (Comment reproduire le problème (étapes, configurations, séquence, etc.)
   
   ## Quel est le comportement actuel?
   
   (Ce qui se produit lorsque vous effectuez l'action)
   
   ## Quel est le comportement attendu?
   
   (Ce qui devrait se produire ou ce que vous devriez voir)
   
   ## Captures d'écran et logs pertinents
   
   (Ajoutez le ou les logs pertinents - utiliser les blocs de code markdown (```) pour formater le log ou le code.
   Vous pouvez aussi inclure toute capture d'écran pertinente)
   
   ## Solutions possibles
   
   (Si vous avez de l'information sur la cause du problème, n'hésitez pas à détailler.)
   
   /label ~revue
   Issue Templates

   Vous pouvez créer des gabarits de issues (issue template) en suivant la procédure suivante: https://docs.gitlab.com/ee/user/project/description_templates.html#create-an-issue-template.

4. Identifier clairement l'auteur de l'issue. Puisque cette revue se fait individuellement, vous devez indiquer clairement que c’est vous qui avez créé l'issue. Si votre utilisateur Gitlab vous identifie clairement, vous n’avez rien à faire de plus. Si ce n’est pas le cas, vous devez signer vos issues afin de pouvoir vous identifier.

5. Créer un fichier de travail. Vous devez créer un tableau indiquant clairement quelles parties de code, ou quels documents vous avez évalués, que vous ayez ou non trouvé une issue dans cette partie.

   Afin de simplifier le travail d’équipe, il est recommandé de créer un document partagé (ex: google doc ou Excel sur Teams). Vous pouvez entrer toute l’information sur le même document en indiquant clairement qui fait quoi.

   Ce tableau devra être remis à la fin de la session sur votre dépôt git.

Précisions sur les issues

Vous pouvez regrouper plusieurs problèmes du même type touchant un même fichier/document dans une seule issue.

Vous pouvez également regrouper plusieurs problèmes similaires touchant plusieurs fichiers/documents dans une seule issue (ex : un bug touchan à plusieurs portions du code de l'application)

Ne créez pas une seule issue pour des problèmes différents. De façon générale, un problème = une issue.

Qui fait le revue de qui?

Équipe	Fait la revue de
FileDrette →	Remorques Ricard
Remorques Ricard →	FileDrette
CIUSS →	LBI
LBI →	CIUSS

Modalités de remise

• Remis via Confluence
• Le fichier de travail doit être placé dans une section Remise Finale de votre Confluence. Un seul fichier par équipe.
• À remettre avant le 28 février 2025 23:59

Grille d'évaluation

Le critère Couverture (quantité et variété des issues) est une note d'équipe, alors que le reste est évalué individuellement.

Critère	Points
Couverture (quantité et variété des issues)	30%
Pertinence des issues soulevées	30%
Qualité des issues en fonction du gabarit (comportement attendu, comportement actuel, étapes pour reproduire, contexte (ex.: navigateur utilisé, version logiciel, ...), logs pertinents ou captures d'écran, solution possible (si applicable)	40%