Process de l'évaluateur

Ce document est donné à titre indicatif. Les évaluateurs s'autorisent à le modifié même après le rendu final.

Processus

Processus réalisé par l'évaluateur d'un projet:

1. Cloner le répertoire git du projet.

   • team-gray: ssh://[e-mail]:2222/fatus/50NuancesDeCode/game.git

   • team-green: ssh://[e-mail]:2222/fatus/green-peace-2020/NetWorld-Green-Peace.git

   • team-orange: ssh://[e-mail]:2222/fatus/orange-bbemmn-2020/ORANGE-BBEMMN.git

   • team-pink: ssh://[e-mail]:2222/fatus/pink-imters-2020/netWorld.git

   • team-purple: ssh://[e-mail]:2222/fatus/purple-drank-2020/purple-drank.git

   • team-red: ssh://[e-mail]:2222/fatus/red-fish-game-2020/red-fish-game.git

   • team-yellow: ssh://[e-mail]:2222/fatus/harmo-info-yellow-2020/harmoinfo.git

2. Vérifier que l'on est bien sur la branche master (git status)

3. Se référer aux README pour avoir une idée globale du projet.

4. Se référer aux README pour avoir trouvé les instructions d'installation et de lancement de la solution.

5. Tester la solution.

6. Se référer aux projet-outline.md pour se faire une idée de se qui a été développé et de comment s'est répartie le travail.

7. Entrer dans le code pour juger de sa qualité (lisibilité, efficacité).

Ce qui est vraiment important

Comme décrit dans dans le processus d'évaluation deux documents sont primordial:

• Le README: tout en étant concis, il donne une présentation globale du projet et les points d'entrée pour s'approprier le travail.

• Le Projet Outline: Il permet de lister les composants du projet et donne une image nette de ce qui a été fait, de se qu'il est prévu de faire par la suite et de comment c'est réparti le travail. Si ce n'ait pas évident, il pointe aussi où dans le code on peut trouvé les éléments développer pour répondre au besoin.

Enfin, conserver sur le master une version opérationnelle. Il est préférable d'en avoir moins sans erreur de segmentation que beaucoup dans le code, mais ou rien ne peut être réellement testé.

Ensuite, il s'agit de proposer un code le plus lisible possible, voire une documentions à côté qui sera visité en même temps que le code.

Une idée du Barème

• 1/4 de la note repose sur le groupe classe: À savoir est-ce que les compétences C on était à peu près équitablement répartie (soit quel est le groupe avec le code le plus moche et à quel point il est moche...).

• Un grand quart sur l'efficacité: le nombre et la difficulté des composants réalisés.

• Un autre grand quart sur la qualité: Le code, efficacité des structures et des algos mis en oeuvre.

• 1/4 sur la propreté de la solution: lisibilité du code, utilité des ressources proposée (tutos ...).

• 1/4 sur l'implication individuelle dans la réalisation du projet.