Menerjemahkan data eksternal ke bahasa tempat Anda pemrograman

Saya tidak yakin apa yang harus dilakukan dengan hal berikut:

Kami mengambil data dari alat eksternal di dalam alat kami sendiri. Data ini ditulis dalam bahasa Belanda. Kami sedang menulis kode Java kami dalam bahasa Inggris. Haruskah kita menerjemahkan bahasa Belanda ini ke bahasa Inggris atau tetap menggunakan bahasa Belanda? Misalnya, kami memiliki 2 departemen: Bouw (Konstruksi dalam bahasa Inggris) & Onderhoud (Pemeliharaan dalam bahasa Inggris).

Maka apakah logis untuk membuat:

public enum Department { BOUW, ONDERHOUD }

atau:

public enum Department { CONSTRUCTION, MAINTENANCE }

atau bahkan:

public enum Afdeling { BOUW, ONDERHOUD }

(Afdeling adalah Department in Dutch)

Dalam skenario ini, saya akan meninggalkan enum nilai-nilai di Belanda:

public enum Department { BOUW, ONDERHOUD }

Karena logika menggunakan konstanta ini akan cocok dengan data yang juga dalam bahasa Belanda . Misalnya, jika inputnya adalah "bouw", kode perbandingannya mungkin terlihat seperti:

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

Saya merasa lebih mudah untuk men-debug ketika nilainya cocok (bahkan jika saya tidak tahu apa artinya nilainya). Penerjemahan hanya menambahkan lingkaran mental I, sebagai pengembang, seharusnya tidak harus melewati untuk membuktikan kebenaran.

Namun demikian, Anda bisa mengomentari kodenya jika itu membantu orang lain memahami konteks data:

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

Bahasa Inggris adalah lingua franca / penyebut umum terendah karena suatu alasan. Bahkan jika alasannya secara konseptual selemah "Semua orang melakukannya", itu masih merupakan alasan yang agak penting.

Melawan praktik umum berarti Anda harus memahami bahasa Belanda untuk memahami struktur data dalam perangkat lunak Anda. Tidak ada yang salah dengan bahasa Belanda, tetapi probabilitas bahwa setiap insinyur yang diberikan harus berinteraksi dengan basis kode berbicara itu masih lebih rendah daripada itu untuk bahasa Inggris.

Oleh karena itu, kecuali Anda seorang Belanda hanya berbelanja, dan tidak berencana untuk memperluas internasional pernah , hampir selalu ide yang baik untuk menjaga monolingual basis kode Anda, dan menggunakan bahasa pengkodean yang paling populer.

Catatan: Saran ini hanya berlaku untuk kode program . Data pengguna seharusnya tidak diterjemahkan, tetapi diproses "sebagaimana adanya". Bahkan jika Anda memiliki pelanggan "Goldstein", jelas Anda tidak boleh menyimpan nama mereka sebagai "batu emas".

Masalahnya adalah ada kontinum istilah antara "yang disediakan pengguna, jangan sentuh" ​​dan "fragmen kode, gunakan bahasa Inggris setiap saat". Nama pelanggan sangat dekat dengan ujung spektrum sebelumnya, variabel Java di dekat ujung spektrum. Konstanta untuk enumnilai sedikit lebih jauh, terutama jika mereka menunjukkan entitas eksternal yang terkenal dan unik (seperti departemen Anda). Jika semua orang di organisasi Anda menggunakan istilah Belanda untuk departemen, Anda tidak berencana menghadapi siapa pun dengan basis kode yang tidak, dan set departemen yang ada jarang berubah, maka menggunakan nama-nama departemen yang diterima dapat membuat lebih banyak akal untuk konstanta enum daripada variabel lokal. Saya masih tidak akan melakukannya.

Hindari terjemahan jika memungkinkan, karena setiap terjemahan adalah upaya tambahan dan dapat menimbulkan bug.

Kontribusi utama "Desain Didorong Domain" untuk rekayasa perangkat lunak modern adalah konsep Bahasa yang Dapat Ditebak , yang merupakan bahasa tunggal yang digunakan oleh semua pemegang saham suatu proyek. Menurut DDD, terjemahan tidak boleh terjadi dalam tim (yang mencakup pakar domain, bahkan jika hanya hadir dengan proksi dokumen spesifikasi), tetapi hanya antar tim (bacaan lebih lanjut: "Desain Didorong Domain" oleh Eric Evans, khususnya bab-bab tentang Bahasa yang Tidak Disadari dan desain strategis).

Yaitu, jika pakar bisnis Anda (atau dokumen spesifikasi Anda) berbicara bahasa Belanda, gunakan terminologi (Belanda) mereka saat mengungkapkan kekhawatiran bisnis dalam kode sumber. Jangan menerjemahkan ke dalam bahasa Inggris dengan sia-sia, karena hal itu menciptakan hambatan buatan untuk komunikasi antara pakar bisnis dan programmer, yang membutuhkan waktu dan dapat (melalui terjemahan yang ambigu atau buruk) menyebabkan bug.

