Dịch dữ liệu ngoài sang ngôn ngữ bạn đang lập trình

Tôi không biết phải làm gì với những điều sau đây:

Chúng tôi lấy dữ liệu từ một công cụ bên ngoài trong công cụ của chúng tôi. Dữ liệu này được viết bằng tiếng Hà Lan. Chúng tôi đang viết mã Java bằng tiếng Anh. Sau đó chúng ta nên dịch tiếng Hà Lan này sang tiếng Anh hay giữ tiếng Hà Lan? Ví dụ: chúng tôi có 2 phòng ban: Bouw (Xây dựng bằng tiếng Anh) & Onderhoud (Bảo trì bằng tiếng Anh).

Sau đó, nó sẽ hợp lý để tạo ra:

public enum Department { BOUW, ONDERHOUD }

hoặc là:

public enum Department { CONSTRUCTION, MAINTENANCE }

hoặc thậm chí:

public enum Afdeling { BOUW, ONDERHOUD }

(afdeling là Sở tại Hà Lan)

Trong kịch bản này, tôi sẽ để các giá trị enum bằng tiếng Hà Lan:

public enum Department { BOUW, ONDERHOUD }

Bởi vì logic sử dụng các hằng số này sẽ khớp với dữ liệu cũng bằng tiếng Hà Lan . Ví dụ: nếu đầu vào là "bouw", mã so sánh có thể trông như sau:

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

Tôi thấy việc gỡ lỗi dễ dàng hơn khi các giá trị khớp với nhau (ngay cả khi tôi không biết ý nghĩa của các giá trị). Dịch chỉ cần thêm một tinh thần tôi, với tư cách là một nhà phát triển, không cần phải nhảy qua để chứng minh sự đúng đắn.

Tuy nhiên, bạn chỉ có thể nhận xét mã nếu nó giúp người khác hiểu ngữ cảnh của dữ liệu:

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

Tiếng Anh là một ngôn ngữ chung / mẫu số chung thấp nhất vì một lý do. Ngay cả khi lý do yếu về mặt khái niệm là "Mọi người đều làm như vậy", đó vẫn là một lý do khá quan trọng.

Đi ngược lại thực tiễn phổ biến có nghĩa là bạn phải hiểu tiếng Hà Lan để hiểu được cấu trúc dữ liệu trong phần mềm. Không có gì sai với tiếng Hà Lan, nhưng xác suất mà bất kỳ kỹ sư nào sẽ phải tương tác với cơ sở mã nói rằng nó vẫn thấp hơn so với tiếng Anh.

Do đó, trừ khi bạn là cửa hàng duy nhất ở Hà Lan và không có kế hoạch mở rộng ra quốc tế bao giờ , thì hầu như luôn luôn là một ý tưởng tốt để duy trì cơ sở mã hóa của bạn và sử dụng ngôn ngữ mã hóa phổ biến nhất.

Lưu ý: Lời khuyên này chỉ áp dụng cho mã chương trình . Dữ liệu người dùng chắc chắn không nên được dịch, nhưng được xử lý "nguyên trạng". Ngay cả khi bạn có một khách hàng "Goldstein", rõ ràng bạn không nên lưu trữ tên của họ là "viên đá vàng".

Vấn đề là có sự liên tục của các thuật ngữ giữa "do người dùng cung cấp, không chạm vào" và "đoạn mã, sử dụng tiếng Anh mọi lúc". Tên khách hàng ở rất gần đầu trước của phổ, các biến Java ở gần đầu sau. Các hằng số cho enumcác giá trị ở xa hơn một chút, đặc biệt nếu chúng biểu thị các thực thể bên ngoài nổi tiếng, duy nhất (như các phòng ban của bạn). Nếu mọi người trong tổ chức của bạn sử dụng thuật ngữ tiếng Hà Lan cho các phòng ban, bạn không có kế hoạch đối đầu với bất kỳ ai có cơ sở mã không, và bộ các phòng ban hiện tại thay đổi hiếm khi, sau đó sử dụng tên được chấp nhận của bộ phận có thể tạo ra nhiều hơn ý nghĩa cho hằng số enum hơn cho các biến cục bộ. Tôi vẫn sẽ không làm điều đó, mặc dù.

