README.adoc 7.56 KB
Newer Older
sunye's avatar
sunye committed
1
2
= GTD Server

sunye's avatar
sunye committed
3
4
*GTD Server* est un serveur de projets qui suivent la méthode _Getting Things Done_,
où un projet est composé de tâches et les tâches sont associées à un contexte.
sunye's avatar
sunye committed
5

sunye's avatar
sunye committed
6
Dans le cadre de ce projet, vous allez contribuer au développement de ce logiciel.
sunye's avatar
sunye committed
7

Gerson SUNYE's avatar
Gerson SUNYE committed
8
9
10
11
== Dates importantes

* Rendu du projet: 1 avril 2021

sunye's avatar
sunye committed
12
== Préambule
13

sunye's avatar
sunye committed
14
Pour compiler et tester ce projet, vous aurez besoin des logiciels suivants:
15

sunye's avatar
sunye committed
16
17
* Java Development Kit (JDK), version ≥ 11 (OpenJDK ou Oracle JDK)
* Apache Maven, version ≥ 3.6
18
19
20
21
22



== Communication

sunye's avatar
sunye committed
23
Avant de commencer le projet, connectez-vous au serveur Discord de l'UE (Software Construction and Evolution).
24

sunye's avatar
sunye committed
25
Vous trouverez dans ce serveur la salle `#projet`, où seront discutées les qustions concernant le projet.
26
27
28
29
30

**Utilisez ce canal comme SEUL et UNIQUE moyen de communication avec les encadrants, pour toute question concernant le projet.**

== Organisation

sunye's avatar
sunye committed
31
Ce projet sera réalisé par groupe de 4 étudiants.
32
33
34
35
36
37
Vous allez suivre le processus de maintenance vu en cours.
Pour rappel:

Commencez par préparer l'environnement de votre projet :

. Avant toutes choses, un membre du groupe doit créer un *"Fork"* du projet sur le serveur.
sunye's avatar
sunye committed
38
Pour ce faire, cliquez sur l'icône "Fork" (ou "Créer une divergence" en français) de la page du projet pour accéder au lien suivant: https://gitlab.univ-nantes.fr/naomod/sce/projet-2020/forks/new
39
40
41
42
43
44
45
46
47
48
49
50

. Ajouter tous les autres membres du groupe à votre fork.

. Créez des étiquettes pour organiser les tickets du projet: _bug_, _improvement_, _smell_, _performance_, _test_, etc.

. Chaque membre du groupe doit cloner *votre fork du projet* (et non pas celui d'origine).
Toutes vos modifications devront être poussées sur votre _fork_ et toutes les _issues_ (ou "tickets" en français) ouvertes le seront sur votre version du projet.

. *Il ne doit y avoir qu'un seul "fork" par groupe d'étudiants.* Il sera utilisé comme espace de rendu des fichiers liés au projet.

== Diagramme de classes niveau conception

sunye's avatar
sunye committed
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
.Diagramme de classes UML
[plantuml]
----
class Project {
    id : Integer
    name : String
    progress : Progress
}

class Task {
    id : String
    name : String
    due : DateTime
    progress : Progress
    frequency : Frequency
    priority : integer
    start : Date
    end : Date
}

class Idea {
    id Integer
    name : String
    description : String
}

class Tag {
    name : String
}

class User {
    id       : String
    login    : String
    password : String
}

class Context {
}

enum Progress {
    todo
    waiting
    delegated
    finished
}

enum Frequency {
    daily
    weekly
    monthly
    yearly
}

Project -> "subprojects [*]" Project
sunye's avatar
sunye committed
105
106
Project "[1]" *-- "[*]" Task
Project "[*]" --> "creator [1]" User
sunye's avatar
sunye committed
107
108
109
Project -- "participants [*]" User
User -> "*" Idea
Task *--> "[*]" Tag
sunye's avatar
sunye committed
110
Task "[*]" -- "[1]" Context
sunye's avatar
sunye committed
111
112
Task -> "creator [1]" User : "\t\t\t"
----
113
114
115
116


== Travail à réaliser

sunye's avatar
sunye committed
117
Dans ce projet, vous devrez résoudre les problèmes déjà répertoriés dans le peojet,
118
soit dans le fichier https://gitlab.univ-nantes.fr/naomod/sce/projet-2020/blob/master/ISSUES.adoc[`ISSUES.adoc`],
119
soit directement dans le code grâce aux commentaires de type `TODO`, `FIXME`, ou `XXX`.
120

121
122
123
124
Pour résoudre ces problèmes, vous allez tout d'abord créer au moins un ticket correspondant au problème.
Dans certains cas, un seul problème peut engendre plusieurs tickets.
Pour ajouter un ticket à votre projet Gitlab (sur l'interface en ligne de Gitlab, section _Tickets_).
Vous devrez y détaillerez les points suivants:
sunye's avatar
sunye committed
125

126
127
128
. Un bref résumé du problème lié au ticket.
. Quels sont les tests à mettre en oeuvre pour vérifier que le ticket a bien été résolu ?
. Comment la solution au ticket doit être mise en oeuvre ?
129

130
Ensuite, pour chaque ticket du fichier https://gitlab.univ-nantes.fr/naomod/sce/projet-2020/blob/master/ISSUES.adoc[`ISSUES.adoc`]:
131
132
133
134
135

. *Associez un membre du groupe* à la résolution du ticket, via l'interface de GitLab.
Cette personne, et uniquement celle-ci, sera chargée de résoudre le ticket.

. Créez 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.
sunye's avatar
sunye committed
136
Pour le nommage de vos tests, vous pouvez vous référer à la ressource suivante: https://dzone.com/articles/7-popular-unit-test-naming.
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154

. Implémentez le code qui résout le ticket.
Les tests écrits précédemment devront valider votre implémentation. _Faites attention à la régression !_ :
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.

. 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 :
https://docs.gitlab.com/ee/user/project/issues/automatic_issue_closing.html[Automatic issue closing]

Le code du projet est là pour vous fournir une base de code.
sunye's avatar
sunye committed
155
Vous êtes libre de _modifier l'implémentation comme vous l'entendez_ et même de modifier le modèle de classes UML en lui-même !
156
157
158
159
160
161
162
*Mais attention, vous devrez motiver tous vos changements dans vos différents tickets/commits !!!*

== Évaluation

* 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.

sunye's avatar
sunye committed
163
164
* Ajoutez 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.
165

166
167
* Ajoutez un fichier appelé «`CONSTRIBUTORS.adoc`» à la racine du projet, afin de lister les participants du projet.

168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
* Pour être évalué, *tout étudiant doit participer activement au 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 cycle de développement donné dans l'énoncé:
. ouverture du ticket;
. écriture des tests;
. validation (`git commit`);
. codage;
. validation;
. publication des validations (`git push`);
. fermeture  du ticket.

** Qualité des tickets ouverts sur votre projet Gitlab: description du problème, des tests requis et de la solution mise en oeuvre.
** 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é !* 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étectez les erreurs de code avec IntelliJ et Sonarlint

L'éditeur IntelliJ propose un plugin appelé https://www.sonarlint.org/[Sonarlint], capable de détecter les _code smells_ dans vos projets.
Nous vous recommandons de l'installer et de l'utiliser dans le cadre de ce projet.

Pour l'installer, vous avez deux options:

sunye's avatar
sunye committed
198
. Allez dans le menu "Préférences" de IntelliJ ->; Section "Plugins", cherchez "Sonarlint" puis cliquez sur "Installer".
199
. Installez le manuellement : https://plugins.jetbrains.com/plugin/7973-sonarlint