image

L’impact psychologique du nommage

Ceux qui me suivent sur Twitter le savent, je suis en train de mettre en place TFS 2010 au sein de ma nouvelle société et à cet effet nous avons mis en place une toute nouvelle infrastructure matérielle afin d’utiliser un ensemble de machines virtuelles.

Lors de la création de la machine virtuelle destinée à l’installation de TFS 2010, un de mes collègues m’a demandé le nom de machine que je souhaitais pour cette machine virtuelle en me demandant si le nom “VM-TFS” me convenait.

image Je me suis alors empressé de lui dire que je ne souhaitais pas que VM apparaisse dans le nom de la machine afin que les utilisateurs ne puissent pas râler sur l’installation à cause du fait que cela soit une VM. Mon collègue l’a pris sur le ton de l’humour mais j’étais en réalité très sérieux.

Une VM doit réagir comme une machine physique et je ne souhaite pas que les utilisateurs puissent avoir une image négative de TFS à cause du fait qu’il soit installé dans une machine virtuelle. La société n’a pas l’habitude d’utiliser les technologies de virtualisation, il est donc plus simple de ne pas leur mettre sous les yeux un panneau “Attention c’est une VM” à chaque fois qu’ils vont y accéder. L’idée n’est pas de masquer les choses (la nouvelle infrastructure a été présentée après que la migration de TFS 2005 vers TFS 2010 ait été effectué) mais de faciliter l’adoption d’une nouvelle technologie en supprimant des freins liés à des idées préconçues.

Dans le domaine du développement, j’ai également conseillé à plusieurs clients de nommer “intelligemment” certaines classes afin d’inciter une réelle maintenance/refactorisation de celles-ci. Durant des revues de code, ou tests de migration, ou autre type d’intervention, j’ai régulièrement trouvé des classes helpers destinées à faciliter l’utilisation d’une fonctionnalité. Ces classes utilisent souvent un nommage du genre “EasyQqueChose” (EasyDB pour l’accès aux bases de données, EasyXml pour la manipulation XML, etc.) pour bien signifier aux développeurs qu’avec cette classe il sera très simple d’effectuer la tâche qu’ils doivent accomplir.

Seulement avec le temps, la classe destinée à faciliter les choses est devenue un vrai capharnaüm, et est devenue complexe à utiliser. Bien évidemment cette classe doit être refactorée depuis 97879 siècles mais au final elle ne l’est jamais.

Quand je rencontrais ce genre de cas, je proposais souvent la même idée : prendre quelques minutes pour renommer la classe “EasyQqueChose” en “FuckingComplexAndUnusableQqueChose”. Je ne suis parvenu à faire appliquer cette idée qu’une seule fois  (et oui il y a encore beaucoup de développeurs qui ont peur de renommer une classe…) et étrangement quand je suis revenu quelques semaines plus tard chez ce client la classe avait été refactorée (et donc de nouveau renommée).

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *