Projet final et méthodologie

Projet final et méthodologie

1. Projet fil rouge : gestionnaire de dépenses

   Le projet porte sur tout le cours. Il est volontairement modeste en dépendances — seule la bibliothèque standard — et Livrable avec des tests.

   Le sujet

   Un gestionnaire de dépenses personnelles : ajouter des dépenses, les classer par catégorie, produire un rapport mensuel, et persister les données dans un fichier JSON.

   Contraintes

   1. Un fichier depenses.py pour le modèle et les règles métier, un fichier test_depenses.py pour les tests, un point d'entrée main.py.
   2. Aucune dépendance externe : uniquement la bibliothèque standard.
   3. Chaque fonction doit être courte, testée, et documentée par une docstring.
   4. Les entrées utilisateur invalides produisent un message clair, jamais une trace Python brute.
   5. Les données sont écrites avec json.dump et relues au démarrage.
   6. Au moins 12 tests couvrent le cas nominal, les cas limites et les erreurs.

   Structure attendue

   gestionnaire/
   ├── main.py
   ├── depenses.py
   └── test_depenses.py

   Conduite du projet

   Étape	Livrable	Critère de fin
   1. Modèle de données	classe Depense	tests unitaires au vert
   2. Métier	ajout, filtrage, rapport	tests unitaires au vert
   3. Persistance	lecture/écriture JSON	aller-retour vérifié
   4. Interface	menu en console	parcours complet testé
   5. Qualité	PEP 8, docstrings	relecture sans commentaire

   On ne passe à l'étape suivante que quand la précédente est vérifiée. C'est ce qui distingue un projet qui avance d'un projet qui s'épuise.

2. Méthodologie et bonnes pratiques

   Les règles qui font la différence

   1. Lisibilité avant astuce. Si une expression demande une seconde de réflexion, elle est trop compliquée.
   2. Le code lu plus souvent qu'il n'est écrit. Nommer clairement vaut mieux que commenter.
   3. Une fonction, une responsabilité. Une fonction qui fait trois choses ne se teste pas.
   4. La bibliothèque standard d'abord. Écrire soi-même ce qu'elle fournit est une perte de temps.
   5. Gérer l'erreur là où elle est prévisible. Pas de except silencieux.

   PEP 8, l'essentiel

   • quatre espaces d'indentation, jamais des tabulations
   • 79 à 99 caractères par ligne
   • deux lignes vides entre les fonctions de haut niveau
   • snake_case pour les fonctions et variables, PascalCase pour les classes

   Outils utiles

   • python -m venv et pip pour l'environnement et les dépendances
   • unittest pour les tests (inclus)
   • pip install ruff : vérificateur de style et de bogues, très rapide
   • pip install black : formatage automatique

   Un projet sans requirements.txt n'est pas reproductible : la liste des dépendances fait partie du code.

   Pour aller plus loin

   1. Données : pandas pour l'analyse, matplotlib pour les graphiques.
   2. Web : Flask (léger) ou Django (complet).
   3. Automatisation : openpyxl pour Excel, requests pour les API.
   4. Tests de style : pytest, alternative moderne à unittest.

3. Ressources et évaluation

   Méthodes d'évaluation

   • Quiz à la fin de chaque module, sur la syntaxe et les concepts.
   • Atelier : un exercice guidé avec livrable.
   • Projet final : évalué sur les tests, la lisibilité et le respect des contraintes.
   • Code review : chaque atelier est relu avec des remarques concrètes.

   Critères d'évaluation du projet

   • fonctionnel : toutes les contraintes sont respectées
   • qualité : tests au vert, code relu, style respecté
   • progressé : étapes livrées dans l'ordre, avec commits identifiables