Перевод внешних данных на язык программирования

Я не уверен, что делать со следующим:

Мы берем данные из внешнего инструмента в нашем собственном инструменте. Эти данные написаны на голландском языке. Мы пишем наш Java-код на английском языке. Должны ли мы затем перевести этот голландский на английский или оставить его на голландском? Например, у нас есть 2 отдела: Bouw (строительство на английском языке) и Onderhoud (обслуживание на английском языке).

Тогда было бы логично создать:

public enum Department { BOUW, ONDERHOUD }

или:

public enum Department { CONSTRUCTION, MAINTENANCE }

или даже:

public enum Afdeling { BOUW, ONDERHOUD }

(afdeling - это отдел на голландском языке)

В этом сценарии я бы оставил значения enum на голландском:

public enum Department { BOUW, ONDERHOUD }

Потому что логика, использующая эти константы, будет сопоставляться с данными на голландском языке . Например, если ввод «bouw», код сравнения может выглядеть так:

if (Department.BOUW == input.toUpper())

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

Тем не менее, вы можете просто прокомментировать код, если он помогает другим понять контекст данных:

public enum Department { 
    BOUW, /* build */
    ONDERHOUD /* maintenance */
}

Английский является лингва франка / наименьший общий знаменатель по причине. Даже если причина концептуально так же слаба, как «Все так делают», это все же довольно важная причина.

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

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

Примечание. Этот совет относится только к коду программы . Пользовательские данные не должны определенно переводиться, а обрабатываться «как есть». Даже если у вас есть клиент «Goldstein», очевидно, что вы не должны хранить его имя как «золотой камень».

Беда в том, что между терминами «пользователь, не трогай» и «фрагмент кода, всегда используй английский язык» существует целый ряд терминов. Имена клиентов очень близки к первому концу спектра, а переменные Java - ко второму концу. Константы enumзначений находятся немного дальше, особенно если они обозначают известные, уникальные внешние объекты (например, ваши отделы). Если все в вашей организации используют голландские термины для отделов, вы не планируете ставить кого-то в негодность с кодовой базой, а набор существующих отделов меняется редко, тогда использование принятых названий отделов может сделать больше смысл для констант перечисления, чем для локальных переменных. Я все еще не сделал бы это, все же.

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

Ключевым вкладом «Domain Driven Design» в современную разработку программного обеспечения является концепция повсеместно распространенного языка , который является единственным языком, используемым всеми заинтересованными сторонами проекта. Согласно DDD, перевод не должен происходить внутри команды (которая включает экспертов по предметной области, даже если она представлена ​​только через прокси-документ спецификации), а только между командами (далее: Эрик Эванс, Эрик Эванс, в частности главы "Проект, управляемый доменом") о вездесущем языке и стратегическом дизайне).

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

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

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

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

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

Правильное решение заключается в том, чтобы вообще не кодировать отделы:

ArrayList<String> departments = (... load them from a configuration file ...)

Или, если вам абсолютно необходим тип отдела:

class Department { String name; Department(String name) { this.name = name; } ... }
HashMap<String, Department> = (... generate from configuration file ...)

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

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

/** The possible departments of a project, given in the Dutch language. */
public enum Department { BOUW, ONDERHOUD }

Если вас беспокоит наличие строкового представления для отображения пользователя или чего-то еще, просто определите массив описаний внутри вашего перечисления и предоставьте метод.
Например: Department.BUILD.getDescription();будет выводить "BOUW"

public enum Department { 
    BUILD,
    MAINTENANCE;

    private String[] descriptions = new String[] {
        "BOUW",
        "ONDERHOUD"
    };

    public String getDescription() {
        return descriptions[ordinal()];
    }
}

Я знаю, что вы выбрали иначе, но на всякий случай вихрь Google бросает людей сюда случайно.

РЕДАКТИРОВАТЬ: Как отметил Pokechu22 вы можете использовать конструкторы enum и частные свойства, как это:

public enum Department {
    BUILD("BOUW"),
    MAINTENANCE("ONDERHOUD");

    private final String description;

    private Department(String description) {
        this.description = description;
    }

    public String getDescription() {
        return description;
    }
}

который также достигнет этого эффекта.

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

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

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

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

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