На каком языке я должен назвать свои бизнес-классы?


29

Я запрашиваю лучшую практику с этим вопросом. Это проблема только в том случае, если компания-заказчик строго национальная, и родной язык, кроме английского, мне кажется.

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


11
Английский. Lingua Franca для программирования.
Рог

6
Одним из наиболее сложных в сообщениях об ошибках PHP имеет интересный поворот на иврите: unexpected T_PAAMAYIM_NEKUDOTAYIM. Видя это несколько раз в своей жизни, я не сомневаюсь, что нужно использовать английский.
Стефф

3
Есть ли в немецких доменных выражениях нестандартные символы (скажем, umulauts (sp?))? Если вы нанимаете программистов за пределами своего региона, они могут оказаться не в состоянии найти клавиатуру с необходимыми символами (у меня ее нет). Да, есть способы переключить «типизированный» язык, но я бы не хотел этого.
Заводная муза

2
Греческий - использование нелатинских алфавитов обеспечивает лучшую безопасность работы, чем клингон.
Уайетт Барнетт

3
@ X-Zero, выходящий за пределы обычного ASCII, открывает червя "какую кодировку мы используем". Обычно тебя кусают и больше туда не ходят.

Ответы:


16

Я работаю в Германии и предпочитаю выбирать английский.

Иногда, например, в предметных областях, таких как создание модуля для "DATEV" (немецкая программа для выставления счетов / выставления счетов), я использую немецкие имена. Некоторые немецкие слова не могут быть переведены должным образом, например, «Referenzbuchungsnummer» (ReferenceBookingNum?) Или «Sachkontenlaenge» (..?). Кроме того, я думаю, что конкретные вещи в домене закончатся ужасом обслуживания. Может быть, вы помните, что ReferenceBookingNum будет относиться к "Referenzbuchungsnummer", но как насчет ваших коллег? Они должны изучить внутреннюю документацию по именованию, если документация существует. Они не будут очень знакомы с модулем, не имея собственных имен. Это ненужная сложность, если все остальные разработчики тоже немецкие. Но "CakeFactory" звучит намного лучше, чем "KeksFabrik";)

Так что все зависит.


2
Этот ответ больше всего отражает мое личное мнение после прочтения других ответов. Особенно этот пункт: «Это ненужная сложность, если все остальные разработчики тоже немцы» при переводе всего.
Zeemee

1
@Mulmoth: «Это ненужная сложность, если все остальные разработчики тоже немцы» --- Как вы можете быть уверены, что в какой-то момент, через несколько лет, проект не будет передан на аутсорсинг другой стране? Как вы можете быть уверены, что не говорящий по-немецки разработчик не будет представлен в проекте в какой-то момент времени?
Коралловая Доу

5
@Coral Doe - я думаю, что новый / другой / сторонний разработчик уже должен копаться в сфере бизнеса и его конкретных выражений. Таким образом, имхо легче сопоставить то, что клиент (который все еще будет немецким) с именованными немецкими классами вместо плохо / неправильно переведенных английских имен.
Zeemee

2
Немецкие «вещи», связанные с выставлением счетов / налогами, никогда не будут переданы на аутсорсинг не говорящей по-немецки стране В университете кто-то сказал мне, что 85 процентов всех счетов / налоговых книг относятся к немецким законам и написаны на немецком языке. Мировой.
lurkerbelow

3
Я согласен, но одна проблема, которая почти всегда случается, состоит в том, что язык, используемый разработчиками, просачивается к пользователям и другим заинтересованным сторонам. Не как часть пользовательского интерфейса, а как вы говорите о проблемной области. Это неизбежно приведет к путанице, поскольку не все свободно владеют английским языком, как большинство разработчиков.
Милле Бессо

14

Будучи норвежцем, работая в норвежской компании, я называю свои объекты на английском языке. Конечно, некоторые слова или понятия могут не иметь английского аналога, и в этом случае можно утверждать, что родное слово может быть использовано вместо плохой замены или буквального перевода, который не имеет смысла. Конечно, многие из этих проблем могут заключаться в том, что у некоторых из нас должен быть лучший словарный запас, поэтому я обычно спрашиваю коллегу, не могу ли я придумать хорошее английское имя :)

Некоторые из наших сотрудников не являются норвежцами, и поэтому написание на английском языке приносит им пользу. Возможность нанять программистов из большей части Европы - это хорошо для экономики, поэтому моя компания тоже выигрывает от этого.

Кстати, я помню, что однажды прочитал источник Hermes (реализация ebXML b2b), и мне было бы трудно, если бы они написали и прокомментировали на китайском языке.


5
Почти отредактированный «колледж», как я полагаю, должен быть «коллегой», но я не был уверен, был ли он намеренным.
Джейкоб Шон

Конечно, я имел в виду коллегу :)
Sylwester

Of course some words or concepts might not have a English counterpart- Мне всегда любопытно, когда это возникает в программировании, почти как если бы вы знали шаблон дизайна, который не придумали бы только говорящие на английском языке. У вас есть быстрый пример?
Изката