Tránh dịch nếu có thể, bởi vì mọi bản dịch là nỗ lực bổ sung và có thể giới thiệu các lỗi.

Đóng góp quan trọng của "Thiết kế hướng miền" cho công nghệ phần mềm hiện đại là khái niệm Ngôn ngữ phổ biến , là ngôn ngữ duy nhất được sử dụng bởi tất cả các bên liên quan của dự án. Theo DDD, dịch thuật không nên xảy ra trong một nhóm (bao gồm các chuyên gia tên miền, ngay cả khi chỉ xuất hiện bằng proxy của tài liệu đặc tả), mà chỉ giữa các nhóm (đọc thêm: "Thiết kế hướng tên miền" của Eric Evans, đặc biệt là các chương về ngôn ngữ Ubiquitous và thiết kế chiến lược).

Đó là, nếu các chuyên gia kinh doanh của bạn (hoặc tài liệu đặc tả của bạn) nói tiếng Hà Lan, hãy sử dụng thuật ngữ (tiếng Hà Lan) của họ khi thể hiện mối quan tâm kinh doanh trong mã nguồn. Không cần dịch sang tiếng Anh, bởi vì làm như vậy sẽ tạo ra một trở ngại nhân tạo cho việc giao tiếp giữa các chuyên gia kinh doanh và lập trình viên, điều này làm mất thời gian và có thể (thông qua bản dịch mơ hồ hoặc xấu) gây ra lỗi.

Ngược lại, nếu các chuyên gia kinh doanh của bạn có thể nói về doanh nghiệp của họ bằng cả tiếng Anh và tiếng Hà Lan, thì bạn đang ở trong tình huống may mắn có thể chọn ngôn ngữ phổ biến của dự án và có những lý do hợp lệ để thích tiếng Anh (như "có thể hiểu được quốc tế và nhiều khả năng được sử dụng bởi các tiêu chuẩn "), nhưng làm như vậy không có nghĩa là các lập trình viên nên dịch những gì người kinh doanh đang nói đến. Thay vào đó, những người kinh doanh nên chuyển đổi ngôn ngữ.

Có một ngôn ngữ phổ biến là đặc biệt quan trọng nếu các yêu cầu phức tạp và phải được thực hiện chính xác, nếu bạn chỉ thực hiện CRUD thì ngôn ngữ bạn sử dụng ít quan trọng hơn.

Giai thoại cá nhân: Tôi đã ở trong một dự án nơi chúng tôi tiếp xúc với một số dịch vụ kinh doanh như một điểm cuối SOAP. Việc kinh doanh hoàn toàn được quy định bằng tiếng Đức và không có khả năng được sử dụng lại như tiếng Anh, bởi vì đó là về các vấn đề pháp lý cụ thể đối với một khu vực pháp lý cụ thể. Tuy nhiên, một số kiến ​​trúc sư tháp ngà đã yêu cầu giao diện SOAP là tiếng Anh để thúc đẩy việc tái sử dụng trong tương lai. Bản dịch này xảy ra tại hoc và có rất ít sự phối hợp giữa các nhà phát triển, nhưng một mình một thuật ngữ chung, dẫn đến cùng một thuật ngữ kinh doanh có một số tên trong hợp đồng dịch vụ web và một số điều khoản kinh doanh có cùng tên trong hợp đồng dịch vụ web. Ồ, và tất nhiên một số tên được sử dụng ở hai bên của sự phân chia - nhưng với ý nghĩa khác nhau!

Nếu bạn chọn dịch bằng mọi cách, vui lòng chuẩn hóa bản dịch trong bảng chú giải thuật ngữ, thêm tuân thủ bảng chú giải đó vào định nghĩa hoàn thành của bạn và kiểm tra nó trong phần đánh giá của bạn. Đừng bất cẩn như chúng ta đã từng.

