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 ;-)