外部データをプログラミング中の言語に翻訳する

私は次のことをどうしたらいいかわかりません：

独自のツール内の外部ツールからデータを取得します。このデータはオランダ語で書かれています。Javaコードを英語で書いています。次に、このオランダ語を英語に翻訳するか、オランダ語のままにする必要がありますか？たとえば、2つの部門があります：Bouw（英語の建設）とOnderhoud（英語の保守）。

作成するのは論理的ですか？

public enum Department { BOUW, ONDERHOUD }

または：

public enum Department { CONSTRUCTION, MAINTENANCE }

あるいは：

public enum Afdeling { BOUW, ONDERHOUD }

（アフェデリングはオランダ語の学科です）

このシナリオでは、列挙値をオランダ語のままにします。

public enum Department { BOUW, ONDERHOUD }

これらの定数を使用するロジックは、オランダ語のデータとも一致するためです。たとえば、入力が「bouw」の場合、比較コードは次のようになります。

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

値が一致する場合（値の意味がわからなくても）デバッグが簡単になります。翻訳はメンタルフープを追加するだけです。開発者として、正しいことを証明するために飛び越す必要はありません。

それでも、他の人がデータのコンテキストを理解するのに役立つ場合は、コードにコメントするだけで済みます。

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

英語は、理由により共通語/最低公約数です。理由が「誰もがやる」ほど概念的に弱いとしても、それはまだかなり重要な理由です。

一般的な慣習に反するということは、ソフトウェアのデータ構造を理解するためにオランダ語を理解する必要があることを意味します。オランダ語には何の問題もありませんが、コードベースとやり取りする必要がある特定のエンジニアがそれを話す確率は、英語の場合よりも低くなります。

あなたはオランダのみのお店だし、国際展開する予定がない場合を除きしたがって、これまでに、それはあなたのコードベースの単一言語を維持し、最も人気のあるコーディング言語を使用するために、ほとんど常に良い考えです。

注：このアドバイスは、プログラムコードにのみ適用されます。ユーザーデータは間違いなく翻訳されるべきではありませんが、「そのまま」処理されます。顧客 "Goldstein"を持っている場合でも、その名前を "金色の石"として保存しないでください。

問題は、「ユーザー指定、触らない」と「コードの断片、常に英語を使用する」という用語の連続体があることです。顧客名はスペクトルの前端に非常に近く、Java変数は後端に近い。enum値の定数は、特によく知られた一意の外部エンティティ（部門など）を示す場合は特に少し離れています。組織内の全員が部門にオランダ語の用語を使用している場合、そうしないコードベースを誰かと対決する予定はなく、既存の部門のセットはめったに変更されないので、受け入れられた部門名を使用するとより多くのことができますローカル変数よりも列挙定数の意味。しかし、私はまだそれをしません。

すべての翻訳は追加の作業であり、バグが発生する可能性があるため、可能な限り翻訳を避けてください。

最新のソフトウェアエンジニアリングに対する「ドメイン駆動設計」の重要な貢献は、プロジェクトのすべての利害関係者が使用する単一言語であるユビキタス言語の概念です。DDDによれば、翻訳はチーム内（仕様文書のプロキシのみで存在する場合でもドメイン専門家を含む）ではなく、チーム間でのみ行う必要があります（詳細はエリックエバンスによる「ドメイン駆動設計」、特に章ユビキタス言語と戦略的設計について）。

つまり、ビジネスの専門家（または仕様文書）がオランダ語を話す場合、ソースコードでビジネス上の懸念を表現するときに（オランダ語）の用語を使用します。不必要に英語に翻訳しないでください。そうすると、ビジネスの専門家とプログラマーの間のコミュニケーションに人為的な障害が生じ、時間がかかり、（あいまいな翻訳または不適切な翻訳によって）バグを引き起こす可能性があります。

対照的に、ビジネスの専門家が英語とオランダ語の両方でビジネスについて話すことができる場合、プロジェクトのユビキタス言語を選択できるという幸運な状況にあり、英語を好む正当な理由があります（「国際的に理解しやすい」標準で使用される可能性が高い」）が、そうすることは、コーダーがビジネスの人々が話していることを翻訳する必要があることを意味しない。代わりに、ビジネスマンは言語を切り替える必要があります。

要件が複雑で正確に実装する必要がある場合、ユビキタス言語を使用することは特に重要です。CRUDを実行するだけであれば、内部で使用する言語の重要性は低くなります。

個人的な逸話：私は、いくつかのビジネスサービスをSOAPエンドポイントとして公開するプロジェクトに参加しました。このビジネスは完全にドイツ語で指定されており、特定の管轄区域に固有の法的事項に関するものであるため、英語のように再利用される可能性は低い。それでも、象牙の塔の設計者の中には、将来の再利用を促進するために、SOAPインターフェースを英語にすることを義務付けている人もいます。この翻訳は一時的に行われ、開発者間の調整はほとんど行われていませんが、用語集だけで共有されていたため、Webサービス契約で同じビジネス用語がいくつかの名前を持ち、Webサービス契約でいくつかのビジネス用語が同じ名前になりました。ああ、もちろん、いくつかの名前は、境界線の両側で使用されていますが、意味は異なります！

とにかく翻訳することを選択する場合は、用語集で翻訳を標準化し、その用語集への準拠を完了の定義に追加し、レビューで確認してください。これまでのように不注意にしないでください。

正しい解決策は、部門をまったくハードコーディングしないことです。

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 }

ユーザーまたは何かを表示する文字列表現が必要な場合は、enum内で記述配列を定義し、メソッドを公開するだけです。
例：Department.BUILD.getDescription();「BOUW」を出力します

public enum Department { 
    BUILD,
    MAINTENANCE;

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

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

別の方法で選択したことは知っていますが、万が一Google vortexが偶然ここに人を投げた場合に備えて。

編集：Pokechu22で述べたように、次のように列挙コンストラクターとプライベートプロパティを使用できます。

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

    private final String description;

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

    public String getDescription() {
        return description;
    }
}

また、その効果を達成します。

コードの特定の不変式が保持されることが期待されています。これらの不変条件の1つは、識別子の名前が変更されてもプログラムの動作が変わらないことです。特にこの場合、列挙型があり、その列挙型のメンバーの名前を変更し、そのメンバーのすべての使用を更新すると、コードが異なる機能を開始することは期待できません。

解析は、データを読み取り、そこからデータ構造を導出するプロセスです。外部データを取得して読み取り、列挙のインスタンスを作成すると、データを解析します。その解析プロセスは、データ表現の受け取り方法と、データ型のメンバーの形状と命名との関係を維持するプログラムの唯一の部分です。

そのため、enumのメンバーにどの名前を割り当てるかは重要ではありません。読み取ったデータで使用されている文字列と偶然一致することは偶然です。

ドメインをモデル化するコードを設計するとき、メンバーの名前はデータのシリアル化形式に関係しないようにする必要があります。オランダ語の用語でも、オランダ語の用語の翻訳でもないはずですが、ドメインモデルに最も適していると判断したものでなければなりません。

パーサーは、データ形式とドメインモデルを変換します。これが、データ形式がコードに与える最後の影響です。