Les patterns avancés ne compensent jamais un socle fragile

Je vois régulièrement passer des posts qui prônent l’architecture hexagonale, la clean architecture, le CQRS. Ce sont des patterns puissants, et on les associe volontiers à des projets «sérieux», bien conçus. Mais trop souvent, un élément essentiel manque au tableau: les bonnes pratiques de développement.

Une classe de deux mille lignes dans une architecture hexagonale reste une classe de deux mille lignes. C’est un anti-pattern, et surtout la signature d’un projet non maîtrisé: une équipe qui suit une tendance qu’on lui a imposée, ou des choix que personne n’a justifiés. Les couches sont là, les diagrammes sont beaux, et le code qu’ils encadrent est le même qu’avant.

On peut empiler les couches et dessiner les plus jolis schémas. Sans SOLID, sans clean code, sans tests automatisés, une application ne tient pas longtemps.

Le pattern organise le code; il ne le rend pas bon

Une dépendance inversée vers une méthode de trois cents lignes n’a rien inversé du tout.

Ce que je constate, c’est que le socle ne fait pas de bruit. Personne n’écrit un post pour dire que ses classes sont petites, que ses tests tournent en une minute et que ses noms disent ce qu’ils font. Ce sont pourtant ces choses-là qui font, en silence, la vraie solidité d’un projet. Les patterns avancés ne compensent jamais un socle technique fragile; ils le rendent seulement plus difficile à voir.

Avant d’adopter un pattern, je pose donc une seule question: l’équipe maîtrise-t-elle déjà ce qui est en dessous?

Si oui, le pattern lui donnera un cadre. Sinon, il lui donnera un alibi