La parole est aux speakers : Mathieu Ferment
Jusqu’à l’AFUP Day 2021, retrouvez nos interviews de speakers pour mieux comprendre leur parcours et le sujet qu’ils ou elles aborderont lors de leur conférence !
Au sein de Prestashop, vous avez choisi le modèle d’architecture CQRS pour votre refonte, pourquoi ce modèle en particulier et pas un autre ? Avez-vous évalué d’autres modèles pour vous conforter dans votre choix ?
PrestaShop est confronté à un challenge de taille: nous migrons l’architecture vers Symfony, ce qui implique de changer énormément de choses de manière non rétrocompatible, alors que c’est un enjeu majeur pour un projet open source. La migration introduit des Breaking Changes, qui doivent être gérés par tous les utilisateurs du projet qui s’appuient dessus : modules, thèmes, intégrateurs…
Nous savons que cela recommencera. PrestaShop aura encore besoin d’évoluer, et aura encore besoin de modifier des composants importants de son architecture après cette migration. Comment faire pour avancer sans systématiquement introduire d’importants Breaking Changes, mal accueillis par la communauté?
CQRS nous a apporté une solution élégante à ce challenge : il isole le domaine de l’application, ce qui permet de faire évoluer le domaine tout en gardant une promesse de compatibilité sur les commandes et les queries. Le domaine isolé peut être retravaillé sereinement : tant que le contrat des Commandes et Queries est respecté, les modules, thèmes, intégrateurs qui s’appuient dessus ne subissent aucun Breaking Change.
Et au passage les Commandes et Queries font office de SDK pour les utilisateurs.
C’est donc amusant : nous n’avons pas du tout choisi CQRS pour les raisons habituelles (introduire de l’asynchrone, séparer le modèle de données de lecture et le modèle de données d’écriture…) mais pour sa capacité à isoler une partie de la codebase derrière une interface claire et figée. Nous avons choisi CQRS pour ses bénéfices sur l’architecture, pas ses bénéfices sur la base de données.
Chez Prestashop, vous avez décidé de créer des ADR pour cadrer les développements à venir, et partager les intentions à la communauté. Récemment une discussion s’est ouverte pour donner encore plus de rigueur au système en le limitant dans le temps. Peux-tu nous en dire plus ?
Nous sommes convaincus que les ADR sont importants pour nous et la communauté afin de laisser une trace des décisions prises. Par contre nous n’avons pas encore trouvé un moyen efficace de les porter jusqu’à un vote. Un ADR chez PrestaShop, c’est une sorte de RFC avec à la clé une décision collégiale : il faut que chaque mainteneur prenne de son temps pour le consulter, donner son opinion, et finalement voter. Or le temps est ce qui manque le plus à un mainteneur PrestaShop ! Il y a tant à faire, nous avons du mal à réunir le temps de chacun sur un sujet commun.
La discussion que j’ai ouverte va finalement être close car après discussion avec les autres mainteneurs, nous pensons que les inconvénients d’une limite de temps sont plus grands que les bénéfices. Nous allons essayer un autre mode de fonctionnement où chaque ADR est assigné à un mainteneur qui doit le “porter” comme un projet, c’est-à-dire relancer ses pairs mainteneurs, pousser la réflexion, créer des réunions si nécessaire… on ne se limite finalement pas dans le temps ; par contre, quelqu’un est chargé de pousser le sujet pour qu’il ne stagne pas.
Comment s’est adapté Prestashop en tant qu’éditeur pour s’organiser en cette période de COVID ?
Nous avons eu de la chance : PrestaShop avait déjà adopté le télétravail bien avant le Covid, particulièrement dans les équipes techniques. Dans l’équipe Core, qui travaille sur le projet open source, deux tiers des effectifs étaient déjà des télétravailleurs à temps complet, nous n’avons eu aucune difficulté à sauter le pas. De toute façon travailler sur un projet open source impose de travailler avec des gens dans le monde entier, avec des fuseaux horaires variés, avec une culture de toujours documenter et écrire le fruit des discussions.
Les équipes de l’entreprise qui ne l’avaient pas encore expérimenté ont pu s’appuyer sur l’expérience des autres: tout le monde s’est mis à Slack, Miro, Meet et Zoom, et ça s’est fait très naturellement.