Lập trình và Ngôn ngữ Ubiquitous (DDD) trong một miền không phải tiếng Anh

Tôi biết đã có một số câu hỏi ở đây có liên quan chặt chẽ đến chủ đề này nhưng không có câu hỏi nào trong số đó lấy Ngôn ngữ Ubiquitous làm điểm khởi đầu nên tôi nghĩ điều đó biện minh cho câu hỏi này.

Đối với những người không biết: Ngôn ngữ Ubiquitous là khái niệm xác định ngôn ngữ (cả nói và viết) được sử dụng như nhau giữa các nhà phát triển và chuyên gia tên miền để tránh sự không nhất quán và thông tin sai lệch do vấn đề dịch thuật và hiểu lầm. Bạn sẽ thấy cùng một thuật ngữ hiển thị trong mã, các cuộc hội thoại giữa bất kỳ thành viên nào trong nhóm, thông số chức năng và không có gì.

Vì vậy, điều tôi băn khoăn là làm thế nào để đối phó với Ngôn ngữ Ubiquitous trong các lĩnh vực không phải tiếng Anh.

Cá nhân, tôi hoàn toàn ủng hộ việc viết mã lập trình bằng tiếng Anh hoàn toàn, bao gồm các bình luận nhưng tất nhiên không bao gồm các hằng số và tài nguyên.

Tuy nhiên, trong một miền không phải tiếng Anh, tôi buộc phải đưa ra quyết định:

1. Viết mã phản ánh Ngôn ngữ Ubiquitous bằng ngôn ngữ tự nhiên của tên miền.
2. Dịch ngôn ngữ Ubiquitous sang tiếng Anh và ngừng giao tiếp bằng ngôn ngữ tự nhiên của tên miền.
3. Xác định một bảng xác định cách ngôn ngữ Ubiquitous dịch sang tiếng Anh.

Dưới đây là một số suy nghĩ của tôi dựa trên các tùy chọn sau:

1) Tôi có ác cảm mạnh mẽ với mã ngôn ngữ hỗn hợp, đó là mã hóa bằng cách sử dụng tên loại / thành viên / biến, v.v. không phải tiếng Anh. Hầu hết các ngôn ngữ lập trình 'thở' tiếng Anh ở một mức độ lớn và hầu hết các tài liệu kỹ thuật, tên mẫu thiết kế, vv cũng bằng tiếng Anh. Do đó, trong hầu hết các trường hợp, không có cách nào viết mã hoàn toàn bằng ngôn ngữ không phải tiếng Anh nên dù sao bạn cũng kết thúc bằng các ngôn ngữ hỗn hợp.

2) Điều này sẽ buộc các chuyên gia trong miền bắt đầu suy nghĩ và nói chuyện bằng tiếng Anh tương đương với UL, một điều có lẽ sẽ không tự nhiên đến với họ và do đó cản trở giao tiếp đáng kể.

3) Trong trường hợp này, các nhà phát triển giao tiếp với các chuyên gia tên miền bằng ngôn ngữ mẹ đẻ của họ trong khi các nhà phát triển giao tiếp với nhau bằng tiếng Anh và quan trọng nhất là họ viết mã bằng bản dịch tiếng Anh của UL.

Tôi chắc chắn rằng tôi không muốn chọn tùy chọn đầu tiên và tôi nghĩ tùy chọn 3 tốt hơn nhiều so với tùy chọn 2. Bạn nghĩ gì? Tôi có thiếu các lựa chọn khác không?

CẬP NHẬT

Hôm nay, khoảng một năm sau, xử lý vấn đề này hàng ngày, tôi phải nói rằng phương án 3 đã giải quyết khá tốt cho tôi.

Nó không tẻ nhạt như ban đầu tôi sợ và dịch trong thời gian thực trong khi nói chuyện với khách hàng cũng không phải là vấn đề.

Tôi cũng tìm thấy những lợi thế sau đây là đúng, dựa trên kinh nghiệm của tôi.

• Dịch UL khiến bạn chú ý hơn đến việc xác định UL và thậm chí chính tên miền, đặc biệt là khi bạn không biết cách dịch thuật ngữ và bạn phải bắt đầu xem qua từ điển, v.v. Điều này thậm chí còn khiến tôi phải xem xét lại các quyết định mô hình hóa tên miền một vài lần.
• Nó giúp bạn làm cho kiến ​​thức về ngôn ngữ tiếng Anh của bạn sâu sắc hơn.
• Rõ ràng, mã của bạn dễ chịu hơn nhiều khi nhìn vào thay vì là một tâm trí bỉ ổi.