Sebaliknya, jika para pakar bisnis Anda dapat berbicara tentang bisnis mereka dalam bahasa Inggris dan Belanda, Anda berada dalam situasi yang menguntungkan untuk dapat memilih bahasa di mana-mana proyek, dan ada alasan yang sah untuk memilih bahasa Inggris (seperti "dapat dipahami secara internasional dan lebih mungkin digunakan oleh standar "), tetapi melakukan itu tidak berarti bahwa pembuat kode harus menerjemahkan apa yang dibicarakan oleh para pelaku bisnis. Sebaliknya, para pebisnis harus beralih bahasa.

Memiliki bahasa di mana-mana sangat penting jika persyaratannya rumit dan harus diterapkan dengan tepat, jika Anda hanya melakukan CRUD, bahasa yang Anda gunakan kurang penting secara internal.

Anekdot pribadi: Saya sedang dalam proyek di mana kami mengekspos beberapa layanan bisnis sebagai titik akhir SOAP. Bisnis itu sepenuhnya ditentukan dalam bahasa Jerman, dan tidak mungkin digunakan kembali seperti dalam bahasa Inggris, karena ini menyangkut masalah hukum khusus untuk wilayah hukum tertentu. Namun demikian, beberapa arsitek menara gading mengamanatkan bahwa antarmuka SOAP menjadi bahasa Inggris untuk mempromosikan penggunaan kembali di masa depan. Terjemahan ini terjadi di hoc, dan dengan sedikit koordinasi di antara para pengembang, belum satu pun glosarium bersama, menghasilkan istilah bisnis yang sama dengan beberapa nama dalam kontrak layanan web, dan beberapa istilah bisnis memiliki nama yang sama dalam kontrak layanan web. Oh, dan tentu saja beberapa nama yang digunakan di kedua sisi membagi - tetapi dengan makna yang berbeda!

Jika Anda tetap memilih untuk menerjemahkan, harap distandarkan terjemahan dalam glosarium, tambahkan kepatuhan dengan glosarium tersebut pada definisi selesai, dan periksa di ulasan Anda. Jangan ceroboh seperti sebelumnya.

Solusi yang benar adalah dengan tidak melakukan hard-code pada departemen sama sekali:

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

Atau, jika Anda benar-benar membutuhkan jenis departemen:

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

Jika Anda merasa perlu menguji terhadap departemen tertentu dalam kode Anda, Anda harus bertanya secara lebih umum apa yang istimewa tentang departemen itu, dan menerima mengonfigurasi departemen itu sebagai memiliki properti itu. Misalnya, jika satu departemen memiliki daftar gaji mingguan, dan itulah yang diperhatikan oleh kode, harus ada properti WEEKLY_PAYROLL yang dapat dilampirkan ke departemen mana pun dengan konfigurasi.

Untuk setiap orang yang bertanya-tanya: kami telah memilih untuk opsi pertama, terutama karena kami pikir Anda tidak boleh membuat istilah untuk menerjemahkan. Namun, jika suatu saat, pengembang internasional akan mengerjakan proyek, kami telah menambahkan beberapa dokumentasi untuk menjelaskannya:

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

Jika Anda khawatir memiliki representasi string untuk ditampilkan kepada pengguna atau sesuatu, cukup tentukan array deskripsi di dalam enum Anda dan paparkan sebuah metode.
Misalnya: Department.BUILD.getDescription();akan menampilkan "BOUW"

public enum Department { 
    BUILD,
    MAINTENANCE;

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

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

Saya tahu Anda memilih sebaliknya, tetapi kalau-kalau google vortex melempar orang ke sini secara tidak sengaja.

EDIT: Seperti dicatat oleh Pokechu22 Anda dapat menggunakan enum konstruktor dan properti pribadi seperti ini:

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

    private final String description;

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

    public String getDescription() {
        return description;
    }
}

yang juga akan mencapai efek itu.

Invarian tertentu dari kode Anda diharapkan berlaku. Salah satu invarian itu adalah bahwa suatu program tidak akan berperilaku berbeda ketika pengenal diubah namanya. Dalam hal ini khususnya, ketika Anda memiliki enum, dan Anda mengganti nama setiap anggota enum itu, dan memperbarui semua penggunaan anggota itu, Anda tidak akan mengharapkan kode Anda untuk mulai berfungsi secara berbeda.

Parsing adalah proses membaca data dan memperoleh struktur data darinya. Saat Anda mengambil data eksternal, membacanya, dan membuat instance enum Anda, Anda mengurai data. Proses parsing itu adalah satu-satunya bagian dari program Anda yang bertanggung jawab untuk menjaga hubungan antara representasi data bagaimana Anda menerimanya, dan bentuk serta penamaan anggota tipe data Anda.

Dengan demikian, tidak masalah apa nama yang Anda tetapkan untuk anggota enum. Bahwa mereka kebetulan bertepatan dengan string yang digunakan dalam data yang Anda baca adalah kebetulan.

Saat Anda merancang kode untuk memodelkan domain, nama anggota tidak boleh terkait dengan format serialisasi data. Seharusnya bukan istilah Belanda, atau terjemahan bahasa Belanda, tetapi harus sesuai dengan model domain yang Anda pilih.

Pengurai daripada menerjemahkan antara format data dan model domain Anda. Itulah pengaruh terakhir yang harus dimiliki format data pada kode Anda.