Програмування та всюдисуща мова (DDD) у домені, що не є англійською

Я знаю, що тут вже є деякі питання, тісно пов'язані з цією темою, але жодне з них не бере всюдисущу мову як вихідну точку, тому я думаю, що це питання виправдовує.

Для тих, хто не знає: всюдисуща мова - це концепція визначення мови (як розмовної, так і письмової), яка однаковою мірою використовується для розробників та експертів домену, щоб уникнути невідповідностей та неправильної комунікації через проблеми перекладу та нерозуміння. Ви побачите ту саму термінологію, яка відображається в коді, розмовах між будь-яким членом команди, функціональними характеристиками та ін.

Отже, мені було цікаво, як поводитися з всюдисущою мовою в неанглійських доменах.

Особисто я дуже віддаю перевагу написанню коду програмування англійською мовою повністю, включаючи коментарі, але, звичайно, виключаючи константи та ресурси.

Однак у домені, що не є англійською, я змушений приймати рішення або про:

1. Напишіть код, що відображає всюдисущу мову на природній мові домену.
2. Перекладіть всюдисущу мову на англійську і перестаньте спілкуватися природною мовою домену.
3. Визначте таблицю, яка визначає, як всюдисуща мова перекладається на англійську.

Ось кілька моїх думок на основі цих варіантів:

1) У мене є сильна відраза до змішаного мовного коду, тобто кодування за допомогою імен типу / члена / змінних тощо, які не є англійською мовою. Більшість мов програмування значною мірою "дихають" англійською мовою, а більшість технічної літератури, назви шаблонів дизайну тощо також є англійською мовою. Тому в більшості випадків просто немає можливості повністю писати код не-англійською мовою, так що ви все одно змішані мови.

2) Це змусить експертів домену почати думати і говорити в англійському еквіваленті UL, що, мабуть, не прийде їм природно і тому значно заважає спілкуванню.

3) У цьому випадку розробники спілкуються з експертами домену рідною мовою, тоді як розробники спілкуються один з одним англійською мовою, а головне, вони пишуть код, використовуючи англійський переклад UL.

Я впевнений, що не хочу йти на перший варіант, і я думаю, що варіант 3 набагато кращий, ніж варіант 2. Що ви думаєте? Я пропускаю інші варіанти?

ОНОВЛЕННЯ

Сьогодні, приблизно через рік, щодня займаючись цим питанням, я повинен сказати, що варіант 3 для мене спрацював досить добре.

Це не було набридливо, як я спочатку побоювався і переклад у реальному часі під час розмови з клієнтом також не був проблемою.

На основі свого досвіду я також виявив такі переваги.

• Переклад UL змушує вас більше уваги приділяти визначенню UL та навіть самому домену, особливо коли ви не знаєте, як перекласти термін, і вам потрібно почати переглядати словники тощо. Це навіть змусило мене переглянути рішення щодо моделювання домену. декілька разів.
• Це допомагає зробити ваші знання англійської мови більш глибокими.
• Очевидно, що на ваш код набагато приємніше дивитися, замість того, щоб бути непристойною непристойністю.

Я часто стикався з цим питанням, і, на мою думку, відповідь такий: "Єдиної відповіді не існує для всіх сценаріїв".

Але майте на увазі, що всюдисуща мова сама по собі не є метою. Це інструмент для посилення комунікації між командою та експертами з доменів та забезпечення концептуальної узгодженості реалізованої моделі в коді, тестах та розмові.

Якщо ви можете говорити UL однозначно, ви на правильному шляху. Якщо ви та ваші колеги постійно перекладаєте з коду на розмову чи від концепції до концепції, то ви, мабуть, поза увагою.

На практиці не всі домени є рівними, ані експерти з доменів. Деякі домени так чи інакше володіють англійською термінологією (наприклад, керовані технологічними доменами), і це здається розумним для вибору повноцінного англійського вибору. Однак деякі культури можуть впливати на цей вибір (на думку французької), і розповсюдження англійської термінології залежить від країни до країни. У деяких інших областях (Юридичний, щоб назвати його) немає способу перекласти деякі терміни. Інакше переклад ускладнить домен експерту абсолютно важче за розмовою.

Загалом, нас більше цікавить, що може сказати експерт з питань домену. Тож ми хочемо полегшити їм справи. Інакше вони могли просто взяти клас UML і прочитати наші діаграми (це був жарт). Тож єдина реальна рекомендація тут: "зверніть увагу на поведінку експерта домену", якщо вони беруть участь у розмові, і розмова йде безперебійно, ви, ймовірно, дотримуєтесь, дотримуйтесь цієї мови. Це може викликати трохи додаткової роботи в команді, але це добре. Як розробники ми дещо навчені вивчати слова з конкретним значенням у контексті.

