Programming and Ubiquitous Language (DDD) dalam domain non-Inggris

Saya tahu ada beberapa pertanyaan yang sudah ada di sini yang terkait erat dengan subjek ini tetapi tidak satupun dari mereka mengambil Bahasa Ubiquitous sebagai titik awal jadi saya pikir itu membenarkan pertanyaan ini.

Bagi mereka yang tidak tahu: Bahasa Ubiquitous adalah konsep mendefinisikan bahasa (baik lisan maupun tulisan) yang sama-sama digunakan di seluruh pengembang dan pakar domain untuk menghindari inkonsistensi dan miskomunikasi karena masalah terjemahan dan kesalahpahaman. Anda akan melihat terminologi yang sama muncul dalam kode, percakapan antara anggota tim, spesifikasi fungsional dan yang lainnya.

Jadi, yang ingin saya tanyakan adalah bagaimana cara berurusan dengan Bahasa Ubiquitous dalam domain non-Inggris.

Secara pribadi, saya sangat suka menulis kode pemrograman dalam bahasa Inggris sepenuhnya, termasuk komentar tetapi tentu saja tidak termasuk konstanta dan sumber daya.

Namun, dalam domain non-Inggris, saya terpaksa membuat keputusan untuk:

1. Tulis kode yang mencerminkan Bahasa Ubiquitous dalam bahasa alami domain.
2. Menerjemahkan Bahasa yang Dapat Diketahui ke Bahasa Inggris dan berhenti berkomunikasi dalam bahasa alami domain.
3. Tentukan tabel yang menentukan bagaimana Bahasa Ubiquitous diterjemahkan ke Bahasa Inggris.

Berikut adalah beberapa pemikiran saya berdasarkan opsi-opsi ini:

1) Saya memiliki keengganan yang kuat terhadap kode bahasa campuran, yaitu pengkodean menggunakan tipe / anggota / nama variabel dll yang bukan bahasa Inggris. Sebagian besar bahasa pemrograman 'menghirup' bahasa Inggris untuk sebagian besar dan sebagian besar literatur teknis, nama-nama pola desain dll dalam bahasa Inggris juga. Oleh karena itu, dalam kebanyakan kasus tidak ada cara untuk menulis kode sepenuhnya dalam bahasa non-Inggris sehingga Anda tetap menggunakan bahasa campuran.

2) Ini akan memaksa para ahli domain untuk mulai berpikir dan berbicara dalam bahasa Inggris yang setara dengan UL, sesuatu yang mungkin tidak akan datang secara alami kepada mereka dan karena itu menghambat komunikasi secara signifikan.

3) Dalam hal ini, para pengembang berkomunikasi dengan para ahli domain dalam bahasa asli mereka sementara para pengembang berkomunikasi satu sama lain dalam bahasa Inggris dan yang paling penting, mereka menulis kode menggunakan terjemahan bahasa Inggris dari UL.

Saya yakin saya tidak ingin menggunakan opsi pertama dan saya pikir opsi 3 jauh lebih baik daripada opsi 2. Bagaimana menurut Anda? Apakah saya kehilangan opsi lain?

MEMPERBARUI

Hari ini, sekitar setahun kemudian, setelah menangani masalah ini setiap hari, saya harus mengatakan bahwa opsi 3 telah bekerja dengan cukup baik untuk saya.

Itu tidak membosankan seperti pada awalnya saya takut dan menerjemahkan secara real time sambil berbicara dengan klien juga tidak masalah.

Saya juga menemukan keuntungan berikut ini benar, berdasarkan pengalaman saya.

• Menerjemahkan UL membuat Anda lebih memperhatikan definisi UL dan bahkan domain itu sendiri, terutama ketika Anda tidak tahu bagaimana menerjemahkan istilah dan Anda harus mulai mencari melalui kamus dll. Ini bahkan telah menyebabkan saya untuk mempertimbangkan kembali keputusan pemodelan domain beberapa kali.
• Ini membantu Anda membuat pengetahuan Anda tentang bahasa Inggris lebih mendalam.
• Jelas, kode Anda jauh lebih menyenangkan untuk dilihat daripada menjadi kecabulan yang membingungkan.

