M-API: Symfony pour le long terme

Nous avons développé et maintenu l’API de données produits pour Migros pendant 10 ans, en adoptant pleinement le développement agile. Nous avons mis en ligne la première version en seulement six mois, puis continué à ajouter des fonctionnalités et à nous adapter aux exigences changeantes et aux systèmes tiers.

Après 10 ans, Migros a créé une équipe interne pour reprendre le développement en interne. Durant les deux dernières années de notre collaboration, nos développeur·euse·s ont travaillé étroitement avec l’équipe interne en pleine croissance, transférant progressivement le savoir-faire et les responsabilités. En 2024, Migros avait entièrement repris le projet.

L’application est un système central permettant un accès en temps réel à toutes les données produits. Elle collecte des informations provenant d’environ 30 applications métiers, allant de systèmes SAP et d’API REST à des fichiers CSV. Les données collectées sont filtrées, préparées et stockées dans un cluster Elasticsearch. Les applications peuvent soit interroger les données via des appels REST en temps réel, soit s’abonner à un message bus global pour synchroniser les mises à jour.

Stratégie

Dès le début, nous avions une vision architecturale claire pour l’API. Nous avons réussi à garder le code moderne et maintenable grâce à des refactorings réguliers, en adoptant de bonnes pratiques:

• Tests unitaires et fonctionnels
• PHPStan: Analyseur statique pour détecter les bugs potentiels
• Code typé (introduit avec PHP 7) pour une meilleure robustesse
• Rector: Refactorisation automatique pour moderniser le code
• PHP-CS-Fixer: Formatage automatique du style de code

Un moment clé fut lorsque le PO nous a encouragé à choisir une refactorisation approfondie plutôt qu’une solution rapide, garantissant ainsi la maintenabilité du projet à long terme.

Outils

Explorons maintenant quelques outils que nous avons utilisé pour maintenir cette application dans cet environnement en évolution rapide.

Testing

Le code hérité est simplement du code sans tests.

Nous avons mis en place des tests dès le début:

• PHPUnit pour les tests unitaires et fonctionnels
• Behat pour les tests end-to-end
• PHPStan pour l’analyse statique et la détection d’erreurs potentielles

En outre, nous avons utilisé l'analyseur statique PHPstan. Cet outil combine le code réel avec les commentaires de la documentation et repère des catégories entières d'erreurs potentielles ou d'erreurs d'exécution avant que le code ne soit exécuté. Cet outil pousse les développeurs à écrire un code plus propre et des commentaires de documentation de meilleure qualité. En se plaignant des constructions inutiles, il aide à simplifier le code ou permet au développeur·euse de repérer les erreurs de logique dans le code.

Documentation

Nous avons documenté le projet à plusieurs niveaux:

• Un wiki collaboratif
• Une documentation API interactive
• Des commentaires documentés dans le code
• Un ADR (Architecture Decision Record)

Nous avons également utilisé un fixeur automatique de style de code pour garantir la cohérence et réduire les distractions liées au formatage. L'outil permettrait de personnaliser les règles à appliquer ou même d'ajouter des règles personnalisées. Nous nous sommes mis d'accord sur le jeu de règles par défaut de Symfony. Nous nous soucions moins du style exact, mais tenons à ce que le style soit cohérent.