🎓 Projet Fil Rouge : Architecture & Qualité Logicielle

1. Le Concept

L’objectif de ce projet est de transformer une idĂ©e fonctionnelle en une application robuste, maintenable et Ă©volutive. Contrairement aux projets scolaires classiques oĂą seul le rĂ©sultat compte, ici, c’est la structure interne qui prime.

Vous partirez de votre prototype initial (le “brouillon” fonctionnel) pour construire une architecture logicielle professionnelle respectant les standards de l’industrie : MVC, SOLID et Design Patterns.

2. Le Sujet (Rappel)

Vous continuez le développement sur le thème choisi en début de formation (RPG, Gestion Sportive, E-Commerce, Utilitaire, etc.).

Votre application doit rĂ©pondre Ă  des cas d’usage complexes nĂ©cessitant de la Logique MĂ©tier (calculs, règles de gestion, changements d’Ă©tats) et ne pas se contenter d’afficher des donnĂ©es statiques.

3. La Roadmap de DĂ©veloppement

Voici les Ă©tapes obligatoires pour valider le module.

📅 Étape 1 : Structuration (Architecture MVC)

Objectif : Sortir du “Tout dans le Main” et organiser le code.

  • Mise en place du DĂ©pĂ´t : Initialisation d’un projet Git propre.

  • SĂ©paration des Couches : Application du pattern MVC (Modèle – Vue – ContrĂ´leur).

    • model : Contient les donnĂ©es et la logique mĂ©tier pure (Aucun System.out.println ici !).

    • view : Gère les interactions avec l’utilisateur (Console ou Interface Graphique simple).

    • controller : Orchestre les appels entre la vue et le modèle.

📅 Étape 2 : Flexibilité (Principes SOLID)

Objectif : Rendre le code modulaire pour faciliter les Ă©volutions futures.

  • SRP (Single Responsibility) : Chaque classe doit avoir une responsabilitĂ© unique. Exemple : Une classe Player ne doit pas gĂ©rer sa propre sauvegarde en base de donnĂ©es.

  • OCP (Open/Closed) : L’ajout d’une nouvelle fonctionnalitĂ© (ex: un nouveau type d’ennemi, une nouvelle taxe) doit se faire par extension (nouvelle classe) et non par modification du code existant (pas de multiplication des if/else).

  • DIP (Dependency Inversion) : Les modules de haut niveau ne doivent pas dĂ©pendre des implĂ©mentations concrètes. Utilisez des Interfaces pour dĂ©coupler vos services.

📅 Étape 3 : Robustesse (Design Patterns)

Objectif : Résoudre des problèmes récurrents avec des solutions élégantes.

Vous devez implémenter et justifier au moins 2 Design Patterns parmi les catégories suivantes :

  • CrĂ©ationnels : Factory Method, Builder, Singleton. (Utiles pour la crĂ©ation d’objets complexes).

  • Comportementaux : Strategy, Observer, Command. (Utiles pour gĂ©rer des algorithmes interchangeables ou des Ă©vĂ©nements).

  • Structurels : Adapter, Decorator, Composite.

4. Les Livrables Attendus (Mise Ă  jour)

À la fin du délai imparti (J+7 après la fin de la formation), vous devrez fournir :

  1. đź“‚ Le Code Source (/src) :

    • Propre, commentĂ© et indentĂ©.

    • Respectant les conventions de nommage Java.

  2. đź“‚ L’Historique (/legacy) :

    • Votre Notebook original (le prototype) pour permettre la comparaison “Avant/Après”.

  3. đź“„ Le Rapport Technique (ARCHITECTURE.md) :

    • Architecture : Diagramme de Classes UML final (gĂ©nĂ©rĂ© via PlantUML).

    • Design Patterns : Justification des choix (Pourquoi ce pattern ici ?).

    • MĂ©thodologie & Transparence IA : Une section obligatoire dĂ©taillant votre dĂ©marche.

      • Logique de travail : Comment avez-vous procĂ©dĂ© pour passer du Notebook au code propre ? (Ex: “J’ai d’abord isolĂ© le Modèle, puis crĂ©Ă© les Interfaces…”).

      • Outils IA utilisĂ©s : Quels outils avez-vous sollicitĂ©s ? (ChatGPT, GitHub Copilot, Claude, etc.).

      • Usage et Critique : Comment l’IA vous a-t-elle aidĂ© ? (GĂ©nĂ©ration de code rĂ©pĂ©titif ? DĂ©bogage ? Suggestion de structure ?). Donnez un exemple concret oĂą l’IA vous a proposĂ© une solution que vous avez dĂ» refuser ou modifier car elle violait les principes SOLID ou MVC.

5. Grille d’Évaluation (Mise Ă  jour)

La notation valorise autant le résultat technique que le recul critique sur vos outils et votre méthode.

Critère Poids Ce qui est évalué
Architecture MVC 20% Séparation stricte des responsabilités. Le modèle est-il indépendant de la vue ?
Respect de SOLID 25% Usage pertinent des interfaces (DIP), découpage des classes (SRP), extensibilité (OCP).
Design Patterns 20% Implémentation correcte de 2 patterns majeurs. Sont-ils utiles ou forcés ?
Qualité du Code 15% Nommage, absence de code mort, convention Java, propreté du Git.
MĂ©thodologie & Critique IA 20% Transparence et dĂ©marche. L’Ă©tudiant est-il capable d’expliquer comment il a construit sa solution et de critiquer le code fourni par l’IA ? A-t-il utilisĂ© l’IA comme un assistant (copilote) ou comme une bĂ©quille (copier-coller aveugle) ?

Bon courage ! N’oubliez pas : un bon dĂ©veloppeur n’est pas celui qui Ă©crit le plus de code, mais celui qui en Ă©crit le moins pour faire le plus de choses. 🚀