Modules réutilisables, et quand s'en abstenir

Un module est presque toujours créé trop tôt. Le scénario est constant : il faut une seconde file de messages, on constate que le bloc ressemble au premier, on l'extrait dans un module « pour plus tard ». Six mois après, le module a onze variables booléennes, trois count = var.enable_x ? 1 : 0, et personne n'ose y toucher parce qu'il est appelé par quatre projets dont deux dépendent d'un comportement que le troisième considère comme un bug. L'abstraction censée réduire la duplication a produit un composant plus difficile à lire que les quatre copies qu'elle remplace.

Le problème n'est pas les modules, c'est le moment où on les crée. Un module est une interface, et une interface ne se conçoit correctement qu'après avoir vu plusieurs usages réels. Écrit après deux ou trois duplications assumées, il capture ce qui varie vraiment et ce qui ne varie pas. Écrit à la première ressemblance, il fige un besoin imaginaire et paramètre les mauvaises choses. Cette leçon montre comment écrire un module utile, puis donne des critères concrets pour décider si vous devez en écrire un.