Programmation et langage ubiquitaire (DDD) dans un domaine autre que l'anglais

Je sais que certaines questions déjà étroitement liées à ce sujet ont déjà été abordées ici, mais aucune ne prend comme point de départ la langue ubiquiste . Je pense donc que cela justifie cette question.

Pour ceux qui ne le savent pas: le langage ubiquitaire est le concept de définition d'un langage (parlé et écrit) qui est également utilisé par les développeurs et les experts du domaine pour éviter les incohérences et les problèmes de communication dus aux problèmes de traduction et aux malentendus. Vous verrez la même terminologie apparaître dans le code, les conversations entre tous les membres de l’équipe, les spécifications fonctionnelles, etc.

Donc, ce que je me demandais, c'est comment traiter la langue ubiquitaire dans des domaines autres que l'anglais.

Personnellement, je suis fortement en faveur de l’écriture complète du code de programmation en anglais, y compris des commentaires, mais bien sûr des ressources et des constantes exclues.

Cependant, dans un domaine non anglais, je suis obligé de prendre la décision suivante:

1. Écrivez le code reflétant la langue ubiquitaire dans la langue naturelle du domaine.
2. Traduisez la langue ubiquitaire en anglais et arrêtez de communiquer dans la langue naturelle du domaine.
3. Définissez un tableau qui définit comment la langue ubiquitaire se traduit en anglais.

Voici certaines de mes réflexions basées sur ces options:

1) J'ai une forte aversion pour le code multilingue, c'est-à-dire le codage utilisant des noms de type / membre / variable, etc. non anglais. La plupart des langages de programmation «respirent» l'anglais dans une large mesure et la plupart de la littérature technique, des noms de modèles de conception, etc. sont également en anglais. Par conséquent, dans la plupart des cas, il n’est tout simplement pas possible d’écrire du code entièrement dans une langue autre que l’anglais, de sorte que vous vous retrouvez avec plusieurs langues.

2) Cela forcera les experts du domaine à commencer à penser et à parler dans l'équivalent anglais de l'UL, ce qui ne leur viendra probablement pas naturellement et gênera donc la communication de manière significative.

3) Dans ce cas, les développeurs communiquent avec les experts du domaine dans leur langue maternelle, tandis que les développeurs communiquent entre eux en anglais et, ce qui est le plus important, écrivent du code en utilisant la traduction anglaise de UL.

Je suis sûr que je ne veux pas choisir la première option et je pense que l'option 3 est bien meilleure que l'option 2. Qu'en pensez-vous? Me manque-t-il d'autres options?

MISE À JOUR

Aujourd'hui, environ un an plus tard, après avoir traité cette question quotidiennement, je dois dire que l'option 3 a plutôt bien fonctionné pour moi.

Ce n'était pas aussi fastidieux que ce que je craignais au départ et traduire en temps réel tout en parlant au client n'était pas un problème non plus.

J'ai également constaté que les avantages suivants étaient vrais, basés sur mon expérience.

• La traduction de l'UL vous incite davantage à définir l'UL et même le domaine lui-même, en particulier lorsque vous ne savez pas traduire un terme et que vous devez commencer à consulter des dictionnaires, etc. Cela m'a même amené à reconsidérer les décisions de modélisation de domaine. parfois.
• Cela vous aide à approfondir votre connaissance de la langue anglaise.
• De toute évidence, votre code est beaucoup plus agréable à regarder qu'au lieu d'être une obscénité ahurissante.

J'ai souvent fait face à ce problème et, à mon avis, la réponse est: "il n'y a pas de réponse unique valable pour tous les scénarios."

Mais gardez à l'esprit que la langue ubiquitaire n'est pas un objectif en soi. C'est un outil pour renforcer la communication entre l'équipe et les experts du domaine et pour renforcer la cohérence conceptuelle du modèle implémenté dans le code, les tests et la conversation.

Si vous parlez sans ambiguïté avec UL, vous êtes sur la bonne voie. Si vous et vos pairs traduisez en permanence du code à la conversation ou d'un concept à un autre, vous êtes probablement en retard.

En pratique, tous les domaines ne sont pas égaux, ni les experts de domaine. Certains domaines ont quand même beaucoup de terminologie anglaise (domaines basés sur la technologie, par exemple) et il semble raisonnable d’opter pour un choix en anglais intégral. Cependant, certaines cultures peuvent influencer ce choix (le français vient à l’esprit) et la diffusion de la terminologie anglaise varie d’un pays à l’autre. Dans certains autres domaines (juridique, pour n'en nommer qu'un), il est impossible de traduire certains termes. Sinon, la traduction rendrait le suivi de la conversation extrêmement difficile pour Domain Expert.

En général, nous sommes plus intéressés par ce que l'expert du domaine a à dire. Nous voulons donc leur faciliter la tâche. Sinon, ils pourraient simplement prendre une classe UML et lire nos diagrammes (c'était une blague). La seule recommandation qui soit faite ici est donc: "faites attention au comportement de l'expert du domaine", s'ils sont engagés dans la conversation et que celle-ci se déroule sans encombre, vous êtes probablement sur la bonne voie, gardez ce langage. Cela pourrait entraîner un peu de travail supplémentaire pour l'équipe, mais c'est bien. En tant que développeurs, nous sommes quelque peu formés pour apprendre des mots avec une signification spécifique dans un contexte.

