Dans quelle langue dois-je nommer mes cours d'affaires?

Je demande les meilleures pratiques avec cette question. Ce n'est un problème que si l'entreprise cliente est strictement nationale et a une langue maternelle autre que l'anglais, je pense.

Si le client a beaucoup d'expressions principalement très spécifiques au domaine (disons, allemand), mélangées à des noms moins spécifiques au domaine. La langue de nos commentaires de code, noms de classe / méthode / variable est l'anglais. Souhaitez-vous traduire tous les noms de domaine spécifiques?

Je travaille en Allemagne et je préfère choisir l'anglais.

Parfois, par exemple, des choses spécifiques au domaine, comme la création d'un module pour "DATEV" (logiciel de facturation / facturation allemand), j'utilise des noms allemands. Certains mots allemands ne peuvent pas être traduits correctement, par exemple "Referenzbuchungsnummer" (ReferenceBookingNum?) Ou "Sachkontenlaenge" (..?). Je pense aussi que les choses spécifiques au domaine se termineraient par une horreur de maintenance. Vous vous souviendrez peut-être que ReferenceBookingNum serait lié à "Referenzbuchungsnummer", mais qu'en est-il de vos collègues? Ils doivent étudier la documentation interne sur la dénomination, si la documentation existe. Ils ne seront pas très familiers avec le module sans avoir de noms propres. C'est une complexité inutile si tous les autres développeurs sont également allemands. Mais "CakeFactory" sonne beaucoup mieux que "KeksFabrik";)

Tout dépend donc.

Étant norvégien travaillant dans une entreprise norvégienne, je nomme mes objets en anglais. Bien sûr, certains mots ou concepts peuvent ne pas avoir d'équivalent en anglais et dans ce cas, on peut affirmer qu'un mot natif peut être utilisé à la place d'un mauvais remplacement ou d'une traduction littérale qui n'a pas de sens. Bien sûr, la plupart de ces problèmes pourraient être le fait que certains d'entre nous devraient avoir un meilleur vocabulaire, donc je demande généralement à un collègue si je ne peux pas penser à un bon nom anglais :)

Certains de nos employés ne sont pas norvégiens et donc écrire en anglais leur profite. Être en mesure d'embaucher des programmeurs de la plupart des pays européens est bon pour l'économie, donc mon entreprise en profite également.

BTW: Je me souviens avoir lu la source d'Hermes une fois (implémentation ebXML b2b) et j'aurais eu du mal s'ils avaient écrit et commenté en mandarin.

Je crois que puisque l'anglais est la lingua franca du domaine informatique, limiter votre code source à une autre langue crée des obstacles artificiels à son développement. Vous limitez d'abord le bassin de personnes pouvant contribuer à celles qui parlent une langue spécifique. La même raison que vous avez posée en échange de pile et non sur un site local.

Vous ne savez pas non plus d'où proviendront les contributions ni où elles iront. Et si vous utilisez un échantillon d'un site, allez-vous traduire cela? Que se passe-t-il si le produit se développe pour être utilisé par des clients dans un autre pays? Si vous avez besoin d'embaucher un entrepreneur / d'externaliser un peu? Pourquoi limiter à un seul pool et ne pas obtenir le meilleur ajustement du monde entier?

Peut supposer qu'il est OK pour certaines structures spécifiques à un domaine qui ne mappent pas facilement à d'autres langues ou si une base de code existante est maintenue.

Mon dernier objectif de projet était de modéliser le domaine commercial des garanties et des hypothèques. Tous les développeurs et l'entreprise pour laquelle nous avons travaillé sont originaires de Pologne. Nous avons construit le logiciel selon les principes de conception pilotée par domaine. Nous avons utilisé des noms polonais pour toutes les entités commerciales et je pense que c'était un très bon choix. Je pense que nous avons pu éviter les problèmes de communication grâce à cette approche. Le domaine des affaires comprenait de nombreux termes que je ne connaissais même pas en polonais, sans parler des traductions en anglais. Nous n'avons utilisé que des lettres latines et toutes les classes techniques ont été nommées en anglais.

Il est généralement plus facile de lire le code source écrit dans une seule langue. Cela pour la plupart des langages de programmation implique que vous devez l'écrire en anglais.

Cela dit, il existe un problème majeur avec les concepts de domaine qui ne se traduisent pas facilement en anglais. Un exemple typique est un identifiant unique que la société donne à l'individu - aux États-Unis, le concept le plus proche est le numéro de sécurité sociale, mais ce n'est pas une cartographie précise. Les noms et numéros de téléphone correspondent généralement assez bien.

Je pense qu'il est généralement nécessaire de conserver les termes du domaine chaque fois qu'une cartographie précise n'est pas facilement disponible en anglais, mais seulement ceux-ci - gardez le reste en anglais. Il en résultera des identifiants inhabituels comme KommuneImpl mais cela devrait avoir un sens immédiat pour ceux qui connaissent le domaine.

Projets de type open source / communauté internationale

La langue commune des projets open source et de la communauté internationale est l'anglais. Par exemple, la langue des sites Stack Exchange est l'anglais. Pour une accessibilité plus large, l'anglais doit être utilisé pour tous les noms de code et d'objet.

Projets commerciaux

La plupart des éditeurs de logiciels internationaux exigent que le code soit écrit en anglais. C'est le plus grand dénominateur commun, il est donc logique d'utiliser l'anglais comme moyen de créer de la cohérence.

De nombreuses sociétés régionales de logiciels écrivent dans leur langue maternelle. Tous ne suivent pas cette approche, mais cela a du sens de leur point de vue - ils utilisent le langage commun à tous leurs développeurs.

Nommer des objets métier

Le langage de codage de l'équipe doit être utilisé pour nommer les objets.
La priorité est que les développeurs puissent communiquer entre eux sur les objets et les exigences du projet. Si l'équipe écrit en français, les objets métier doivent être nommés en français. S'ils codent en anglais, nommez les objets en anglais.

Votre question ajoute une ride car le client parle une langue maternelle autre que le langage de codage de votre équipe. Vous devez toujours utiliser le langage de codage de votre équipe pour nommer les objets.
Lorsque les analystes commerciaux ou les développeurs doivent communiquer avec le client au sujet des objets métier spécifiques, une traduction au besoin du nom de l'objet du langage de codage vers le langage client peut être requise. D'après mon expérience, il est assez rare que j'aie parlé d'objets de code spécifiques avec le client, de sorte que la traduction dans le langage client n'a pas vraiment été nécessaire.

La seule exception à la règle de dénomination est lorsqu'un objet n'a pas d'autre terme suffisamment concis pour capturer l'intention de l'objet. OMI, c'est vraiment rare, mais ça peut arriver. En réalité cependant, c'est la même chose que les langues parlées font pour exprimer des concepts particuliers. " Facade " est à l'origine un terme français mais a été adapté par l'anglais afin d'exprimer le concept, et est un modèle de conception commun. " Schadenfreude " est un autre bon exemple d'un terme emprunté bien que je ne pense pas qu'il ait un schéma correspondant.