Prototype pour le calcul de moyenne d’un groupe d’étudiants
À partir d’une classe monolithe qui calcule la moyenne d’un groupe d’étudiantes et d’étudiants, je me donne le défi de transformer ce monolithe en solution logicielle professionnelle pour les services du registraire dans un cégep ou une université. Tout en faisant ça, je vais partager chaque étape de développement logiciel ici sur mon blogue mais aussi sur le wiki de GitHub pour le projet.
En observant ce projet évoluer, tu comprendras comment passer d’un simple exercice à une véritable application. On va progresser ensemble à travers les étapes essentielles : clarifier exactement ce dont on a besoin, concevoir une architecture pensée pour la maintenance, séparer les responsabilités pour garder le code propre, valider les données entrantes, gérer les erreurs de façon élégante, ajouter des tests pour assurer la fiabilité, et documenter le tout pour que d’autres puissent le reprendre. C’est une invitation à découvrir comment les développeuses et développeurs professionnels structurent leur travail pour créer des solutions robustes et évolutives. Le dépôt GitHub et le wiki du projet te permettront de suivre chaque phase en détail et de t’en inspirer pour tes propres apprentissages.
Une des premières choses que tu vas voir, c’est la différence entre un petit prototype de cours et une application vraiment utilisable par des personnes du registraire. Un prototype, c’est souvent du code écrit vite pour vérifier une idée : ça marche « juste assez » pour une démo en classe, mais ce n’est pas pensé pour être utilisé tous les jours par quelqu’un qui n’a pas écrit le code. Une application utilisable, au contraire, doit être claire, fiable, prévisible, et facile à faire évoluer. Par exemple, un prototype peut supposer que toutes les notes entrées sont valides et qu’il n’y a jamais d’erreurs; une vraie application doit gérer les oublis, les fautes de frappe, les cas particuliers, les changements de règles et les besoins d’audit.
Les services du registraire ont des besoins très concrets auxquels ton code doit répondre. Ce sont des personnes qui doivent gérer des centaines ou des milliers de dossiers : calculer des moyennes, vérifier des préalables, appliquer des règles de progression, produire des relevés officiels, respecter des échéanciers, et pouvoir justifier chaque changement fait dans un dossier étudiant. Elles n’ont pas le temps de deviner comment fonctionne le système ou de redémarrer l’application chaque fois qu’un message d’erreur obscur apparaît. Ça veut dire que notre solution devra offrir des messages clairs, des workflows logiques, une bonne performance et surtout une grande fiabilité des données.
Pour y arriver, on va insister beaucoup sur la séparation des responsabilités. Au lieu d’avoir une seule grosse classe qui fait tout (lire les données, calculer les moyennes, afficher les résultats, gérer les erreurs, parler à la base de données, etc.), on va découper le système en morceaux spécialisés. Par exemple, tu pourras avoir une partie de ton code qui ne s’occupe que des règles de calcul, une autre qui gère la validation des données, une qui s’occupe de l’accès aux fichiers ou à la base de données, et une autre encore qui gère l’interface avec l’utilisateur ou l’utilisatrice. Ça rend le code plus facile à comprendre, à tester, à corriger et à faire évoluer.
La qualité et la validation des données vont aussi jouer un rôle central. Dans un devoir de programmation, on se permet souvent de supposer que les données sont « propres ». Dans un contexte réel, c’est rarement le cas. Tu devras donc vérifier, par exemple, que les notes sont dans un intervalle acceptable, que les identifiants d’étudiants existent vraiment, que les cours ne sont pas en double, que les champs obligatoires ne sont pas vides, et que les formats (dates, nombres, codes de cours) sont cohérents. On va voir comment centraliser cette validation pour éviter de répéter le même code partout, et comment réagir lorsque quelque chose cloche sans faire planter l’application au complet.
Les cas d’erreur sont d’ailleurs une partie essentielle du projet. Au lieu de simplement « crasher » quand quelque chose ne fonctionne pas, on va apprendre à anticiper les problèmes : fichier manquant, données corrompues, connexion à la base de données interrompue, règles métier qui ne peuvent pas être appliquées, etc. Tu vas voir comment signaler ces situations de façon claire, comment les enregistrer pour pouvoir les diagnostiquer plus tard, et comment offrir des pistes de solution à la personne qui utilise le système, plutôt que de la laisser seule devant un message d’erreur incompréhensible.
Les tests vont nous servir de filet de sécurité tout au long de l’évolution du projet. On ne va pas se contenter de « cliquer un peu partout » pour voir si ça marche; on va écrire des tests automatisés qui vérifient que les règles de calcul fonctionnent comme prévu, que la validation des données réagit comme il faut aux mauvaises entrées, et que les cas limites sont pris en compte. Tu verras la différence entre tester à la main et avoir une suite de tests que tu peux relancer à chaque changement, et tu comprendras pourquoi les développeuses et développeurs professionnels misent tellement sur cette pratique.
La documentation va aussi faire partie du parcours, mais pas seulement sous la forme d’un gros document ennuyeux à la fin. On va documenter au fur et à mesure : en commentant le code avec parcimonie et pertinence, en écrivant des fichiers README clairs, en ajoutant des exemples d’utilisation, et en expliquant les décisions importantes dans le wiki du projet. L’objectif, c’est que quelqu’un qui arrive plus tard (y compris toi-même dans quelques mois) puisse comprendre rapidement ce que fait le système et pourquoi il a été conçu de cette façon.
Tout au long du projet, on utilisera GitHub comme outil pour suivre l’évolution du code. Tu pourras voir comment structurer les commits, écrire des messages de commit utiles, créer des branches pour expérimenter une idée, et revenir en arrière quand quelque chose ne fonctionne pas. Le dépôt GitHub te servira d’exemple vivant de bonnes pratiques de contrôle de version adaptées à un contexte pédagogique.
Finalement, on va parler de choix de conception et on va les rendre explicites. Plutôt que de dire simplement « on fait ça comme ça », chaque décision importante sera justifiée : pourquoi tel design et pas un autre, pourquoi tel patron de conception, pourquoi telle structure de données, pourquoi tel style de message d’erreur. Le projet va évoluer progressivement : on va partir de la petite classe monolithe, ajouter des fonctionnalités, réorganiser le code quand il devient trop chargé, introduire de nouveaux concepts au besoin, et parfois même revenir sur des décisions pour les améliorer. Tu pourras suivre cette évolution pas à pas, comprendre la logique derrière chaque changement, et t’en servir pour développer ta propre façon de penser comme une ou un professionnel du logiciel.
De l’exercice à l’application professionnelle
Ce projet va te montrer, étape par étape, comment transformer une simple classe avec une fonction main() en une solution logicielle plus complète, adaptée aux besoins réels des services du registraire. Chaque phase du développement sera expliquée ici sur le blogue et dans le wiki GitHub du projet, pour que tu puisses suivre la progression et t’en inspirer dans tes propres apprentissages.
- Clarifier les besoins
- Définir les données et les règles de calcul
- Concevoir la solution
- Améliorer le prototype
- Ajouter des tests
- Gérer les erreurs
- Documenter le projet
Cette documentation et ce code serviront pour la rédaction du manuscrit D’Étudiante à professionnelle TI : Du code académique aux solutions logicielles professionnelles.
Bonne nouvelle ! 🎉 Des exemples sont maintenant disponibles dans un dépôt GitHub pour vous aider dans votre apprentissage. N’hésitez pas à consulter le wiki pour plus de détails. Bonne exploration !