Saya sudah sering menghadapi masalah ini, dan menurut saya jawabannya adalah: "tidak ada jawaban tunggal yang valid untuk semua skenario."

Namun perlu diingat bahwa Bahasa Ubiquitous bukan tujuan semata. Ini adalah alat untuk memperkuat komunikasi antara tim dan Ahli Domain dan untuk menegakkan koherensi konseptual dari model yang diterapkan dalam kode, tes dan percakapan.

Jika Anda dapat berbicara UL dengan jelas, Anda berada di jalur yang benar. Jika Anda dan rekan Anda terus menerjemahkan dari kode ke percakapan atau dari konsep ke konsep, maka Anda mungkin keluar jalur.

Dalam praktiknya, tidak semua domain sama, atau pakar domain. Beberapa domain tetap memiliki banyak terminologi bahasa Inggris (misalnya, domain yang digerakkan oleh teknologi) dan masuk akal untuk memilih pilihan bahasa Inggris penuh. Namun, beberapa budaya mungkin memengaruhi pilihan ini (Prancis muncul di benak) dan difusi terminologi bahasa Inggris bervariasi dari satu negara ke negara. Di beberapa domain lain (Legal, untuk menyebutkan satu) tidak ada cara untuk menerjemahkan beberapa istilah. Atau menerjemahkan akan mempersulit Ahli Domain untuk mengikuti percakapan.

Secara umum, kami lebih tertarik dengan apa yang dikatakan Pakar Domain. Jadi kami ingin mempermudah semuanya. Kalau tidak, mereka bisa mengambil kelas UML dan membaca diagram kami (itu adalah lelucon). Jadi satu-satunya rekomendasi nyata di sini adalah: "memperhatikan perilaku Domain Expert", jika mereka terlibat dalam percakapan dan percakapan berlangsung lancar, Anda mungkin di jalur, tetap bahwa bahasa. Mungkin menyebabkan sedikit kerja ekstra pada tim, tapi itu tidak masalah. Sebagai pengembang, kami agak terlatih untuk mempelajari kata-kata dengan makna spesifik dalam suatu konteks.

Anehnya, pertanyaan ini selalu disertai dengan asumsi bahwa semua kode perlu berbicara dalam satu bahasa. Itu mungkin ditantang juga. Saya bukan orang Inggris asli, dan pengetahuan tentang bahasa asing tidak datar: otak saya bergerak cepat ketika berbicara tentang nama , nama keluarga , mobil dan sejenisnya, kehilangan beberapa detail ketika berbicara tentang kode pos , melambat ketika berbicara tentang pinjaman dan pasti bertanya untuk penjelasan yang meyakinkan ketika berbicara tentang hipotek .

Jadi, sekali lagi, pilih kombinasi terbaik yang akan membuat alur percakapan utama dan memberikan jumlah informasi dan umpan balik tertinggi dari Pakar Domain.

Saya biasanya menganggap kata-kata teknis tertentu sebagai bahasa netral bahkan jika ada terjemahan dalam bahasa lain.

Sebagai contoh ketika berbicara tentang pengkodean dalam bahasa Jerman saya masih menggunakan kosakata teknis bahasa Inggris seolah-olah itu adalah kata-kata Jerman meskipun ada padanan bahasa Jerman.

Dalam kasus Anda, saya akan melakukan yang sebaliknya. Impor kata-kata teknis tertentu dari bahasa asli Anda ke bahasa Inggris seperti kata-kata asing telah diimpor selama berabad-abad. Jadikan mereka berperilaku tata bahasa seperti kata-kata bahasa Inggris. Awalnya terasa aneh, tetapi Anda akan terbiasa.

Saya setuju dengan sebagian besar bahasa pemrograman 'menghirup' komentar bahasa Inggris , yang selalu menjadi masalah dengan upaya pengembangan multi-bahasa

Biasanya saya akan memiliki UL dalam bahasa tim pemrograman Anda

