Переклад зовнішніх даних на мову, якою ви програмуєте

Я не впевнений, що робити з наступним:

Ми беремо дані із зовнішнього інструмента в межах власного інструменту. Ці дані написані голландською мовою. Ми пишемо наш код Java англійською мовою. Чи повинні ми тоді перекласти цю голландську на англійську чи зберегти її голландською? Наприклад, у нас є 2 відділи: Bouw (будівництво англійською мовою) та Onderhoud (технічне обслуговування англійською мовою).

То було б логічно створити:

public enum Department { BOUW, ONDERHOUD }

або:

public enum Department { CONSTRUCTION, MAINTENANCE }

або навіть:

public enum Afdeling { BOUW, ONDERHOUD }

(afdeling - кафедра голландською мовою)

У цьому сценарії я б залишив значення перерахувань голландською мовою:

public enum Department { BOUW, ONDERHOUD }

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

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

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

Тим не менш, ви можете просто прокоментувати код, якщо він допомагає іншим зрозуміти контекст даних:

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

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

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

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

Примітка. Ця порада стосується лише програмного коду . Дані користувача, безумовно, не слід перекладати, а обробляти "як є". Навіть якщо у вас є клієнт «Гольдштейн», явно не слід зберігати їх назву як «золотий камінь».

Проблема в тому, що існує континуум термінів між "наданими користувачем, не торкайтеся" та "фрагментом коду, користуйтеся англійською мовою завжди". Імена клієнтів дуже близькі до першого кінця спектру, а змінні Java - до другого. Константи enumзначень трохи далі, особливо якщо вони позначають відомі, унікальні зовнішні сутності (наприклад, ваші відділи). Якщо кожен у вашій організації використовує голландські терміни для департаментів, ви не плануєте конфліктувати когось із кодовою базою, хто цього не робить, і набір існуючих відділів змінюється рідко, то, використовуючи прийняті назви відділу, можна зробити більше сенс для констант enum, ніж для локальних змінних. Я все одно не хотів би цього робити.

Уникайте перекладу, де це можливо, тому що кожен переклад - це додаткові зусилля і може спричинити помилки.

Ключовий внесок «Дизайну, керованого доменом» в сучасній інженерії програмного забезпечення - це концепція всюдисущої мови , яка є єдиною мовою, що використовується всіма зацікавленими сторонами проекту. Згідно з 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 випадково кине людей сюди.

EDIT: Як зазначає 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;
    }
}

що також дозволить досягти цього ефекту.

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

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

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

Коли ви розробляєте свій код для моделювання домену, імена членів не повинні бути пов’язані з форматом серіалізації даних. Вони не повинні бути нідерландськими термінами, ні вони не повинні бути перекладами нідерландських термінів, але вони повинні бути те, що ви вирішите, найкраще відповідає доменній моделі.

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