Fabien Bézagu

Parmi les nombreuses questions récurrentes que je me pose, celle-ci est une de celles qui me torture le plus : dans quelle langue dois-je écrire le code qui reflète le domaine sur lequel je travaille ?

Ces derniers temps, ma réponse était plutôt tranchée en faveur de l'anglais. Evidemment, j'ai plein d'arguments.

1. Le plus important est la difficulté d'écrire du code avec les caractères accentués de la belle langue de Molière. Récemment, j'ai connu quelques déboires pour utiliser des fichiers sources écrit avec des accents sous Windows après les avoir extrait de ma repository Subversion. Je passe les détails techniques, mais il faut avouer que c'est le genre d'expérience qui pousse à affimer : plus jamais d'accent dans mes fichiers source !
2. Je travaille en ce moment pour un client qui est implanté dans de nombreux pays et la possibilité que le code que j'écris aujourd'hui soit un jour maintenu par un développeur allemand milite également en faveur d'un langage international. Il faut (malheureusement) constater que pour remplir ce rôle, l'anglais s'impose,
3. La quasi totalité des langages informatiques que nous utilisons sont basés sur l'anglais et contiennent des mots clefs anglais : if, then, else, call, get, set, abstract, override... Mixer de l'anglais et une autre langue rend la lecture du code moins fluide qu'en utilisant uniquement de l'anglais,
4. Les frameworks (pardon, les structures (?)) et les outils externes que nous utilisons le plus souvent sont également très souvent en anglais, ce qui renforce le point précédent,
5. Les patterns (motifs ?) sont souvent eux aussi plus souvents compris par les développeurs dans leur terme original, qu'il s'agisse de design pattern, de patterns d'architecture ou de patterns DDD : qui utilise "usine abstraite" pour "abstract factory", "entrepôt" pour "repository", "chargement paresseux" pour "lazy loading", etc ? Il est donc plus naturel d'utiliser le terme CustomerRepository pour que tout développeur éclairé à DDD sache qu'on parle bien du pattern "repository",
6. Afin d'éviter de créer une application multilingue, il est moins couteux d'écrire une interface utilisateur unique, bien souvent en anglais. Afin d'éviter de traduire le modèle en anglais, autant l'écrire directement dans cette langue.

Comme je l'ai dit plus haut, tous ces arguments sont très valables. Malgré cela, je continue de me poser la question.

Dans DDD ^[1], Eric Evans avance de nombreux arguments pour la mise en place d'un langage omniprésent (ubiquitous language). Il parle ici des problèmes liés à la divergence entre les différents jargons : d'un côté les développeurs utilisent des termes techniques et de l'autre les experts du domaine utilise leur jargon métier. Le langage omniprésent permet à ces deux parties d'utiliser les mêmes termes et de se comprendre. Le code est ainsi le reflet de ce langage omniprésent.

Je pense que le même problème s'applique pour la langue utilisée. Si nous écrivons notre code en anglais et que nos conversations avec les experts du domaine sont faites en français, alors nous sommes obligés de mettre en place une traduction néfaste pour la communication. J'ai entendu un argument pour résoudre ce problème : faisons nos réunions en anglais ! Je trouve cela saugrenu ;-)

La solution qui coule de source est donc d'utiliser sa langue maternelle pour modéliser le domaine. Le code est le reflet du modèle et devrait donc être écrit dans cette langue.

Les arguments que j'ai énumérés plus haut ne sont pas pour autant balayés d'un revers de la main mais je pense qu'il faut composer avec et en connaissance de cause.

J'attends les réactions ;-)

Dur titre de billet. J'ai récemment commencé ma deuxième lecture de DDD ^[1] et je constate avec une pointe d'amerture que notre tentative de modéliser le domaine sur lequel s'appuie notre application est loin de correspondre à une approche DDD :-(

Bien que le code que nous avons écrit reprend quelques termes métiers, nous avons été obligé d'introduire des notions que les experts du domaine et les utilisateurs ne s'attendraient absolument pas à trouver ici. Pire, nous passons souvent beaucoup de temps à relire ce code en nous posant des questions interdites : mais à quoi ça sert et comment ça marche ? Le code devrait être le reflet de notre modèle. Nous devrions pouvoir dialoguer en toute transparence avec les experts sur les mécanismes internes non techniques de ce code. Ce n'est pas le cas. Ce code n'est le reflet d'aucun modèle cohérent et exprimable.

Bien sûr, je peux nous trouver des tonnes d'excuses : certes nous n'avons jamais rencontré les utilisateurs ni les détenteurs du besoin; certes nous n'avons vu notre "expert du domaine" qu'environ trois ou quatre fois en six mois; certes le processus de développement est anti-agile avec un modèle en cascade d'un pouvoir destructeur sur l'information essentielle tel que j'en ai rarement connu. Mais ce ne sont que des excuses.

Plus nous sommes entourés de personnes qui nous retranscrivent un besoin dépouillé de sa substance fonctionnelle, plus nous pêchons par orgueil en prétendant mieux connaître le métier que l'utilisateur lui-même. Cet orgueil nous aveugle sur nos propres faiblesses.

Ce projet est ma deuxième tentative de modèliser un domaine avec toute sa complexité et sa richesse. La première fois également, je n'avais pas accès aux experts du domaine. A quoi sert de modéliser un domaine correctement si on ne peut pas s'en servir pour communiquer avec les personnes qui connaissent le métier et qui ont besoin de nous pour répondre à un besoin ? Certainement à peu de chose. C'est d'ailleurs un des prérequis qu'impose Eric Evans : pouvoir dialoguer avec un expert du domaine. Je comprend aujourd'hui toute la force de ce prérequis: au delà du bête recueil des besoins, il s'agit de mettre en place une osmose totale entre les développeurs et les experts du domaine.

Sur mon projet actuel, comme je l'ai déjà dit, nous n'avons pas pu mettre en place ce dialogue "osmotique". Je reste convaincu que l'approche DDD est bonne même dans ce cadre (maintenabilité, gestion de la complexité, testabilité...) mais nous aurions dû être d'avantage schizophrène que nous l'avons été.

Dorénavant, je serai plus vigilant et une chose est sûr : la prochaine fois, je ferai mieux.