Як не дивно, це питання завжди супроводжується припущенням, що весь код повинен говорити однією мовою. Це теж може бути оскарженим. Я не є рідною англійською, і знання іноземної мови не є рівним: мій мозок швидко йде, коли говорять про ім’я , прізвище , машину тощо, пропускає деякі деталі, коли говорити про поштовий індекс , гальмує, коли розмовляє про позику і обов'язково запитує для заспокійливого пояснення, коли йдеться про іпотеку .

Отже, знову ж таки, виберіть найкращу комбінацію, яка дозволить зробити ключовий потік розмови та забезпечить максимальну кількість інформації та відгуків від експерта домену.

Я зазвичай вважаю певні технічні слова нейтральними до мови, навіть якщо є переклад на іншу мову.

Наприклад, коли говорити про кодування німецькою мовою, я все ще використовую англійський технічний словник так, ніби вони були німецькими словами, навіть якщо є німецький еквівалент.

У вашому випадку я зробив би навпаки. Імпортуйте певні технічні слова з рідної мови англійською мовою так само, як іноземні слова були імпортовані століттями. Змусити їх граматично вести себе як англійські слова. Спочатку це дивно, але ти звикнеш до цього.

Я погоджуюсь з коментарями англійської мови , які більшість мов програмування "дихають" , що завжди стає проблемою з багатомовних зусиль з розвитку

Як правило, я мав би UL на мові вашої команди програмування

Ми робили те, що ми складали нові слова, які краще виражають доменні теми. У французькому / англійському проекті складені слова, де переважно англійська, але з французьким присмаком (не дуже важко, оскільки багато англійських слів є французькими), але це може стосуватися будь-якої мовної суміші

напр

"кількість"

Англійською мовою є "Кількість деревини" або "кількість деревини", французькою мовою є "quantité de bois", тому достатньо близько для обох носіїв мови. Це повинно зменшити кількість нових слів, які повинен вивчити кожен оратор

Наскільки великий ваш домен UL? Це стає проблемою. Якщо це менше 100 ключових фраз, то ви можете використовувати гібридну мову, створену в стилі, якщо більше, я б дотримувався переважаючої мови розробників, оскільки їм зазвичай доводиться інтенсивніше боротися з нею.

Опублікуйте словник / тезаурус вікі, щоб усі також посилалися на необхідні події, щоб не було виправдань для розуміння

Нещодавно я працював над проектом DDD у Швейцарії, чи була сфера податків (зокрема ПДВ та інший вид податку ... що не легко перекладається на англійську ...).

Вони обрали перший варіант: UL німецькою мовою, використовується в коді і німецькою мовою.

Перш ніж я працював над цим проектом, я мав абсолютно таку ж неприязнь, як і ви до змішаного мовного коду. Мені (досі) подобається мати все англійською мовою, хоча я не є носієм англійської мови. Я також не є носієм німецької мови. Тож коли я почав досліджувати кодову базу, я жахнувся.

Після року роботи над цим проектом я мушу визнати, що я вважаю, що це було правильним рішенням у цій справі (ми також могли використовувати французьку чи італійську, інші офіційні швейцарські мови, але більшість учасників проекту були рідною німецькою динаміки).

Багато конкретних термінів домену насправді не можна було перекладати англійською мовою змістовно. Мені довелося навчитися німецьким термінам, щоб спілкуватися з рештою команди. Мені було б важче також вивчити англійські переклади, які все одно були б винайдені з повітря.

Тож я думаю, це дійсно залежить від домену. Деякі домени буде важко перекласти на англійську, і це не матиме особливого сенсу.

Це, мабуть, залежить і від рідної мови. Німецька мова - це ти, коли ти можеш складати слова приблизно таким же чином і особливо в тому ж порядку, що і англійською. Наприклад, податкова декларація була б Steuerdeklaration . Не шокуюче відрізняється.

Я не знаю, як я зробив би еквівалентну назву класу французькою мовою, наприклад, якби природним терміном було б "декларування d'impôts", з протилежним порядком та додатковим прийменником посередині ... І це просто простий приклад. Мені було б дуже цікаво, якщо хтось має досвід подібного іменування латинськими мовами (французькою, іспанською, італійською, португальською ...)!

Іншою проблемою були форми множини, які на німецькому мовою іноді є ледь відрізняються від однини ( в той час як в англійській мові це майже завжди має S в кінці).

Наголошені символи були в порядку, оскільки в німецькій мові всі вони мають не наголошений еквівалент ( ü -> ue тощо). Це ще один момент, коли французи були б більш проблемними ...