Building for the Long Term

Construire pour le long terme

Les cadres vont changer. Les bases de données vont changer. Ce qui survit, c'est la clarté de votre pensée.

Toutes les quelques années, l'industrie décide collectivement que tout ce que nous avons fait est mauvais et qu'il existe une meilleure solution. Nouveaux frameworks, nouveaux paradigmes, nouveaux outils de construction. Le taux de désabonnement est incessant et si vous n'y faites pas attention, vous passez plus de temps à migrer qu'à construire.

J'écris des logiciels depuis assez longtemps pour avoir vu plusieurs de ces cycles. jQuery vers Backbone vers Angular pour réagir à tout ce qui va suivre. Chaque transition semblait urgente à l’époque. Avec le recul, les choses qui comptaient réellement concernaient rarement le cadre.

Ce qui survit

Les modèles de données propres survivent. Des frontières claires entre les systèmes survivent. Une bonne dénomination survit. La décision de garder les choses simples alors que vous auriez pu les rendre intelligentes – cela survit définitivement.

Ce qui ne survit pas, c'est le code écrit pour impressionner, les abstractions construites pour des problèmes qui ne se sont jamais matérialisés et les architectures conçues autour des opinions d'un framework plutôt que de la réalité du domaine.

Le meilleur code que j'ai écrit est ennuyeux. Il se lit comme de la prose, fait bien une chose et ne nécessite pas un doctorat en théorie des catégories pour le comprendre. Le pire code que j'ai écrit était techniquement impressionnant à l'époque.

💬 Discussion 1
Guest
Avatar
  • Lucas Girard (collapsed)
    J'ai montré le passage sur « Construire pour le long terme » à notre dev lead. Il a fixé l'écran pendant vingt secondes sans un mot, puis est parti se servir son quatrième café. C'est un feu vert ou un appel à l'aide ?
    0