@@ -11,11 +11,13 @@ Si vous utilisez les machines des salles de TPs dans le cadre de ce projet, vous
Vous pouvez changer le JDK utilisé dans un projet dans
menu:Project structure[Project > Project SDK].
IMPORTANT: Pour poser des questions sur le projet, utilisez le https://mattermost.univ-nantes.fr/genie-logiciel/channels/cel-2022-23[Canal Mattermost] appropriée.
== Organisation
Ce projet sera réalisé par groupe de 3 étudiants.
Pour simplifier l'identification des participants,
IMPORTANT: Pour simplifier l'identification des participants,
utilisez *toujours* le compte GitLab lié à votre numéro d'étudiant.
Vous allez suivre le processus de maintenance vu en cours.
...
...
@@ -64,15 +66,17 @@ Pour chaque ticket du fichier link:./ISSUES.adoc[`ISSUES.adoc`]:
WARNING: Certains tickets sont plus longs et peuvent être réalisés par différents membres, tout au long du projet.
Par exemple, les tickets qui concernent la traduction ou le renommage d'identifiants.
. Créer les tests unitaires qui permettront de vérifier d'abord qu'il s'agit bien d'un problème et ensuite de la résolution du ticket.
. Créez des tests unitaires qui permettront de vérifier d'abord qu'il s'agit bien d'un problème et ensuite de la résolution du ticket.
Pour le nommage de vos tests, vous pouvez vous référer à la ressource suivante: https://dzone.com/articles/7-popular-unit-test-naming.
. Implémenter le code qui résout le ticket. Les tests écrits précédemment devront valider votre implémentation. _Faites attention à la régression{nbsp}!:
. Écrivez le code qui résout le ticket. Les tests écrits précédemment devront valider votre implémentation.
IMPORTANT: Faites attention à la régression{nbsp}!:
toute modification ne doit pas "casser" du code qui marchait auparavant (les autres tests unitaires doivent passer).
. Si jamais vous devez changer d'approche au niveau des tests, de l'implémentation, etc, *ajoutez un commentaire sur le ticket Gitlab* pour documenter tout changement. *N'éditez pas le texte du ticket original*, afin de garder un historique de votre travail.
. Effectuer un (ou plusieurs) commit(s) pour pousser vos modifications sur le dépôt, en référençant le numéro du ticket et en indiquant votre progression dans sa résolution. Nous vous invitons à lire le billet suivant à ce sujet: https://chris.beams.io/posts/git-commit/.
. Effectuez un (ou plusieurs) commit(s) pour pousser vos modifications sur le dépôt, en référençant le numéro du ticket et en indiquant votre progression dans sa résolution. Nous vous invitons à lire le billet suivant à ce sujet: https://chris.beams.io/posts/git-commit/.
. Enfin, quand le ticket est résolu, marquez-le comme "résolu" dans l'interface de Gitlab.
Vous pouvez aussi fermer les tickets automatiquement à l'intérieur d'un message de commit{nbsp}: https://docs.gitlab.com/ee/user/project/issues/automatic_issue_closing.html[Automatic issue closing]
...
...
@@ -83,21 +87,21 @@ Le code du projet est là pour vous fournir une base de code. Vous êtes libre d
* Le travail à rendre se composera de votre *fork en ligne Gitlab*, sur lequel vous aurez poussé toutes vos modifications. Cela inclut également tous les messages de commits et tickets ouverts.
* Si vous le souhaitez, vous pouvez ajouter un fichier "`RENDU.md`" à la racine du projet, afin de décrire les spécificités de votre projet (choix techniques, parties non traitées, extensions non demandées, etc.).
* Ajoutez un fichier "`RENDU.adoc`" à la racine du projet, afin de décrire les spécificités de votre projet (choix techniques, parties non traitées, extensions non demandées, etc.).
* Pour être évalué, *tout étudiant doit participer activement du projet*, en réalisant des "commits", en ajoutant des lignes de code, en ouvrant des tickets sur le serveur GitLab, etc.
* L'évaluation portera sur les critères suivants :
* Respect du protocole de développement donné dans l'énoncé (ouverture du ticket -> écriture des tests -> développement -> commits -> fermeture du ticket).
** Respect du protocole de développement donné dans l'énoncé (ouverture du ticket -> écriture des tests -> développement -> commits -> fermeture du ticket).
* Qualité des tickets ouverts sur votre projet Gitlab{nbsp}: description du problème, des tests requis et de la solution mise en œuvre.
* Qualité du code produit.
* Qualité et pertinence des tests unitaires mis en place.
* Approche choisie pour résoudre chaque ticket.
* Qualité des messages de commits.
** Qualité des tickets ouverts sur votre projet Gitlab{nbsp}: description du problème, des tests requis et de la solution mise en œuvre.
** Qualité du code produit.
** Qualité et pertinence des tests unitaires mis en place.
** Approche choisie pour résoudre chaque ticket.
** Qualité des messages de commits.
*Ne sacrifiez pas la qualité à la quantité{nbsp}!* Il vaut mieux rendre un projet bien réalisé avec des tickets non résolus qu'un projet avec tous les tickets mal résolus.
IMPORTANT: *Ne sacrifiez pas la qualité à la quantité{nbsp}!* Il vaut mieux rendre un projet bien réalisé avec des tickets non résolus qu'un projet avec tous les tickets mal résolus.
== Détecter les erreurs de code avec IntelliJ et Sonarlint
