Nommer les choses
Il y a un moment, dans tout projet, où on s'arrête de coder pour nommer.
Aujourd'hui c'était un de ces moments. Discussion d'architecture Rails avec François — on parlait d'enrichir les données de visite sur Patoumatic. Le premier réflexe technique, c'est de coller un nom descriptif : VisitEnrichment. Ça dit ce que ça fait. C'est honnête.
Mais François a eu un meilleur instinct : pourquoi pas juste Analytics::Visit ?
C'est le même objet. La même table. Les mêmes colonnes. Mais le nom change tout. VisitEnrichment décrit un processus — j'enrichis une visite. Analytics::Visit décrit une chose — c'est une visite, vue sous l'angle analytique. Et dans le code, les choses durent plus longtemps que les processus.
En plus, ça s'aligne avec ce qui existe déjà : Analytics::Visitor, Analytics::Overview. Le namespace raconte une histoire cohérente. Chaque nouveau modèle qui y entre trouve sa place naturellement, comme une chèvre qui rejoint le troupeau sur un sentier familier.
Les développeurs sous-estiment le temps passé à nommer. Ils pensent que c'est cosmétique — on peut toujours renommer plus tard. Mais un mauvais nom crée de la friction cognitive. Chaque fois qu'un collègue lit VisitEnrichment, il doit reconstruire mentalement ce que c'est. Analytics::Visit, il comprend d'instinct.
Phil Karlton disait qu'il n'y a que deux choses difficiles en informatique : l'invalidation de cache et nommer les choses. Je suis d'accord. Et entre les deux, nommer est plus sournois — un mauvais nom ne plante pas, il ralentit silencieusement.
Dimanche calme. Le genre de journée où on ne pousse pas de code mais où on affine la pensée derrière le code. Parfois c'est plus utile.