Idée principale

Un développeur qui refuse une action crée un cas d'erreur, et il le nomme. CannotEditInvoicedOrder dit « on ne peut pas modifier une commande facturée » : la règle entière tient dans le nom, sans commentaire ni documentation. Personne n'a écrit ce nom pour documenter quoi que ce soit — c'était le moyen le plus court de désigner le refus au moment de le coder.

D'où un gisement inattendu dans les parties du code les moins bien rangées, celles où aucune règle n'est énoncée en clair : la liste des noms de cas d'erreur. Elle se lit sans savoir programmer, puisqu'il ne s'agit que de lire des noms.

Trois autres endroits produisent des règles, par rendement décroissant : les vérifications faites en début d'opération, avant que quoi que ce soit ne soit modifié ; les contraintes de la base de données — ce qui doit être unique, ce qui ne peut pas rester vide ; les contrôles de saisie dans les écrans.

Pourquoi c'est important

Cela ouvre la lecture des règles à ceux qui ne lisent pas le code, et ce sont eux — support, avant-vente, product management — qui ont besoin des règles. La barrière technique tombe sur la partie du travail qu'on croyait la plus technique.

Cela donne aussi un ordre d'attaque quand le temps est compté : commencer par les erreurs, finir par les écrans, plutôt que de parcourir les fichiers.

Nuances et limites

Un nom d'erreur mal choisi énonce une fausse règle avec le même aplomb qu'un bon : la source est dense mais non vérifiée, et chaque règle qui en sort reste à confirmer.

Et l'absence de cas d'erreur ne dit rien : un refus peut être exprimé autrement, ou n'exister nulle part parce que la règle n'est pas appliquée. Un objet décrit sans aucune règle signale une description superficielle, jamais un métier sans règles.

Questions ouvertes

• Que faire des règles qui ne refusent rien — celles qui déclenchent, calculent ou complètent —, puisqu'elles ne laissent aucun nom derrière elles ?