Travail à réaliser

1. Contexte

Le projet Risk est composé de 7 modules, chacun développé par une équipe différente. Ce sont en réalité des projets indépendants, contenants différents types de mauvaises odeurs, que vous allez détecter et ensuite supprimer. Les modules sont plus au moins aboutis et utilisent des bibliothèques différentes.

L’exécution de certains modules demande un JDK contenant le module JavaFX.

2. Évaluation de la suite de tests

La première étape consiste à déterminer les parties du code qui ne sont pas bien testées. Comme vous allez restructurer le code, vous aurez besoin d’un filet de sécurité capable de détecter l’introduction d’erreurs. Les tests unitaires joueront ce rôle.

Vous pouvez utiliser le plug-in de couverture de code de IntelliJ, ou alors le plugin Maven JaCoCo.

L’analyse de mutation est une alternative à la couverture de code, qui permet aussi de déterminer les parties du code qui sont mal testées. Vous pouvez utiliser le plug-in Maven Pitest pour le faire.

3. La chasse aux mauvaises odeurs

La deuxième étape consiste à scruter le code source à la recherche de mauvaises odeurs. Vous pouvez effectuer cette tâche manuellement, en utilisant des outils d’analyse statique, ou les deux.

Voici quelques exemples d’outils de détection de mauvaises odeurs pour Java, disposant d’un plugin Maven :

  1. PMD

  2. Checkstyle

  3. Spotbugs

Nous avons déjà configuré les plugins de ces outils dans le projet. Chacun de ces plugins génère un rapport différent pour les différents modules du projet. Pour générer ces rapports, ouvrez un terminal et placez vous à la racine du projet. Ensuite, exécutez la commande suivante:

mvn compile site

Les rapports seront générés à l’intérieur do dossier target/site de chacun des modules et ensuite agrégés dans le dossier target/site du module parent. Vous pouvez modifier les règles utilisées pour mieux correspondre à vos besoins. Elles sont définies à l’intérieur du module build-tools.

Ces outils d’analyse statique de code sont très utiles pour vous indiquer les mauvaises odeurs, mais :

  • ce ne sont pas la seule source de vérité, vous pouvez trouver des mauvaises odeurs en regardant le code source, tout simplement.

  • Ils sont souvent très configurables : vous pouvez commencer par ajouter à la configuration un petit ensemble de règles que vous jugez importantes.

L’éditeur IntelliJ propose un plugin appelé SonarQube IDE, 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:

  1. Aller dans Préférences  Plugins  SonarQube puis cliquer sur Installer.

  2. L’installer manuellement : https://plugins.jetbrains.com/plugin/7973-sonarqube-for-ide

4. Mauvaises odeurs

Dans ce projet, nous allons nous limiter aux mauvaises odeurs énumérées ci-dessous. Bien évidemment, vous pouvez supprimer d’autres mauvaises odeurs, mais elles ne seront pas considérées dans l’évaluation.

Code mort

Extraits de code, variables, paramètres, méthodes ou classes qui ne sont jamais exécutés.

Code dupliqué

Deux ou plusieurs extraits de code ayant un comportement similaire.

Classes trop grandes

Ici, nous allons considérer comme "trop grandes" les classes avec plus de 300 lignes de code.

God Classes

Nous allons nous baser sur les métriques de PMD pour identifier les classes dieu, à savoir WMC >= 47 et ATFD > 5 et TCC < 1/3. Où WMC signifie « Weighted Methods Count » (nombre de méthodes pondérées) ou « Weighted Method per Class » (méthode pondérée par classe). La métrique WMC est définie comme la somme des complexités de toutes les méthodes déclarées dans une classe. Cette métrique est un bon indicateur de l’effort nécessaire pour maintenir et développer une classe particulière.

ATFD signifie « Access to Foreign Data » (accès aux données externes). Cette métrique représente le nombre de classes externes à partir desquelles une classe donnée accède à des attributs, directement ou via des méthodes d’accès.

Enfin, TCC signifie Tight Class Cohesion (cohésion étroite des classes). Le TCC est le nombre relatif de méthodes directement connectées via des accès aux attributs.

Méthodes trop longues

Ici, nous allons considérer comme "trop longues" les méthodes avec plus de 40 lignes de code.

Trop de paramètres

Ici, nous allons considérer comme ayant "trop de paramètres" les méthodes qui en ont plus de 5.

Trop de conditionnels imbriqués

Les méthodes avec plus de 3 niveaux d’imbrication.

5. Création de tickets

Lors que vous aurez trouvé une mauvaise odeur ou que vous aurez trouvé une partie du code qui doit être mieux testée, c’est le moment d’organiser votre travail.

Pour chaque mauvaise odeur à éliminer et test à réaliser :

  1. Ouvrez un ticket dans votre projet GitLab (sur l’interface en ligne de GitLab, section Tickets). Vous y détaillerez les points suivants :

    • Un bref résumé du problème lié au ticket.

    • Comment la solution au ticket doit être mise en œuvre ?

  2. Associez un membre du groupe à la résolution du ticket, via l’interface de GitLab. Cette personne sera chargée de résoudre le ticket.

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.

  1. Écrivez le code qui résout le ticket.

Faites attention à la régression ! Toute modification ne doit pas "casser" du code qui marchait auparavant (les autres tests unitaires doivent passer).

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

  2. 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 à suivre la norme Conventional Commits.

  3. 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 : Automatic issue closing and linking

Le code du projet est là pour vous fournir une base de code. Vous êtes libre de modifier l’implémentation comme vous l’entendez. Mais attention, vous devrez motiver tous vos changements dans vos différents tickets/commits !!!

Avant de valider vos changements, assurez-vous que la production (le build) termine correctement.

6. Écriture de tests unitaires

Écrivez les test unitaires en JUnit 5 (Jupiter). Si vous souhaitez, vous pouvez utiliser des outils de génération de tests unitaires, comme :

  1. Symflower

  2. Evosuite (Attention, il demande un JDK ≤ 9)

  3. Randoop

  4. Diffblue (Limité à 100 tests par semaine)

  5. Squaretest (Limité à 30 jours)

  6. Qodo

Vous pouvez aussi faire appel directement à un grand modèle de langage, comme GitHub Copilot, Llama, Gemini ou ChatGPT.

L’objectif est d’améliorer la qualité des tests, ce que vous pouvez faire en ajoutant des nouveaux tests et aussi en modifiant les tests unitaires existants.
Ajouter beaucoup de tests unitaires qui n’améliorent pas la qualité des tests est considéré comme une mauvaise odeur.

7. Refactorings

Pendant cette étape vous allez utiliser les opérations de refactoring pour supprimer les mauvaises odeurs. Référez-vous au cours sur les refactorings pour trouver des solutions correspondantes aux mauvaises odeurs.

Bien que IntelliJ propose un ensemble important d’opérations de refactoring, cet ensemble n’est pas complet. Vous pouvez réaliser des refactorings manuellement, en faisant attentions aux préconditions de chaque opération.

8. Journal des modifications

Pendant tout le déroulement du projet, vous devez maintenir le fichier CHANGELOG.adoc, qui contient le journal des modifications du projet.

Ce fichier doit respecter le format Keep a Changelog.

9. Consolidation

Dans cette étape optionnelle, vous allez consolider le code.

  1. Le but du module risk-core est de contenir les classes et interfaces communes aux sept autres modules.

  2. Par exemple, les modules possèdent une classe appelée Card : trouvez ce que ces classes ont en commun et déplacez ces propriétés à une super-classe commune, que vous placerez dans le nouveau module.

  3. Faites la même chose avec les autres classes communes aux modules.