4.8 KiB
Rapport d'équipe - Projet Webzine
Équipe 1 Formation : Développement .NET niveau 1 / Dr1-P4 Date : Mars 2026
Problèmes techniques
Ce chapitre liste les difficultés rencontrées pendant le projet, ce qui n'a pas fonctionné comme prévu, et ce que nous ferions différemment.
Côté développement
La correction des erreurs des jalons
La code review du jalon 1 et 2s ont mis en évidence un volume d'erreurs accumulées pendant le développement: HTML invalide, controllers inutiles, fautes dans les vues, incohérences dans les noms de routes. Joséphine a créé une branche TODO_erreurs pour tout recenser, et nous avons passé toute la première journée du jalon 2 à corriger ça avant de pouvoir avancer sur de nouvelles fonctionnalités. Pour le jalon 3, la correction a pris plus de temps et a été faite en parallèle du développement des autres features.
Nous avons pourtant passer en revue chaque PR. Ces corrections ont permis d'améliorer ce processus et de monter en compétences.
Passer des factories aux repositories
C'est probablement le chantier le plus difficile du jalon 2. Au jalon 1, les données étaient instanciées directement dans les controllers via des classes factory. Ça fonctionnait pour afficher les vues, mais tout était couplé : il était impossible de connecter une vraie base de données sans tout réécrire.
La migration vers des repositories a impliqué plusieurs changements simultanés :
- extraire la logique de données,
- créer des interfaces,
- reconfigurer
Program.cspour gérer l'injection de dépendances.
Cette dernière partie a été la plus difficile à appréhender - les cycles de vie des services (Singleton, Scoped, Transient) et la façon dont ASP.NET Core résout les dépendances à l'exécution n'étaient pas évidents au départ.
La coexistence de deux environnements (SQLite en dev, PostgreSQL en prod) a ajouté une couche de complexité supplémentaire : il fallait deux implémentations concrètes des mêmes interfaces et conditionner leur enregistrement dans Program.cs selon l'environnement.
Le seeder Spotify
En jalon 3, Loïc a travaillé sur un seeder pour alimenter la base avec des données réelles issues de l'API Spotify.
L'API Spotify ne renvoie pas toutes les informations en un seul appel. Pour récupérer des artistes avec leurs albums et leurs titres, il faut enchaîner plusieurs endpoints, chacun avec sa propre structure JSON. De nombreux DTOs ont été nécessaires pour désérialiser correctement les réponses avant de les mapper vers les entités du domaine. En plus de ça, l'API pagine ses résultats, ce qui impliquait de gérer les appels successifs et de dédoublonner les données avant insertion.
Nous avions mal estimé cette tâche. Une exploration rapide de l'API en amont aurait donné une bien meilleure idée de ce qu'elle impliquait réellement.
Les Pull Requests
À partir du jalon 2, nous avons formalisé l'utilisation des branches et des Pull Requests, ce qui a amélioré la qualité du code. Mais cela a aussi créé des blocages : les reviews prenaient beaucoup de temps, plusieurs PR restaient ouvertes en parallèle, et Joséphine se retrouvait souvent à devoir les débloquer en plus de sa charge de gestion de projet.
Nous n'avions pas défini de règles sur la taille des PR ni sur les délais de review. Des PR trop volumineuses sont plus longues à relire, génèrent davantage de conflits, et finissent par ralentir tout le monde. C'est quelque chose à fixer dès le début d'un projet.
Néanmoins, toute l'équipe est montée en compétences sur la gestion des conflits (on parle bien de git) et des merge/rebase.
La logique métier dans les controller
Lors du daily du 1er avril (jalon 3), nous avons réalisé que la logique du dashboard avait été placée dans le ViewModel plutôt que dans la couche métier. Il a fallu refactoriser : remplacer le ViewModel par un DTO et déplacer la logique au bon endroit.
Ce type d'erreur arrive quand les responsabilités des différentes couches ne sont pas clairement définies et partagées au sein de l'équipe. Chacun avait sa propre interprétation, et cela s'est reflété dans le code.
Côté ops
La CI/CD qui saturait Gitea
La CI/CD mise en place par Clément et Mathys teste tous les endpoints de l'application et mesure leurs temps d'exécution. C'est un choix pertinent pour surveiller les performances, mais lors de sa mise en place initiale, chaque exécution du pipeline rendait Gitea inutilisable pendant une dizaine de secondes.
Pour une équipe dont tout le code et tous les tickets reposent sur cette instance, c'était bloquant. Le problème venait du fait que les dépendances étaient retéléchargées à chaque run. Les mettre en cache a résolu le problème.