Construire une architecture qui tient la route quand on livre seul
Deux stages et plusieurs projets freelance plus tard, voici comment mes choix d'architecture ont évolué face à des délais courts et des clients qui changent d'avis.
Sur mes premiers projets, je découpais mon code en couches propres dès le premier jour : services, repositories, contrôleurs. Ça avait l'air sérieux. Le problème, c'est que la moitié de ces couches ne servaient à rien sur un projet d'un mois avec un seul développeur.
Découper large, puis resserrer
J'ai changé d'approche : je commence maintenant par un découpage simple, aligné sur les fonctionnalités visibles par le client, et je ne fais émerger une abstraction que lorsqu'un vrai second cas d'usage apparaît. Ça évite de deviner une architecture avant de savoir ce que le projet va réellement devenir.
Ce changement s'est vu concrètement sur mes deux derniers projets livrés en freelance : moins de fichiers, moins d'indirections, et surtout des livraisons plus rapides sans sacrifier la possibilité de faire évoluer le code ensuite.
- Commencer par la donnée et l'écran, pas par la couche d'abstraction
- Ne factoriser qu'après avoir vu le même besoin apparaître deux fois
- Documenter les décisions plutôt que le code lui-même, pour garder la liberté de changer d'avis
Ce n'est pas une méthode figée. C'est une manière de rester honnête sur ce qu'un projet a réellement besoin, à l'instant où on le construit.