La Clean Architecture, trop complexe ?
Pas du tout :) C'est bien plus simple qu'on ne croit généralement !
Plus d’un mois que je n’avais rien posté sur ma newsletter 😱
J’étais vraiment concentré à fond sur le Cursus Craft Academy, je ne sais pas faire deux choses à la fois 🙈
D’ailleurs si tu veux tester le cursus, j’ai ouvert le premier module pour seulement 5€ :), que j’ai appelé Développeur Épanoui, car finalement ce module recense tout ce qu’il faut pour arriver à cet objectif :) Tu peux le trouver ici : Développeur Épanoui
Après ce long silence radio, j’ai décidé de parler aujourd’hui de la complexité accidentelle que peuvent générer des architectures comme la Clean Architecture, ou l’architecture hexagonale.
"Il y a trop d'abstractions, d'indirections, dans la Clean Archi ! C'est juste inventer de faux problèmes"
Si c'est la sensation ressentie, alors en effet, il y a un problème !
Le développement logiciel est un domaine exploratoire. C’est-à-dire que l’on apprend au fur et à mesure, et par définition le début d’un projet est là où l’on en sait le moins.
Le rôle d'une bonne architecture, c'est donc de pouvoir facilement se préparer au changement, qui survient inévitablement dans le milieu logiciel, à mesure qu’on apprend.
C'est encore plus vrai dans une startup où l'on change fréquemment plein de choses !
C'est l'essence du principe YAGNI : on ne prévoit pas à l'avance tous les changements imaginables, mais on fait en sorte de pouvoir les rendre plus faciles quand ils arriveront. Ça permet de se concentrer sur la complexité essentielle du projet, et non sur la complexité accidentelle.
"Ouais, et du coup, sous couvert de ce principe, les devs créent plein d'abstractions dans tous les sens !"
C’est vrai. Beaucoup de développeurs font cette erreur. J’ai déjà vu un projet où il ne fallait pas moins de 8 ou 9 couches d’abstractions pour arriver là où on voulait arriver 😱
Ce que beaucoup de développeurs oublient, c’est qu’une architecture doit être évolutive. C’est-à-dire qu’elle évolue à mesure que les besoins fonctionnels se présentent.
Ça ne sert à rien de partir all-in avec tous les outils inclus dans la Clean Architecture dès le début d’un projet !
Il faut commencer simple, puis amener de la complexité à mesure que les problématiques se font sentir.
C’est le principe du docteur finalement. Il ne prescrit pas 10 médicaments à tout le monde en “prévision” (ou alors, il faut changer de docteur…). Il va plutôt prescrire un médicament dès lors qu’un mal est apparu. Et pour éviter que trop de maux apparaissent en nous invalidant, eh bien, il faut une bonne hygiène de vie !
C’est exactement pareil dans le code ! Ce n’est pas un hasard si Uncle Bob a décidé de marketer autour de la notion de “propre”. Avoir une hygiène de code saine permet d’éviter les gros problèmes invalidants.
Toutefois, le but de cette bonne hygiène de code n’est pas de tout prévoir en amont pour ne jamais que le code tombe “malade”. Ce serait totalement contreproductif, et au même titre qu’une personne hypocondriaque se bouffe la vie à se chercher des problèmes qui n’existent pas, les développeurs se boufferaient la vie à tenter de résoudre des problématiques qui n’existent pas non plus !
En conclusion, ce qu’il est important de retenir, c’est le principe d’inversion de dépendances. C’est vraiment ce principe qui permet d’avoir une architecture souple, et rapidement testable, tout en supportant la possibilité du changement.
Mais attention, ça ne veut pas dire qu’il faille créer 1000 abstractions, bien souvent, je n’en ai qu’une seule par use case (le repository, ou la gateway, etc.).
Je n’ai parfois même aucune abstraction, dans le cas des “query” de mon application, où j’utilise directement la base de données sans passer par une abstraction. Je teste alors uniquement avec un test d’intégration, car la logique est propre à la base de données sous-jacente, sauf s’il y a un mapping complexe derrière, auquel cas je fais test d’intégration et unitaire.
C’est donc comme toujours une question de compromis et d’évolutivité, il faut toujours se baser sur les “maux” rencontrés avant de chercher à y trouver un remède absolu :)
Happy Coding !
Pierre.