Якою мовою я повинен називати свої бізнес-класи?

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

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

Я працюю в Німеччині і вважаю за краще вибирати англійську.

Іноді, наприклад, для доменних речей, таких як створення модуля для "DATEV" (німецька накладна / програмне забезпечення для виставлення рахунків), я використовую німецькі імена. Деякі німецькі слова неможливо перекласти належним чином, наприклад, "Referenzbuchungsnummer" (ReferenceBookingNum?) Або "Sachkontenlaenge" (..?). Крім того, я думаю, що речі, що стосуються домену, закінчуватимуться жахом обслуговування. Можливо, ви пам'ятаєте, що ReferenceBookingNum стосуватиметься "Referenzbuchungsnummer", але як бути з вашими колегами? Вони повинні вивчити внутрішню документацію щодо іменування, якщо вона існує. Вони не будуть дуже добре знайомі з модулем без власних імен. Це зайва складність, якщо всі інші розробники теж німецькі. Але "CakeFactory" звучить набагато краще, ніж "KeksFabrik";)

Тож все залежить.

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

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

До речі: пам'ятаю, я прочитав джерело Hermes одного разу (реалізація ebXML b2b), і мені було б важко, якби вони написали та коментували на мандаринському.

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

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

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

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

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

Однак, існує велика проблема з доменними поняттями, які не легко перекласти на англійську мову. Типовим прикладом є унікальний ідентифікатор, який суспільство дає людині - у США найближчим поняттям є номер соціального страхування, але це не точне відображення. Імена та номери телефонів зазвичай досить добре відображаються.

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

Проекти з відкритим кодом / міжнародним співтовариством

Спільною мовою проектів з відкритим кодом та міжнародними спільнотами є англійська. Справа в тому, мова сайтів Stack Exchange - англійська. Для широкої доступності для всіх імен коду та об'єктів слід використовувати англійську мову.

Комерційні проекти

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

Багато регіональних програмних фірм пишуть рідною мовою. Не всі дотримуються такого підходу, але це має сенс з їхньої точки зору - вони використовують загальну мову для всіх своїх розробників.

Назви об’єктів бізнесу

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

Ваше запитання додає зморшок, оскільки клієнт розмовляє рідною мовою, відмінною від мови кодування вашої команди. Вам слід використовувати мову кодування вашої команди для назви об'єктів.
Коли бізнес-аналітикам або розробникам потрібно спілкуватися з клієнтом щодо конкретних бізнес-об'єктів, може знадобитися переклад назви об'єкта з мови кодування на мову клієнта. З мого досвіду, досить рідко я говорив про конкретні кодові об'єкти з клієнтом, тому переклад назад на мову клієнта насправді не потрібен.

Єдиним винятком із правила іменування є те, коли об’єкт не має іншого достатньо стислого терміна, який би захоплював наміри об'єкта. ІМО, це дійсно рідко, але воно може статися. Насправді ж це те саме, що розмовні мови роблять для вираження конкретних понять. " Фасад " спочатку є французьким терміном, але був адаптований англійською мовою, щоб виразити концепцію, і є загальною схемою дизайну. " Schadenfreude " - це ще один хороший приклад запозиченого терміну, хоча я не думаю, що він має відповідний зразок.