Tôi đã phải đối mặt với vấn đề này thường xuyên, và theo tôi, câu trả lời là: "không có câu trả lời duy nhất nào hợp lệ cho tất cả các kịch bản."

Nhưng hãy nhớ rằng Ngôn ngữ Ubiquitous không phải là mục tiêu. Đó là một công cụ để tăng cường giao tiếp giữa nhóm và các Chuyên gia Miền và để thực thi sự gắn kết khái niệm của mô hình được triển khai trong mã, kiểm tra và hội thoại.

Nếu bạn có thể nói UL một cách rõ ràng, bạn đang đi đúng hướng. Nếu bạn và đồng nghiệp của bạn liên tục dịch từ mã sang hội thoại hoặc từ khái niệm này sang khái niệm khác, thì có lẽ bạn đã đi sai hướng.

Trong thực tế, không phải tất cả các tên miền đều như nhau, cũng không phải là chuyên gia tên miền. Một số tên miền dù sao cũng có rất nhiều thuật ngữ tiếng Anh (ví dụ như các lĩnh vực hướng đến công nghệ) và nghe có vẻ hợp lý để lựa chọn một lựa chọn hoàn toàn bằng tiếng Anh. Tuy nhiên, một số nền văn hóa có thể ảnh hưởng đến sự lựa chọn này (tiếng Pháp xuất hiện) và sự phổ biến của thuật ngữ tiếng Anh khác nhau giữa các quốc gia. Trong một số tên miền khác (Pháp lý, để đặt tên một) không có cách nào để dịch một số thuật ngữ. Hoặc dịch sẽ khiến Chuyên gia Miền khó theo dõi cuộc trò chuyện.

Nói chung, chúng tôi quan tâm nhiều hơn đến những gì Chuyên gia Miền nói. Vì vậy, chúng tôi muốn làm cho mọi thứ dễ dàng cho họ. Nếu không, họ chỉ có thể lấy một lớp UML và đọc sơ đồ của chúng tôi (đó là một trò đùa). Vì vậy, khuyến nghị thực sự duy nhất ở đây là: "chú ý đến hành vi của Chuyên gia Miền", nếu họ tham gia vào cuộc trò chuyện và cuộc trò chuyện diễn ra suôn sẻ, có lẽ bạn đang đi đúng hướng, hãy giữ ngôn ngữ đó . Nó có thể gây ra thêm một chút công việc cho đội, nhưng điều đó tốt. Là nhà phát triển, chúng tôi phần nào được đào tạo để học các từ có ý nghĩa cụ thể trong ngữ cảnh.

Thật kỳ lạ, câu hỏi này luôn đi kèm với giả định rằng tất cả các mã cần nói một ngôn ngữ. Điều đó cũng có thể được thử thách. Tôi không phải là người Anh, và kiến ​​thức về ngoại ngữ không bằng phẳng: bộ não của tôi đi rất nhanh khi nói về tên , họ , xe và những thứ tương tự, bỏ lỡ một số chi tiết khi nói về mã zip , chậm lại khi nói về khoản vay và chắc chắn hỏi cho một lời giải thích yên tâm khi nói về thế chấp .

Vì vậy, một lần nữa, chọn kết hợp tốt nhất sẽ tạo ra luồng hội thoại chính và cung cấp lượng thông tin và phản hồi cao nhất từ ​​Chuyên gia Miền.

Tôi thường coi một số từ kỹ thuật là ngôn ngữ trung lập ngay cả khi có một bản dịch trong ngôn ngữ khác.

Ví dụ khi nói về mã hóa bằng tiếng Đức, tôi vẫn sử dụng từ vựng kỹ thuật tiếng Anh như thể chúng là từ tiếng Đức ngay cả khi có từ tiếng Đức tương đương.

Trong trường hợp của bạn, tôi sẽ làm ngược lại. Nhập một số từ kỹ thuật từ ngôn ngữ mẹ đẻ của bạn vào tiếng Anh giống như các từ nước ngoài đã được nhập khẩu trong nhiều thế kỷ. Làm cho chúng hoạt động theo ngữ pháp như các từ tiếng Anh. Ban đầu cảm thấy lạ, nhưng bạn sẽ quen với nó.

Tôi đồng ý với hầu hết các ngôn ngữ lập trình 'thở' bình luận tiếng Anh , điều đó luôn trở thành một vấn đề với những nỗ lực phát triển đa ngôn ngữ

Thông thường tôi sẽ có UL trong ngôn ngữ của nhóm lập trình của bạn

