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:
- Écrivez le code reflétant la langue ubiquitaire dans la langue naturelle du domaine.
- Traduisez la langue ubiquitaire en anglais et arrêtez de communiquer dans la langue naturelle du domaine.
- 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.