Tłumaczenie zewnętrznych danych na język, w którym programujesz

Nie jestem pewien, co zrobić z następującymi elementami:

Pobieramy dane z zewnętrznego narzędzia w ramach naszego własnego narzędzia. Te dane są napisane w języku niderlandzkim. Piszemy nasz kod Java w języku angielskim. Czy powinniśmy przetłumaczyć ten holenderski na angielski, czy zachować go w języku holenderskim? Na przykład mamy 2 działy: Bouw (budownictwo w języku angielskim) i Onderhoud (konserwacja w języku angielskim).

Czy logiczne byłoby utworzenie:

public enum Department { BOUW, ONDERHOUD }

lub:

public enum Department { CONSTRUCTION, MAINTENANCE }

lub nawet:

public enum Afdeling { BOUW, ONDERHOUD }

(afdeling jest departamentem w języku niderlandzkim)

W tym scenariuszu pozostawiłbym wartości wyliczeniowe w języku niderlandzkim:

public enum Department { BOUW, ONDERHOUD }

Ponieważ logika wykorzystująca te stałe będzie pasować do danych, które również są w języku niderlandzkim . Na przykład, jeśli dane wejściowe to „bouw”, kod porównania może wyglądać następująco:

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

Łatwiej jest mi debugować, gdy wartości się zgadzają (nawet jeśli nie wiem, co oznaczają wartości). Tłumaczenie dodaje po prostu mentalny obręcz I, jako programista, nie powinienem przeskakiwać, aby udowodnić poprawność.

Niemniej jednak możesz po prostu skomentować kod, jeśli pomaga on innym zrozumieć kontekst danych:

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

Angielski jest z jakiegoś powodu lingua franca / najniższym wspólnym mianownikiem. Nawet jeśli pod względem koncepcyjnym powód jest tak słaby jak „Wszyscy to robią”, jest to nadal dość ważny powód.

Postępowanie wbrew powszechnej praktyce oznacza, że ​​musisz rozumieć język holenderski, aby zrozumieć struktury danych w oprogramowaniu. Nie ma nic złego w języku holenderskim, ale prawdopodobieństwo, że każdy inżynier, który będzie musiał wejść w interakcję z bazą kodu, mówi, jest wciąż niższe niż w przypadku języka angielskiego.

Dlatego też, jeśli nie jesteś holenderski tylko zakupy, i nie planuje ekspansję międzynarodową kiedykolwiek , to prawie zawsze dobry pomysł, aby zachować swoją codebase jednojęzycznych i używać najpopularniejszy język kodowania.

Uwaga: ta rada dotyczy tylko kodu programu . Dane użytkownika zdecydowanie nie powinny być tłumaczone, ale przetwarzane „tak jak są”. Nawet jeśli masz klienta „Goldstein”, oczywiście nie powinieneś przechowywać jego nazwy jako „złotego kamienia”.

Problem polega na tym, że istnieje ciąg terminów między „dostarczonym przez użytkownika, nie dotykaj” a „fragmentem kodu, używaj angielskiego zawsze”. Nazwy klientów znajdują się bardzo blisko pierwszego końca spektrum, zmienne Java w pobliżu drugiego końca. Stałe enumwartości są nieco dalej, szczególnie jeśli oznaczają znane, unikalne jednostki zewnętrzne (takie jak twoje działy). Jeśli wszyscy w Twojej organizacji używają holenderskich terminów dla działów, nie planujesz konfrontować nikogo z bazą kodu, kto tego nie robi, a zestaw istniejących działów rzadko się zmienia, wtedy użycie zaakceptowanych nazw departamentów może zwiększyć wyczuwa stałe wyliczeniowe niż zmienne lokalne. Nadal bym tego nie zrobił.

W miarę możliwości unikaj tłumaczenia, ponieważ każde tłumaczenie to dodatkowy wysiłek i może powodować błędy.

Kluczowym wkładem „Domain Driven Design” do nowoczesnej inżynierii oprogramowania jest koncepcja języka wszechobecnego , który jest jednym językiem używanym przez wszystkich interesariuszy projektu. Według DDD tłumaczenie nie powinno odbywać się w zespole (który obejmuje ekspertów w dziedzinie, nawet jeśli jest obecny tylko przez pełnomocnika dokumentu specyfikacji), ale tylko między zespołami (dalsze czytanie: „Domain Driven Design” Erica Evansa, w szczególności rozdziały o wszechobecnym języku i projektowaniu strategicznym).

Oznacza to, że jeśli Twoi eksperci biznesowi (lub dokument specyfikacji) mówią po holendersku, używaj ich (holenderskiej) terminologii podczas wyrażania obaw biznesowych w kodzie źródłowym. Nie tłumacz niepotrzebnie na angielski, ponieważ stwarza to sztuczną przeszkodę w komunikacji między ekspertami biznesowymi a programistami, co zajmuje dużo czasu i może (poprzez niejednoznaczne lub złe tłumaczenie) powodować błędy.

