Gestion du projet Tamagoshi avec Git

PARTIE 1

Ce TP va vous permettre d'acquérir un minimum de maîtrise de l'outil Git et du workflow qui lui est associé. Git permet de gérer l'évolution d'un code source de manière très efficace, que ce soit en solo ou en collaboratif. Notre objectif est ici d'expérimenter son utilisation sur le projet tamagoshi.

Exercice 1:

Un des principaux avantages de Git est qu'il permet de gérer à distance un dépôt de code source (repository), tout en travaillant en local sur machine. Lisez les deux premiers chapitres de sa documentation en ligne : en anglais ou en français.

Exercice 2:

Il existe beaucoup de logiciels, sous forme de Web app, faisant office d'interface pour gérer des dépôts : GitHub par exemple. En ce qui nous concerne, nous utiliserons une instance de GitLab hébergée au département, où chacun d'entre vous possède un espace personnel. Loggez vous sur votre espace depuis la : page d'accueil.

Exercice 3:

Créer un nouveau projet Tamagoshi après avoir lu, entièrement, la page de la documentation correspondante. Il existe en effet plusieurs façon de procéder. Testez les différentes lignes de commandes vues dans les chapitres de la documentation de Git.

Exercice 4:

Les IDE reconnaissent les dossiers qui appartiennent à un dépôt et permettre d'accéder à toutes les fonctionnalités de Git depuis leur interface. Assurez vous que votre IDE est bien en phase avec cette nouvelle gestion de votre code source.

Exercice 5:

Vous devriez donc maintenant avoir une branche master en place. Dans un dépôt, il est inutile de conserver certains fichiers, notamment ceux qui sont générés automatiquement. Le fichier caché .gitignore permet de gérer cet aspect. Lisez sa documentation puis modifiez votre fichier .gitignore afin que git ignore tous les fichiers qui n'ont pas besoin d'être suivis, par exemple les dossiers bin, build ou ceux contenant de la javadoc. Testez avec la commande git status. Validez vos changements avec un commit

Exercice 6:

L'un des concepts les plus utiles de Git est celui de branche. Lisez le troisième chapitre de la documentation de Git pour en avoir une bonne compréhension. Reproduisez les conseils lus. Vous devriez donc avoir ensuite au moins deux branches identiques : master et develop.

Dans ce qui suit, pour chacune des parties, vous allez suivre le workflow Git en travaillant sur des branches dédiées. Par exemple, pour travailler sur la javadoc, vous créerez d'abord une nouvelle branche ""javadoc"" à partir de develop sur laquelle vous ferez les modifications associées. Vous ferez un commit pour chaque classe modifiée, puis, une fois la javadoc entièrement réalisée, vous ferez une fusion de la branche javadoc dans la branche develop. Ce qui permettra de vérifier le tout sur la branche develop, avant une éventuelle fusion avec la branche master.

PARTIE 2 : De nouveaux tamagoshis

On va maintenant durcir un peu le jeu en introduisant deux types différents de tamagoshi : les gros mangeurs et les gros joueurs. Créez tout d'abord une novelle branche "new_tamagoshi" à partir de develop et basculez dessus.

Exercice 7:

Créer deux nouvelles classes dans le package tamagoshis.tamagoshi : la classe GrosMangeur et la classe GrosJoueur qui héritent toutes les deux de la classe Tamagoshi. La seule différence avec la classe précédente tient respectivement dans la modification des méthodes consommeEnergie et consommeFun : chacune de ces méthodes consomme un point supplémentaire pour la variable concernée.

Exercice 8:

Pour arriver à obtenir ce que vous voulez, il faudra changer le modificateur de visibilité de certaines variables ou rajouter des méthodes. Effectuer cette modification.

Exercice 9:

Modifier la classe TamaGame de sorte que le type de tamagoshi créé l'initialisation ait 50 % de chances d'appartenir à l'une ou l'autre de ces deux classes.

Exercice 10:

Lorsque le jeu se termine, on veut maintenant que le bilan affiche quelles étaient les classes des différents tamagoshis :

Exemple :

-------------bilan------------

Pierre qui était un GrosMangeur n'est pas arrivé au bout et ne vous félicite pas :(

Paul qui était un GrosJoueur a survécu et vous remercie :)

Jacques qui était un GrosJoueur a survécu et vous remercie :)

niveau de difficulté = 3, score obtenu :63.0%

API

java.lang.Object

java.lang.Class

Exercice 11:

Imaginez une nouvelle classe de Tamagoshi avec un comportement encore différent.

PARTIE 3 : noms aléatoires

Exercice 12:

Sur une branche "random_names", améliorer l'ergonomie du jeu en permettant à l'utilisateur de choisir une génération automatique des noms de manière à ne pas avoir à les saisir. Par exemple, en choisissant des noms aléatoirement dans une liste prédéfinie.

Exercice 13:

Etendez le jeu à loisir ! Par exemple en imaginant de nouveaux comportements et/ou de nouvelles classes.

PARTIE 4 : durée de partie modifiable

Exercice 14:

Ajoutez la possibilité pour l'utilisateur de pouvoir choisir la durée de vie des tamagoshis, et donc la durée maximum d'une partie

PARTIE 5 : refactoring

Exercice 15:

Faites en sorte que votre code soit le plus factorisé possible (i.e. Il ne devrait jamais y avoir deux lignes qui se ressemblent).
Autrement dit, créer des méthodes auxiliaires partout où cela est possible dans votre code.
Pour ce faire, utiliser la fonction extract method d'Eclipse (menu refactor) par exemple

PARTIE 6 : Visibilités des méthodes

Exercice 16:

Générer la javadoc du projet Tamagoshi

Une fois avec la visibilé public dans un dossier doc_public
Et une fois avec la visibilé private dans un dossier doc_private

Il doit y avoir un minimum de chose dans la doc public (juste de quoi pouvoir utiliser les classes, notamment le jeu)
Passer donc le maximum de méthodes en private.
A l'avenir réfléchissez bien à la visibilité des méthodes que vous écrivez...

PARTIE 7 : Javadoc du projet

Exercice 17:

Ecrivez la javadoc pour chaque classe de votre projet. Pour savoir quoi écrire pour vos classes, attributs et méthodes, n'hésitez pas à vous inspirez la javadoc du JDK.

Exercice 18:

Générez à nouveau la javadoc du projet pour vérifier qu'elle ne possède pas de trou, même pour une visibilité privée.

PARTIE 8 : modularisation du projet

Exercice 19:

Si ce n'est pas déjà fait, transformer votre projet pour qu'il utilise un JDK > 11, puis créez le fichier module-info.java

Exercice 20:

Générez un exécutable portable grâce à la commande jlink. Créez un fichier contenant la commande correspondante et commitez le.

PARTIE 9 : linting du projet

Exercice 21:

Ajoutez le plugin sonar lint depuis le market place d'Eclipse, puis de faire le plus de correction proposées.

Exercice 22:

Dans les IDE, il est possible de définir son propre style : essayez sous Eclipse en allant dans les préférences -> Java -> code style -> formatter.

PARTIE 10 : finalisation de la V1 du projet

Exercice 23:

Choisissez une licence libre et rajoutez la à votre projet. Par exemple, en utilisant ce plugin pour Eclipse

Exercice 24:

Votre dépôt ne doit pas être en visibilité public. En revanche, partagez le avec moi en me mettant maintainer : je recevrai une notification de partage et pourrai y accéder.