Apa yang telah kami lakukan di masa lalu adalah membuat kata-kata baru yang mengekspresikan topik domain dengan lebih baik. Dengan proyek Perancis / Inggris, kata-kata yang dibuat di mana sebagian besar berbasis bahasa Inggris tetapi dengan rasa Perancis (tidak terlalu sulit karena banyak kata-kata bahasa Inggris adalah Perancis), tetapi ini bisa berlaku untuk campuran bahasa apa pun

misalnya

"kuantitas bois"

Dalam bahasa Inggris adalah "Jumlah kayu" atau "jumlah kayu", dalam bahasa Prancis adalah "quantité de bois", jadi cukup dekat untuk kedua penuturnya. Ini harus mengurangi jumlah kata baru yang harus dipelajari setiap pembicara

Seberapa besar UL domain Anda? Ini menjadi masalah. Jika kurang dari 100 frasa utama maka Anda dapat menggunakan bahasa gaya berbahan hybrid, jika lebih besar saya akan menempelkan bahasa utama para pengembang karena biasanya mereka harus mengatasinya dengan lebih intens.

Publikasikan kamus wiki / tesaurus untuk semua orang sebagai referensi juga sesuai kebutuhan sehingga tidak ada alasan untuk pemahaman

Saya baru-baru ini bekerja pada proyek DDD di Swiss, jika domainnya adalah pajak (khususnya PPN dan jenis pajak lainnya ... yang tidak mudah diterjemahkan ke bahasa Inggris ...).

Mereka memilih opsi pertama: UL dalam bahasa Jerman, digunakan dalam kode dalam bahasa Jerman juga.

Sebelum saya mengerjakan proyek ini, saya memiliki keengganan yang sama persis seperti Anda untuk kode bahasa campuran. Saya (masih) suka memiliki segalanya dalam bahasa Inggris, meskipun saya bukan penutur asli bahasa Inggris. Saya juga bukan penutur asli bahasa Jerman. Jadi ketika saya mulai menjelajahi basis kode, saya merasa ngeri.

Setelah satu tahun mengerjakan proyek itu, saya harus mengakui bahwa saya pikir itu adalah keputusan yang tepat dalam kasus ini (kami juga bisa menggunakan bahasa Prancis atau Italia, bahasa resmi Swiss lainnya, tetapi mayoritas aktor dalam proyek ini adalah penduduk asli Jerman speaker).

Banyak istilah khusus dari domain tersebut yang benar-benar tidak dapat diterjemahkan ke dalam bahasa Inggris dengan cara yang bermakna. Saya harus belajar istilah-istilah Jerman untuk berkomunikasi dengan anggota tim lainnya. Akan lebih berantakan jika harus juga belajar terjemahan bahasa Inggris, yang akan diciptakan dari kehampaan.

Jadi saya kira itu sangat tergantung pada domain. Beberapa domain akan sangat sulit diterjemahkan ke bahasa Inggris dan itu tidak masuk akal.

Itu mungkin tergantung pada bahasa asli juga. Bahasa Jerman adalah bahasa tempat Anda dapat menyusun kata-kata dengan cara yang kira-kira sama dan terutama urutan yang sama seperti dalam bahasa Inggris. Misalnya, deklarasi pajak akan menjadi Steuerdeklarasi . Tidak terlalu berbeda.

Saya tidak tahu bagaimana saya akan membuat nama kelas yang setara dalam bahasa Prancis, misalnya, adalah istilah alami akan menjadi "déclaration d'impôts", dengan urutan yang berlawanan dan preposisi tambahan di tengah ... Dan itu hanya contoh sederhana. Saya akan sangat tertarik jika ada yang punya pengalaman dengan penamaan seperti itu dalam bahasa latin (Perancis, Spanyol, Italia, Portugis ...)!

Tantangan lain adalah bentuk jamak, yang dalam bahasa Jerman kadang-kadang sulit dibedakan dari bentuk tunggal (sedangkan dalam bahasa Inggris hampir selalu memiliki huruf s pada akhirnya).

Karakter aksentuasi itu OK, karena dalam bahasa Jerman mereka semua memiliki padanan non aksentuasi ( ü -> ue dan seterusnya). Ini adalah titik lain di mana Perancis akan lebih bermasalah ...