La parole est aux speaker : Benoit Galati

Jusqu’à l’AFUP Day 2024, retrouvez nos interviews de speakers pour mieux comprendre leur parcours et le sujet qu’ils ou elles aborderont lors de leur conférence !

La conférence

Sensée aider nos choix de développement, l’archi hexagonale peut parfois nous faire poser encore plus de questions. Comment selon toi bien cadrer une équipe de devs pour que tout soit clair pour tout le monde ?

L’architecture hexagonale a l’avantage de la simplicité. Il faut prendre le temps d’expliquer à toute l’équipe les principes de cette dernière et pourquoi on l’implémente. Que tout le monde comprenne les problèmes que l’on cherche à résoudre avec une architecture hexagonale est fondamental. Une fois passé ce rapide tour théorique, place à la pratique où l’on peut proposer d’implémenter une feature sans archi hexagonale dans un 1er temps, puis avec. Tout ça dans le cadre du projet sur lequel on travaille actuellement pour faire d’une pierre 2 coups. Dernier point, il est essentiel de rester proche des équipes afin d’être à l’écoute de toute incompréhension : par exemple via de la code review ou du pair programming. Ou tout simplement pendant les différentes pauses qui rythment la journée.

Penses-tu qu’une bonne personne au poste de « Tech domain designer » est un·e dev ayant une bonne connaissance du métier ou au contraire la personne qui se fait un devoir de poser les bonnes questions sans apporter son point de vue ?

Je n’ai jamais entendu parler d’un tel rôle à vrai dire. Un·e dev doit s’intéresser au domaine dans lequel il évolue, c’est indispensable. Je dirais donc qu’un·e dev doit forcément finir par cultiver une bonne connaissance du métier/domaine de son entreprise grâce à ses questions et sa curiosité. Aussi, apporter son point de vue à la réflexion est toujours source de richesse : elle permet de faire évoluer le point de vue des experts métiers ainsi que des devs. D’ailleurs, l’un des enjeux de DDD est d’arriver à co-construire un modèle riche avec les experts métiers. La bonne implémentation dépend à 50 % de ses compétences techniques et à 50 % de son expertise métier. La phase d’implémentation est systématiquement l’occasion de raffiner le modèle qui avait initialement été conçu avec les experts métiers. C’est pour cette raison que dans l’idéal, il est intéressant d’avoir ses experts avec soi afin de raccourcir la boucle de feedback. Finalement, c’est aussi cette phase d’implémentation qui permet d’approfondir encore plus la compréhension du métier/domaine de son entreprise.

La différence entre l’architecture et design peut être subtile et parfois est mise de côté en considérant que c’est une formule un peu obscure à appliquer. Que dirais-tu à un·e dev un peu perdu entre les deux notions ?

Je lui dirais que cela n’a pas vraiment d’importance : tout est design, à vrai dire, quand on y réfléchit. Ce qui est important c’est d’aiguiser sa curiosité de façon générale, toujours essayer de comprendre les raisons qui ont mené à telle architecture, à tel choix, à tel design, etc. Cette démarche nous protège des risques du « cargo cult« , et c’est un investissement à long terme sur soi-même avec un effet boule de neige garanti !

Une conférence présentée par

Benoit GALATI

Software engineer dans une équipe plateforme chez Yousign où les backends sont pratiquement tous propulsés par PHP bien sûr ! Benoit est passionné de software design et plus particulièrement par les approches comme DDD et TDD. Il souhaite créer des logiciels maintenables et évolutifs, qui apportent une valeur ajoutée importante aux entreprises, tout en rendant ses utilisateurs finaux heureux.

Autres intervenants