Gérer les décisions d'architectures dans les projets

On me demande régulièrement comment sont gérées les décisions (et le suivi) d’architectures que l’on est amené à prendre dans les projets sur lesquels j’interviens. Dans la plupart des cas, cela va se dérouler en deux phases: la communication et le suivi.

La première étape que j’ai nommée “la communication” se fait en deux temps. Elle commence tout d’abord par une discussion d’équipe (ou des acteurs concernés) dans laquelle sont évoquées la ou les problématiques qui sont rencontrées. Cette discussion (réalisée de manière synchrone ou asynchrone) permet de s’aligner sur le problème rencontré, d’échanger sur les solutions qui peuvent être envisagées. Une fois ce travail réalisé, l’équipe pourra se mettre d’accord sur la solution finale à adopter.

Il est important de noter que l’ensemble des échanges doivent être tracés au sein d’un ADR (Architecture Decision Record) afin de conserver l’historique des échanges, discussions, contexte du problème, solutions envisagées et d’expliquer comment l’équipe (à cette date) en est arrivée à la solution convenue.

Une fois tout le travail de recherche et de concertation réalisé, l’équipe va alors pouvoir commencer à implémenter la solution finale. Se pose alors la question du suivi. Comment suivre et faire respecter la décision d’architecture qui a été prise ?

Au sein d’une équipe qui travaille avec de la revue de code, la première idée qui nous vient naturellement en tête est que l’équipe devra alors “faire attention” lors de la relecture du code. C’est une première étape, mais elle a l’inconvénient de reposer uniquement sur l’humain. Or, s’assurer du respect de toutes les règles qui ont été établies peut-être un véritable défi sur des projets d’envergures.

C’est pour cela que nous tentons (avec les équipes) d’automatiser au maximum la vérification des règles mises en place. Et pour cela, un certain nombre d’outils sont disponibles en fonctions des besoins. Les principaux étant:

• Deptrac: un outil qui va vérifier les dépendances et les interactions entre les différentes couches d’un projet pour s’assurer du respect des règles de couplages. Dans le cadre d’une Clean Architecture, nous pouvons vérifier les dépendances entre les couches Domain, Application, Infrastructure et Presentation ,
• PHP CS Fixer: pour tout ce qui est vérification (et correction automatique) des règles liées aux conventions de nommages du code,
• PHPStan: principalement conçu pour analyser le code PHP et détecter erreurs et problèmes dans le code, nous l’utilisons pour écrire des règles personnalisées pour vérifier des règles d’architectures qui ne peuvent être réalisées par les outils précédents.