5
@Izkata: вопрос был о бизнес- классах. Они чаще привязаны к специфическим для страны правилам и нормам. Например, если закон заставляет вас отслеживать местонахождение всех грузовиков с опасными химическими веществами, вы вполне могли бы назвать этот класс в честь этого закона.
MSalters

9

Я считаю, что поскольку английский является языком общения в области ИТ, ограничение исходного кода другим языком создает искусственные препятствия для его развития. Сначала вы ограничиваете круг людей, которые могут помочь тем, кто говорит на определенном языке. По той же причине, что вы просили в стеке, а не на локальном сайте.

Кроме того, вы не знаете, откуда поступят взносы и куда они пойдут. Что, если вы используете образец с сайта, вы будете переводить это? Что если продукт расширяется для использования клиентами в другой стране? Если вам нужно нанять подрядчика / аутсорсинг? Почему бы ограничиться одним пулом, а не получить наибольшую пригодность со всего мира?

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


9

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


4
Это хороший момент: если все знания предметной области даны на местном языке и не существует согласованных английских имен для понятий предметной области, использование местного языка может быть хорошей идеей.
Иоахим Зауэр

7

Как правило, легче читать исходный код, написанный на одном языке. Это для большинства языков программирования означает, что вы должны писать на английском языке.

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

Я считаю, что обычно необходимо сохранять доменные термины, когда точное сопоставление недоступно на английском языке, а только на тех, которые оставляют на английском. Это приведет к появлению необычных идентификаторов, таких как KommuneImpl, но это должно иметь непосредственный смысл для тех, кто знает домен.


2

Проекты с открытым исходным кодом / международным сообществом

Общим языком проектов с открытым исходным кодом и проектов международного сообщества является английский. Например, языком сайтов Stack Exchange является английский. Для большей доступности английский язык должен использоваться для всех кодов и имен объектов.

Коммерческие проекты

Большинство международных фирм-разработчиков программного обеспечения требуют написания кода на английском языке. Это самый большой общий знаменатель, поэтому имеет смысл использовать английский как средство для обеспечения согласованности.

Многие региональные софтверные фирмы пишут на родном языке. Не все придерживаются этого подхода, но это имеет смысл с их точки зрения - они используют общий язык для всех своих разработчиков.

Наименование бизнес-объектов

Язык кодирования команды должен использоваться для именования объектов.
Приоритетом для разработчиков является возможность общаться друг с другом относительно объектов и требований проекта. Если команда пишет по-французски, то бизнес-объекты должны быть названы по-французски. Если они кодируют на английском, то назовите объекты на английском.

Ваш вопрос добавляет морщинку, потому что клиент говорит на родном языке, отличном от языка программирования вашей команды. Вы все равно должны использовать язык кодирования вашей команды для именования объектов.
Когда бизнес-аналитикам или разработчикам необходимо общаться с клиентом о конкретных бизнес-объектах, может потребоваться перевод имени объекта с языка кодирования на язык клиента по мере необходимости. Из моего опыта довольно редко я говорил о конкретных объектах кода с клиентом, поэтому перевод обратно на язык клиента действительно не был необходим.

Единственным исключением из правила именования является случай, когда у объекта нет другого достаточно краткого термина, чтобы зафиксировать намерение объекта. ИМО, это действительно редко, но это может произойти. В действительности же разговорные языки делают то же самое, чтобы выразить определенные понятия. « Фасад » изначально был французским термином, но был адаптирован английским языком, чтобы выразить концепцию, и является общей моделью дизайна. « Schadenfreude » - еще один хороший пример заимствованного термина, хотя я не думаю, что у него есть соответствующий шаблон.


1
Ваш последний абзац полностью противоречит вашему первому, кажется
Джеймс

@ Джеймс - спасибо! Я удалил этот раздел, поскольку у меня нет времени, чтобы уточнить, что я имел в виду. Он должен был поддерживать, но неважно.

1
Сильно не согласен. Поскольку основные понятия практически всех языков, с которыми вы встречаетесь, написаны на английском языке, использование неанглоязычной терминологии приводит к менее разборчивому исходному коду. Ум постоянно должен прыгать между английским и другим языком. Код должен быть свободным и читаемым.
Майк Адлер

@MikeAdler - неясно, согласны ли вы с тем, что я предлагаю в качестве общего правила (назовите вещи на языке команды) или с исключением, которое должно быть очень редким.

Предоставляется. Я уточню: я не согласен с тем, что любой объект должен быть назван на любом другом языке, кроме английского. Ваш первый заголовок «Проекты с открытым исходным кодом / проекты международного сообщества» очень хорошо отражает мою точку зрения. Все после этого я не покупаю. Причина, как указано, заключается в ремонтопригодности, которая, по моему мнению, должна быть первостепенной задачей практически для каждого проектного решения (включая схему именования), которое вы принимаете.
Майк Адлер
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.