Bienvenue sur le podcast Artisan Developer, l'émission pour les programmeurs qui veulent
vivre une carrière épanouissante.
Prêts à passer au niveau supérieur ? C'est parti !
Aujourd'hui je suis avec Romain Fallet, Romain bonjour.
Bonjour Benard.
Est-ce que tu peux te présenter en quelques mots pour ceux qui ne te connaîtraient pas ?
Oui, je m'appelle Romain Fallet, je suis lead développeur chez TALK qui est une start-up
qui fait un logiciel SaaS qui permet d'automatiser en fait des interactions utilisateurs, donc
des messages, je fais des canaux like chat ou des messageries comme Instagram et Facebook.
Donc derrière on a une petite intelligence artificielle qu'on développe en interne.
Le sujet de l'épisode c'était architecture hexagonale versus framework.
Tu avais noté que je mentionnais souvent Rails comme ce que j'ai mis dans ce framework
là, c'est que c'était quelque chose qui était un peu clair en main.
En gros tu n'avais pas trop à réfléchir sur la structure et tu suivais un peu la convention.
Pour moi c'est tout ce qui fait la force de Rails, c'est tout l'intérêt de Rails,
c'est là-dedans parce que ça a plein d'avantage.
Et tu notais que comment est-ce que l'architecture hexagonale rentrait là-dedans qu'en fait ?
C'est ça en fait, c'est plutôt, a priori ce sont des approches complètement différentes
parce que le principe de l'architecture hexagonale, de la clean architecture, c'est de se dire
tout doit être interchangeable dans l'application.
Donc un framework doit pouvoir être emplacé par un autre équivalent alors que sur l'approche
Ruby on Rails, c'est-à-dire bah voilà je prends mon framework, je prends la stack connue
de tous et ça me permet de ne pas avoir à m'embêter avec la technique, me concentrer
sur le métier.
Mais ceci, la même promesse du coup, cette même promesse de concentration sur le métier
qui apporte l'architecture hexagonale, c'est-à-dire bah voilà en fait vu que tout
est interchangeable, je vais pas être contraint à mon donné par un framework, par une solution
technique, je vais pouvoir épouser l'évolution du besoin au métier.
Et donc voilà, c'est cette promesse de focus sur le métier qui a priori semble être la
même mais sur deux approches un peu contradicteurs.
Alors pour moi, ces deux approches qui sont contradictoires je suis assez d'accord et d'ailleurs
ce que j'ai trouvé intéressant c'est que l'un des, il me sent, que l'un des premiers
papiers d'un Cullmub sur l'architecture hexagonale ou la clé d'architecture chez
Pu ou Robert Matin enfin chez Pu a été justement sur des cas illustrés par du Rails.
Ce qui n'a pas manqué de générer une réaction assez vive dans la communauté notamment de
son fondateur DHH qui est donné lui à plein d'échanges super intéressants sur TDDHsDead.
Et quand j'ai vu ça, je t'avoue, moi je vais faire une confession voilà c'est le moment,
c'est le moment de confession sur le podcast, sur les projets que j'ai fait pendant 8 ans
dans mon OSN, j'ai très peu fait d'architecture hexagonale et j'ai pas honte de le dire et même
je défends un point de vue qui était de dire ça amène une complexité, voilà, première fois
que j'ai vu ça, je me suis dit oh bordel, toute cette complexité supplémentaire, pourquoi exactement ?
Mais en fait j'ai très vite on s'est rendu compte que pour nous ça n'allait pas le coup en fait,
dire qu'il n'y avait pas de rationnel économique à faire ça en fait,
on restait sur des projets qui étaient assez simples, du bon vu, crud ça marchait très très bien,
on embrassait complètement le framework, on allait du coup extrêmement vite ce qui était la demande
du client, de toute façon neuf projets sur 10 se sont cassés à la gueule, n'ont pas passé l'étape
de la survie du marché et justement les deux projets qui ont survécu, y'en a un on n'a pas pu
rapidement, on a passé la main à des équipes internes et le deuxième on a pu aller un peu plus loin
et on a commencé à mettre en place de l'architecture hexagonale, donc tu vois j'ai pas honte de dire
qu'en fait il faut savoir s'adapter à la situation, à ton contexte, à tes besoins et dans beaucoup
des projets c'était juste pas adapté de notre point de vue.
Je suis complètement d'accord avec toi et c'est ça qui m'intéressait aussi justement dans l'échange
parce que je savais que tu avais eu cette approche là avec ton SN alors que justement nous ce qu'on
a mis en place chez TOLK c'est l'architecture hexagonale, mais parce qu'on a un produit
qu'on fait évoluer sur l'échelle d'année, on n'est pas sur un projet de trois à six mois,
on n'est plus sur un Poc, notre preuve de marché elle est là, donc maintenant c'est comment on fait
pour évoluer, pour apprendre et faire en sorte qu'on puisse toujours y térer sur les besoins de
nos clients. Et je trouve ça très bien d'ailleurs, tu vois sur les... ça me fait penser en fait pas à
l'approche micro-service versus monolithe, c'est un peu le même discours, on démarrait toujours
en monolithe et il y a quelques projets en fait en l'occurrence depuis en huit ans où c'était
complètement justifié à un moment donné, on sentait la complexité du monolithe se peser et on
s'est dit non là en fait là il a besoin de découper, il en a fait parce que si ton code il est propre,
si ton code il est déjà bien structuré, que tu es déjà en service, que tu es déjà avec une
couche bien bien bien designée, parce que tout on faisait pas que ça comme des cochons à tout mettre
dans des modèles tu vois, parce que c'est un peu le biais notamment sur rails, tu commences, tu mets
tout dans la couche de modèle et à un moment donné tu te retrouves avec ce qu'on appelle les
fattes modèles l'ailleurs, mais si tu es... commence progressivement dès le début à mettre des choses
proprement dans des services à séparer les responsabilités des classes, des opérations
que tu fais en fait à un moment donné, splitter et faire du micro service c'est juste un enjeu
DevOps quoi, c'est l'ancien serveur configuré à une queue et vas-y. C'est ça et en fait je pense
qu'on met souvent du coup en opposition cet aspect l'approche framework à l'approche du coup
archi un peu plus costaud, en ayant en tête que en fait sur le framework il n'y a pas de notions
de découplage, qu'il n'y a pas de notions de conception fortes justement alors qu'en fait on
peut faire du mauvais code avec un framework, on peut aussi faire du mauvais code en archi exacto
l'idée c'est peut-être se concentrer en fait sur les principes de conception qui
est derrière quoi, c'est pas tout, la stack finalement c'est pas tout quoi.
Clairement on reparlait encore de l'archi exacto dans le cercle pas plus tard qu'hier,
l'archi exacto c'est jamais qu'une standardisation du principe d'inversion de dépendance et c'est
très bien, très bien mais si tu utilises le principe d'inversion de dépendance dans ton design
et que tu te retrouves avec des classes faiblement couplées, t'es déjà vachement mieux qu'avec
dix microservices qui sont en fait des espèces de plates baguette. C'est tout à fait.
Donc l'idée derrière cette réflexion c'est finalement est-ce que les deux permettent le même
focus métier et la réponse c'est oui à condition que la conception soit bien pensée.
Toi dans ton projet là où vous l'avez mis en œuvre dès le début l'archi exacto
où c'est venu au fil de l'eau ? On l'avait dès le début quand je suis arrivé mais
du coup pas dès le début à l'échelle de l'histoire du produit parce que je suis arrivé il y a
à peu près un an et demi le produit doit avoir plus de trois ans maintenant donc oui on a du
legacy comme tout le monde qui ne sont pas en archi exacto où les choses ne sont pas bien
découplées etc mais c'est quelque chose qui est arrivé progressivement et maintenant toutes les
nouvelles fonctionnalités sont faites dans ce paradigme. Et quelles sont les challenges que
tu as au quotidien dans la gestion de ton legacy et la migration vers ce pattern de conception ?
La difficulté je pense c'est vraiment de savoir qu'est ce qu'on migre et qu'est ce qu'est surtout
quand. Parce qu'en fait on est une petite équipe on est moins d'une dizaine et l'idée c'est voilà
on est sur un marché qui est encore très concurrentiel on a fait notre on a fait notre
preuve de marché mais la boîte n'est pas encore loin devant ses concurrents donc il y a une certaine
pression qu'on a sur sur les livraisons et donc on ne peut pas se permettre de pouvoir se permettre
de livrer de passer trop de temps en fait à refactorer des choses qui qui sont pas importantes
maintenant et donc il y a ce côté faut mettre le le curseur sur est ce qu'on fait déjà est ce
qu'on a besoin de retoucher à ce truc là est ce que ça va évoluer et puis est ce qu'on fait
maintenant est ce que là maintenant c'est le bon moment par rapport à d'autres priorités à
d'autres fonctionnalités qui pourraient apporter plus de valeur mais est ce que du coup si plus on
attend plus ça va être compliqué aussi de le changer enfin voilà c'est vraiment ce curseur
savoir est ce que le le périmètre doit être bougé est ce qui doit être changé maintenant
je pense que c'est un très bon problème si tu te posais pas ces questions là c'est que c'est que
soit un problème marché soit un problème technique donc c'est et je pense que c'est tout le secret
des boîtes qui qui arrive à un moment donné c'est de gérer cette cette dualité dans les deux
excès soit tu pars dans un excès très technique mais comme tu l'as dit tu avances plus tellement
et ton marché trahète enfin tes concurrentes te rattrapes et voir te dépasser te rendent
d'asmine soit tu tombes dans l'accès inverse de d'être uniquement focus sur le marché et sortir
sortir des choses sans te préoccuper de la tech mais à un moment donné tu le payes et t'es immobilisé
c'est ça donc en tout cas nous le le l'arbitrage qu'on fait pour l'instant c'est parti sur du
moment où on n'a pas besoin de le faire évoluer on ne migre pas on migre que s'il y a besoin de faire
évoluer et du coup s'il y a besoin de faire évoluer en se posant la question est ce que on n'a pas
une priorité par rapport à ce chantier donc faut déjà qu'on estime l'ampleur et est ce que
voilà est ce que c'est le moment maintenant ce qu'il n'y a pas une priorité ce qu'on a vraiment
besoin maintenant de ce facteur quitte du coup des fois à repousser des évolutions voilà j'allais
dire du coup ça veut dire que des fois tu acceptes de continuer à faire comme c'était avant donc
d'alourdir un petit peu la dette de cette partie là pour aller plus vite et pouvoir te concentrer
sur autre chose qui a peut-être plus de valeur c'est ça mais et puis en fait des fois on se dit
bah en fait vu que cette évolution elle va nécessiter ce réfacto en fait on se dit bah
en fait cette évolution on l'avait pensé pour l'embarquer le mois prochain mais en fait peut-être
qu'on l'embarquer un peu plus tard ok donc soit tu joues tu joues de l'arbitrage tu peux aussi
arbitrer sur le délai quoi c'est ça on peut en fait on peut aussi arbitrer sur le délai dans le
sens où on a une intelligence produit où on prend en compte ça à un moment où planifie le boulot
quoi et pour le produit c'est entendable de se dire bah plutôt que de faire un truc rapide sale
sur le vieux c'est aussi entendable de dire bah on va plutôt faire passer un ou deux sprints sur
un autre sujet qui n'a complètement rien à voir pour que quand on aura besoin de toucher à ça on
est suffisamment d'espace pour faire ça correctement quoi là ça sous-entend une un travail en très
bonne intelligence avec le produit quoi c'est ça et ça c'est vraiment un truc que je trouve hyper
chouette qu'on a chez nous dans l'équipe c'est hyper plaisante de pouvoir travailler comme ça
bah écoute roman je suis ravi et ce sera le mot de la fin si les auditeurs veulent en savoir plus
sur ce que tu fais et te suivre ils peuvent venir au et peuvent me trouver sur link et din et si si
tout le que les intéressent peut retrouver sur le site tolk.ai merci roman merci à toi quand ça
t'achète aux auditeurs bah comme d'aimes j'espère que tu apprécies cet épisode si tu veux en savoir
plus découvrir ce fameux cursus dont je t'ai parlé pendant cet épisode vient sur compagnons.artisan
développeurs.fr dans la rubrique formation je te souhaite une bonne journée