Étrangement, cette question est toujours accompagnée de l’hypothèse que tout le code doit parler une seule langue. Cela pourrait être contesté aussi. Je ne suis pas natif anglais, et la connaissance d'une langue étrangère est pas plat: mon cerveau va vite quand on parle de nom , nom , voiture et autres, manque quelques détails quand on parle de code postal , ralentit quand on parle de prêt et demande certainement pour une explication rassurante quand on parle d’ hypothèque .

Alors, encore une fois, choisissez la meilleure combinaison qui facilitera l’écoulement de la conversation et fournira la plus grande quantité d’informations et de commentaires de la part de l’Expert du domaine.

Je considère généralement certains mots techniques comme neutres même s’il existe une traduction dans l’autre langue.

Par exemple, lorsque je parle de codage en allemand, j'utilise toujours le vocabulaire technique anglais comme s'il s'agissait de mots allemands, même s'il existe un équivalent en allemand.

Dans votre cas, je ferais le contraire. Importez certains mots techniques de votre langue maternelle en anglais, tout comme les mots étrangers ont été importés depuis des siècles. Faites-les se comporter grammaticalement comme des mots anglais. Au début, cela semble étrange, mais vous vous y habituerez.

Je suis d'accord avec le commentaire anglais «respirer» de la plupart des langages de programmation , qui devient toujours un problème avec les efforts de développement multilingue

Normalement j'aurais le UL dans le langage de votre équipe de programmation

Ce que nous avons fait par le passé est de créer de nouveaux mots qui expriment mieux les sujets du domaine. Avec un projet français / anglais, les mots composés étaient principalement basés sur l'anglais mais avec une saveur française (pas trop difficile car beaucoup de mots anglais sont français de toute façon), mais cela pourrait s'appliquer à n'importe quel mélange de langues.

par exemple

"quantité bois"

En anglais est "quantité de bois" ou "quantité de bois", en français est "quantité de bois", donc est assez proche pour les deux locuteurs. Cela devrait réduire le nombre de nouveaux mots que chaque locuteur doit apprendre

Quelle est la taille de votre domaine UL? Cela devient le problème. Si moins de 100 phrases clés sont utilisées, vous pouvez utiliser un langage de style hybride, si vous préférez, je vais coller le langage prédominant des développeurs, car ils doivent généralement le traiter plus intensément.

Publier un dictionnaire / dictionnaire des synonymes pour que tout le monde puisse s'y référer, au besoin, afin d'éviter toute excuse pour la compréhension

J'ai récemment travaillé sur un projet DDD en Suisse, où le domaine était celui des taxes (plus particulièrement la TVA et un autre type de taxe ... qui ne peut pas être traduit facilement en anglais ...).

Ils ont choisi la première option: UL en allemand, utilisé également dans le code en allemand.

Avant de travailler sur ce projet, j'avais exactement la même aversion que vous pour le code en plusieurs langues. J'aime (toujours) tout avoir en anglais, bien que je ne sois pas anglophone. Je ne suis pas non plus un locuteur allemand. Alors, quand j'ai commencé à explorer le code, j'étais horrifié.

Après un an de travail sur ce projet, je dois admettre que j’ai pensé que c’était la bonne décision dans ce cas (nous aurions aussi pu utiliser le français ou l’italien, les autres langues officielles suisses, mais la majorité des acteurs du projet étaient de langue allemande haut-parleurs).

Beaucoup de termes spécifiques du domaine n'étaient vraiment pas traduisibles en anglais de manière significative. De toute façon, je devais apprendre les termes allemands pour pouvoir communiquer avec le reste de l'équipe. Il aurait été plus compliqué d’apprendre aussi les traductions en anglais, qui auraient été inventées de toutes pièces.

Donc, je suppose que cela dépend vraiment du domaine. Certains domaines seront très difficiles à traduire en anglais et cela n’aura pas beaucoup de sens.

Cela dépend probablement aussi de la langue maternelle. L'allemand est une langue dans laquelle vous pouvez composer des mots à peu près de la même manière et surtout dans le même ordre qu'en anglais. Par exemple, une déclaration fiscale serait une déclaration Steuerdeklaration . Pas tellement différent.

Je ne sais pas comment je donnerais un nom de classe équivalent en français, par exemple, si le terme naturel était "déclaration d'impôts", avec l'ordre inverse et une préposition supplémentaire au milieu ... Et c'est juste un exemple simple. Je serais vraiment intéressé si quelqu'un a de l'expérience avec ce type de nommage en langues latines (français, espagnol, italien, portugais ...)!

Les formes plurielles constituaient un autre défi. En allemand, elles se distinguent parfois à peine du singulier (alors qu’en anglais, il ya presque toujours un s à la fin).

Les caractères accentués étaient acceptables, car en allemand ils ont tous un équivalent non accentué ( ü -> ue et ainsi de suite). C'est un autre point où les Français seraient plus problématiques ...