Le nom donne le point de départ
Un nom ne sert pas seulement à identifier un sujet. Il indique aussi où commencer à chercher.
Avant son départ en congé, une collègue m’a transmis un ticket qui semblait assez simple.
Le titre décrivait le changement à réaliser, mais pas la fonctionnalité concernée. Lors du handover, j’ai reçu une première explication. Plus tard, le Product Owner m’en a donné une autre. Les deux étaient plausibles, mais elles ne renvoyaient pas au même endroit du produit.
Ce qui m’a débloquée, ce n’est pas une explication plus détaillée. C’est un collègue qui connaissait bien ce domaine et qui m’a simplement indiqué où regarder. À partir de là, le code est devenu facile à lire. La difficulté n’était pas l’implémentation ; c’était de trouver le bon contexte.
Depuis, je considère les noms comme de petits éléments d’orientation. Un titre, un champ ou un composant ne répond pas seulement à la question qu’est-ce que c’est ? Il suggère aussi où cela se situe-t-il ? et quel modèle mental faut-il activer ?
Quand le nom reste vague, chacun doit reconstruire ce contexte. On perd du temps, mais surtout on risque de commencer à raisonner au mauvais endroit.
Un titre plus précis, incluant le nom de la fonctionnalité, aurait probablement évité cette dérive dès le départ. Il n’aurait pas rendu le problème moins complexe ; il aurait raccourci le chemin vers la bonne zone du système.
Nommer n’est donc pas un geste cosmétique. C’est une forme discrète d’architecture de l’information.