Những gì chúng tôi đã làm trong quá khứ là tạo ra các từ mới thể hiện tốt hơn các chủ đề tên miền. Với một dự án tiếng Pháp / tiếng Anh, các từ được tạo thành chủ yếu dựa trên tiếng Anh nhưng có hương vị tiếng Pháp (không quá khó vì nhiều từ tiếng Anh là tiếng Pháp), nhưng điều này có thể áp dụng cho bất kỳ ngôn ngữ nào

ví dụ

"số lượng bois"

Trong tiếng Anh là "Lượng gỗ" hoặc "số lượng gỗ", trong tiếng Pháp là "quantité de bois", do đó, đủ gần cho cả hai loa. Điều này sẽ làm giảm lượng từ mới mà mỗi người nói phải học

Tên miền của bạn lớn đến mức nào? Điều này trở thành vấn đề. Nếu nó ít hơn 100 cụm từ chính thì bạn có thể sử dụng ngôn ngữ tạo kiểu lai, nếu lớn hơn tôi sẽ sử dụng ngôn ngữ chính của các nhà phát triển vì họ thường phải đối phó với nó mạnh mẽ hơn

Xuất bản một từ điển wiki / từ điển đồng nghĩa cho mọi người tham khảo theo yêu cầu để không có lý do để hiểu

Gần đây tôi đã làm việc trong một dự án DDD ở Thụy Sĩ, tên miền là thuế (cụ thể là VAT và một loại thuế khác ... không dễ dịch sang tiếng Anh ...).

Họ đã chọn tùy chọn đầu tiên: UL bằng tiếng Đức, cũng được sử dụng trong mã bằng tiếng Đức.

Trước khi tôi làm việc trong dự án này, tôi đã có ác cảm chính xác như bạn đối với mã ngôn ngữ hỗn hợp. Tôi (vẫn) thích có mọi thứ bằng tiếng Anh, mặc dù tôi không phải là người nói tiếng Anh bản ngữ. Tôi cũng không phải là một người nói tiếng Đức bản xứ. Vì vậy, khi tôi bắt đầu khám phá codebase, tôi đã rất kinh hoàng.

Sau một năm làm việc trong dự án đó, tôi phải thừa nhận rằng tôi nghĩ đó là quyết định đúng đắn trong trường hợp này (chúng tôi cũng có thể sử dụng tiếng Pháp hoặc tiếng Ý, các ngôn ngữ chính thức khác của Thụy Sĩ, nhưng phần lớn các diễn viên trong dự án là người Đức bản địa diễn giả).

Nhiều thuật ngữ cụ thể của tên miền thực sự không thể dịch sang tiếng Anh một cách có ý nghĩa. Dù sao tôi cũng phải học các thuật ngữ tiếng Đức để giao tiếp với các thành viên còn lại trong đội. Nó cũng sẽ rắc rối hơn khi phải học các bản dịch tiếng Anh, dù sao nó cũng đã được phát minh ra ngoài không khí.

Vì vậy, tôi đoán nó thực sự phụ thuộc vào tên miền. Một số tên miền sẽ thực sự khó dịch sang tiếng Anh và nó sẽ không có nhiều ý nghĩa.

Nó có thể phụ thuộc vào ngôn ngữ bản địa là tốt. Tiếng Đức là một ngôn ngữ mà bạn có thể soạn các từ theo cùng một cách và đặc biệt là theo thứ tự như trong tiếng Anh. Ví dụ, một tờ khai thuế sẽ là Steuerdeklaration . Không khác biệt gây sốc.

Tôi không biết làm thế nào tôi có thể tạo một tên lớp tương đương bằng tiếng Pháp, ví dụ, thuật ngữ tự nhiên sẽ là "déclaration d'impôts", với thứ tự ngược lại và một giới từ phụ ở giữa ... Và đó chỉ là một ví dụ đơn giản. Tôi sẽ thực sự thích thú nếu có ai có kinh nghiệm với cách đặt tên theo ngôn ngữ Latin (Pháp, Tây Ban Nha, Ý, Bồ Đào Nha ...)!

Một thách thức khác là các hình thức số nhiều, trong tiếng Đức đôi khi khó phân biệt với số ít (trong khi trong tiếng Anh, nó hầu như luôn luôn có một s ở cuối).

Các ký tự có dấu là OK, vì trong tiếng Đức, tất cả chúng đều có một tương đương không có dấu ( ü -> ue , v.v.). Đó là một điểm khác mà người Pháp sẽ gặp nhiều vấn đề hơn ...