Faites Entrer Les Design Pattern

Le code était devenu un labyrinthe. Des classes qui s’imbriquaient comme des mensonges, des dépendances enchevêtrées, trop de new, trop de responsabilités. Chaque fonctionnalité ajoutée laissait une cicatrice. Personne n’osait toucher aux fondations. On parlait de « refacto » comme on parle d’une opération à cœur ouvert : nécessaire, mais risquée. Ils sont arrivés sans bruit. Pas des frameworks. Pas des règles. Des schémas. Les Design Patterns. On les appelait le Gang of Four, comme un vieux mythe d’architectes fatigués par le chaos. Ils n’imposaient rien. Ils observaient. Puis ils nommaient les choses. Factory. Strategy. Observer. Comme si mettre un mot sur un problème suffisait déjà à l’affaiblir. Ce n’étaient pas des recettes. Plutôt des récits de survie. Des façons éprouvées de ne pas recréer l’enfer à chaque sprint. Certains jouaient avec l’héritage, d’autres préféraient la composition. Les plus sages évitaient l’état global. Les plus dangereux promettaient de tout simplifier… à condition de ne pas les mal utiliser. Chaque pattern était une réponse à une erreur déjà commise quelque part, par quelqu’un, un jour. Une trace laissée dans la pierre. Apprendre les GoF, ce n’était pas apprendre à écrire du code parfait. C’était apprendre à reconnaître les pièges avant d’y tomber. À lire un projet comme un champ de bataille et à se dire : ici, un Strategy aurait évité ce carnage. Là, un Observer aurait empêché ce couplage toxique. Les Design Patterns ne sauvent pas un projet. Ils lui donnent juste une chance de ne pas sombrer. Et quand le code commence à respirer à nouveau, on comprend : ce n’était pas de la magie. Juste de l’expérience condensée. Froide. Méthodique. Impitoyable.