Jeśli natomiast eksperci biznesowi mogą rozmawiać o swojej działalności zarówno w języku angielskim, jak i holenderskim, masz szczęście, że możesz wybrać wszechobecny język projektu, i istnieją uzasadnione powody, aby preferować angielski (np. „Zrozumiały dla całego świata i bardziej prawdopodobne, że będą używane przez standardy ”), ale nie oznacza to, że koderzy powinni tłumaczyć to, o czym rozmawiają ludzie biznesu. Zamiast tego ludzie biznesu powinni zmieniać języki.

Posiadanie wszechobecnego języka jest szczególnie ważne, jeśli wymagania są złożone i muszą zostać zaimplementowane precyzyjnie, jeśli tylko robisz CRUD język, którego używasz wewnętrznie, ma mniejsze znaczenie.

Osobista anegdota: Byłem w projekcie, w którym ujawniliśmy niektóre usługi biznesowe jako punkt końcowy SOAP. Firma została w całości określona w języku niemieckim i jest mało prawdopodobne, aby została ponownie wykorzystana, podobnie jak w języku angielskim, ponieważ dotyczyła kwestii prawnych właściwych dla konkretnej jurysdykcji. Niemniej jednak niektórzy architekci z wieży z kości słoniowej zalecili, aby interfejs SOAP był angielski, aby promować przyszłe ponowne użycie. Tłumaczenie to odbyło się w trybie hoc i przy niewielkiej koordynacji między programistami, ale tylko ze wspólnym glosariuszem, w wyniku czego ten sam termin biznesowy ma kilka nazw w umowie o świadczenie usług internetowych, a niektóre warunki biznesowe mają tę samą nazwę w umowie o świadczenie usług internetowych. Aha, i oczywiście niektóre nazwy były używane po obu stronach podziału - ale mają różne znaczenia!

Jeśli mimo wszystko zdecydujesz się na tłumaczenie, ujednolic tłumaczenie w glosariuszu, dodaj zgodność z tym glosariuszem do swojej definicji ukończenia i sprawdź w swoich recenzjach. Nie bądź tak nieostrożny jak my.

Prawidłowe rozwiązanie to wcale nie kodować działów w ogóle:

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

Lub, jeśli absolutnie potrzebujesz typu działu:

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

Jeśli okaże się, że konieczne jest przetestowanie określonych działów w kodzie, należy bardziej ogólnie zapytać, co jest specjalnego w tym dziale, i zaakceptować skonfigurowanie tego działu jako posiadającego tę właściwość. Na przykład, jeśli jeden dział ma tygodniową listę płac i właśnie o to chodzi w kodzie, powinna istnieć właściwość WEEKLY_PAYROLL, którą konfiguracja może dołączyć do dowolnego działu.

Dla wszystkich zastanawiających się: wybraliśmy pierwszą opcję, głównie dlatego, że uważamy, że nie powinieneś nadrabiać warunków ze względu na tłumaczenie. Jeśli jednak jakiś projekt opracowałby międzynarodowy programista, dodaliśmy dokumentację, aby to wyjaśnić:

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

Jeśli martwisz się, że masz ciąg znaków reprezentujący użytkownika lub coś, po prostu zdefiniuj tablicę opisów w swoim wyliczeniu i ujawnij metodę.
Np .: Department.BUILD.getDescription();wyświetli „BOUW”

public enum Department { 
    BUILD,
    MAINTENANCE;

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

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

Wiem, że wybrałeś inaczej, ale na wypadek, gdyby wir Google go rzucił tu przez przypadek.

EDYCJA: Jak zauważył Pokechu22 , możesz używać konstruktorów enum i własności prywatnych, takich jak:

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

    private final String description;

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

    public String getDescription() {
        return description;
    }
}

który również osiągnie ten efekt.

Oczekuje się, że niektóre niezmienniki kodu będą przechowywane. Jednym z tych niezmienników jest to, że program nie będzie zachowywać się inaczej po zmianie nazwy identyfikatora. W szczególności w tym przypadku, gdy masz wyliczenie i zmieniasz nazwę dowolnego członka tego wyliczenia i aktualizujesz wszystkie zastosowania tego członka, nie spodziewałbyś się, że kod zacznie działać inaczej.

Analiza składniowa to proces odczytu danych i uzyskiwania z nich struktur danych. Gdy pobierasz dane zewnętrzne, czytasz je i tworzysz wystąpienia wyliczenia, analizujesz dane. Ten proces analizowania jest jedyną częścią Twojego programu odpowiedzialną za utrzymanie relacji między reprezentacją danych, w jaki sposób je otrzymujesz, a kształtem i nazwami członków typów danych.

W związku z tym nie powinno mieć znaczenia, jakie nazwy przypisujesz członkom wyliczenia. To, że akurat pokrywają się z łańcuchami używanymi w czytanych danych, jest przypadkowe.

Podczas projektowania kodu do modelowania domeny nazwy członków nie powinny być powiązane z formatem serializacji danych. Nie powinny one być ani holenderskimi terminami, ani nie powinny być tłumaczeniem holenderskich terminów, ale powinny być tym, co według Ciebie najlepiej pasuje do modelu domeny.

Analizator składni następnie tłumaczy między formatem danych a modelem domeny. To ostatni wpływ formatu danych na kod.