Le coût du renouvellement perpétuel
Chaque choix technologique est un pari sur l'avenir. Certains paris vieillissent bien — le HTML sémantique, l'amélioration progressive, une séparation claire des responsabilités. D'autres non — les patterns propres à un framework qui vous enferment, les outils de build abandonnés en route, les abstractions qui résolvent des problèmes que vous n'avez jamais réellement eus.
Le coût d'un mauvais choix ne se limite pas à la migration. C'est la friction accumulée à travailler contre ses outils plutôt qu'avec eux. C'est la documentation qui ne correspond pas à la version que vous exécutez. C'est la charge mentale d'entretenir des patterns qui avaient un sens il y a trois ans, mais plus aujourd'hui.
Ce qui vieillit bien
D'expérience, les choses qui vieillissent bien partagent des traits communs :
- Elles sont ennuyeuses. Les technologies ennuyeuses sont ennuyeuses parce qu'elles ont été éprouvées. Les bugs sont connus. Les cas limites sont documentés. La communauté a des réponses.
- Elles sont simples. Pas faciles — simples. Elles ont une surface réduite. Elles font une seule chose et la font bien. Elles se composent avec d'autres outils au lieu d'essayer d'être toute la pile.
- Elles respectent les standards. HTML, CSS, HTTP, les URL — ce sont les murs porteurs du web. Construire directement sur eux, plutôt que de les masquer derrière des abstractions, tend à produire des systèmes qui durent.
- Elles sont explicites. La magie est amusante jusqu'au jour où il faut la déboguer. Un code explicite, un flux de données évident et un comportement prévisible valent plus que des abstractions ingénieuses qui économisent quelques frappes de clavier.
Les bénéfices de la simplicité se cumulent
Un système simple que vous comprenez entièrement vaut plus qu'un système sophistiqué que vous ne comprenez qu'en partie. C'est vrai à toutes les échelles — d'une simple fonction à une architecture entière.
La simplicité, ce n'est pas écrire moins de code. C'est écrire du code où chaque ligne est là pour une raison que vous pouvez formuler. C'est choisir l'approche qui comporte le moins de pièces mobiles tout en résolvant le problème. C'est résister à l'envie d'optimiser pour des exigences futures hypothétiques.
La récompense de cette discipline est cumulative. Les systèmes simples sont plus faciles à étendre, plus faciles à déboguer, plus faciles à transmettre et plus faciles à appréhender sous pression. Ils vieillissent mieux parce qu'il y a moins de choses qui peuvent mal tourner.
La pratique
Construire pour durer est une pratique, pas une liste de contrôle. C'est marquer une pause avant d'ajouter une dépendance. C'est se demander si l'abstraction vaut l'indirection. C'est choisir la lisibilité plutôt que l'ingéniosité, et la stabilité plutôt que la nouveauté.
Ce n'est pas l'approche la plus exaltante. Mais c'est celle qui vous permet de consacrer votre temps au travail qui compte au lieu de vous battre contre vos outils.