Соглашения об именах: в поисках альтернативы смешиванию английских терминов и терминов домена / рабочего процесса

Question

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

Какой у вас опыт по этой теме? Вы избегаете глупых имен в коде всеми средствами или просто живете с этим?

Answer 1

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

ИМО все термины домена должны оставаться на родном языке, как и документация и комментарии. Это позволяет разработчикам сосредоточиться на логике кода, а не на проблемах перевода. Может показаться глупым иметь сочетание двух языков в коде, даже в пределах имен отдельных методов, но IMO это на самом деле не проблема, и лучше, чем прилагать большие усилия, чтобы иметь все на английском, когда никто на самом деле не извлекает из этого пользу.

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

Answer 2

У нас точно такая же проблема в нашей компании. Мы пытаемся написать код и примеры на английском языке, но мы часто находим неразрешимые ситуации, когда прямые общие имена на нашем родном языке не имеют прямого или неизвестного перевода или эквивалентности. Так что, с моей точки зрения, почти невозможно избежать смешения языков (будет ли Spanglish языком будущего, несмотря на мою волю?).

В основном это вопрос двух вещей:

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

Эффекты этого:

• Комментарии не могут быть понятны носителям английского языка (поскольку используемые слова не существуют или предложения являются буквальным переводом с исходного языка).
• Неправильные переводы, полные фальшивых друзей или придуманных слов. Типичным примером этого было бы использование «фактического» слова для «текущего» значения, поскольку именно оно означает «фактический» на испанском языке.

Фактическое решение этой проблемы - попытаться исправить это, чтобы атаковать источник проблемы:

• Тренинги английского языка (включая прикладной технический английский) должны быть обязательными в компании, чтобы каждый работник мог достичь минимально приемлемого уровня знаний английского языка.
• Заставьте не слишком совершенных людей следовать некоторым правилам кодирования путем определения таблицы стилей кода или, что еще лучше, иметь отдел контроля качества, обеспечивающий качество кода, грамматику комментариев и удобочитаемость.

Answer 3

У меня нет опыта с этим, так как я носитель английского языка. Однако, когда домен сложный, Extreme Programming предлагает использовать метафору, которая удобна для программистов и клиентов.

Это может быть применено в вашей ситуации.