Giải pháp chính xác là không mã hóa các bộ phận:

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

Hoặc, nếu bạn thực sự cần một loại phòng ban:

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

Nếu bạn thấy cần phải kiểm tra các bộ phận cụ thể trong mã của mình, bạn phải hỏi một cách khái quát hơn về bộ phận đó có gì đặc biệt và chấp nhận định cấu hình bộ phận đó có thuộc tính đó. Ví dụ: nếu một bộ phận có bảng lương hàng tuần và đó là những gì mã quan tâm, thì nên có một thuộc tính WEEKLY_PAYROLL có thể được gắn vào bất kỳ bộ phận nào theo cấu hình.

Đối với bất kỳ ai thắc mắc: chúng tôi đã chọn tùy chọn đầu tiên, chủ yếu là vì chúng tôi nghĩ rằng bạn không nên tạo ra các điều khoản vì mục đích dịch thuật. Tuy nhiên, nếu đôi khi, một nhà phát triển quốc tế sẽ làm việc với dự án, chúng tôi đã thêm một số tài liệu để giải thích như vậy:

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

Nếu bạn lo lắng về việc có một biểu diễn chuỗi để hiển thị cho người dùng hoặc thứ gì đó, chỉ cần xác định một mảng mô tả bên trong enum của bạn và hiển thị một phương thức.
Ví dụ: Department.BUILD.getDescription();sẽ xuất "BOUW"

public enum Department { 
    BUILD,
    MAINTENANCE;

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

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

Tôi biết bạn đã chọn cách khác, nhưng chỉ trong trường hợp cơn lốc google ném người ở đây một cách tình cờ.

EDIT: Theo ghi nhận của Pokechu22, bạn có thể sử dụng các hàm tạo enum và các thuộc tính riêng tư như thế này:

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

    private final String description;

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

    public String getDescription() {
        return description;
    }
}

Điều đó cũng sẽ đạt được hiệu quả đó.

Một số bất biến của mã của bạn được dự kiến ​​sẽ giữ. Một trong những bất biến đó là chương trình sẽ không hoạt động khác khi định danh được đổi tên. Trong trường hợp này, đặc biệt, khi bạn có enum và đổi tên bất kỳ thành viên nào của enum đó và cập nhật tất cả các cách sử dụng của thành viên đó, bạn sẽ không mong đợi mã của mình bắt đầu hoạt động khác đi.

Phân tích cú pháp là quá trình đọc dữ liệu và lấy dữ liệu từ nó. Khi bạn lấy dữ liệu ngoài, đọc nó và tạo các thể hiện của enum, bạn đang phân tích dữ liệu. Quá trình phân tích cú pháp đó là phần duy nhất trong chương trình của bạn chịu trách nhiệm duy trì mối quan hệ giữa biểu diễn dữ liệu về cách bạn nhận được nó, hình dạng và cách đặt tên của các thành viên của kiểu dữ liệu của bạn.

Như vậy, việc bạn gán tên cho các thành viên của enum là không quan trọng. Rằng chúng xảy ra trùng khớp với các chuỗi được sử dụng trong dữ liệu bạn đọc là trùng hợp ngẫu nhiên.

Khi bạn thiết kế mã của mình để mô hình hóa tên miền, tên của các thành viên không nên liên quan đến định dạng tuần tự hóa của dữ liệu. Chúng không phải là các thuật ngữ tiếng Hà Lan, cũng không nên là các bản dịch của các thuật ngữ tiếng Hà Lan, nhưng chúng phải là những gì bạn quyết định phù hợp nhất với mô hình miền.

Trình phân tích cú pháp hơn dịch giữa định dạng dữ liệu và mô hình miền của bạn. Đó là ảnh hưởng cuối cùng của định dạng dữ liệu đối với mã của bạn.