Übersetzen externer Daten in die Sprache, in der Sie programmieren

Ich bin nicht sicher, was ich mit Folgendem anfangen soll:

Wir nehmen Daten von einem externen Tool innerhalb unseres eigenen Tools. Diese Daten sind in niederländischer Sprache verfasst. Wir schreiben unseren Java-Code in Englisch. Sollten wir dieses Niederländisch dann ins Englische übersetzen oder es Niederländisch behalten? Zum Beispiel haben wir zwei Abteilungen: Bouw (Konstruktion in Englisch) und Onderhoud (Wartung in Englisch).

Wäre es dann logisch anzulegen:

public enum Department { BOUW, ONDERHOUD }

oder:

public enum Department { CONSTRUCTION, MAINTENANCE }

oder auch:

public enum Afdeling { BOUW, ONDERHOUD }

(afdeling is Department auf Niederländisch)

In diesem Szenario würde ich die Enum- Werte auf Niederländisch belassen :

public enum Department { BOUW, ONDERHOUD }

Weil die Logik, die diese Konstanten verwendet, mit Daten übereinstimmt , die auch auf Niederländisch vorliegen . Wenn die Eingabe beispielsweise "bouw" lautet, sieht der Vergleichscode möglicherweise folgendermaßen aus:

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

Ich finde es einfacher zu debuggen, wenn die Werte übereinstimmen (auch wenn ich nicht weiß, was die Werte bedeuten). Die Übersetzung fügt nur einen mentalen Rahmen hinzu, durch den ich als Entwickler nicht springen muss, um die Richtigkeit zu beweisen.

Sie können den Code jedoch nur kommentieren, wenn er anderen hilft, den Kontext der Daten zu verstehen:

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

Englisch ist aus einem bestimmten Grund eine Verkehrssprache / der kleinste gemeinsame Nenner. Auch wenn der Grund konzeptionell so schwach ist wie "Jeder tut es", ist das immer noch ein ziemlich wichtiger Grund.

Gegen die gängige Praxis zu verstoßen bedeutet, dass Sie Niederländisch verstehen müssen, um die Datenstrukturen in Ihrer Software zu verstehen. Es ist nichts Falsches an Holländisch, aber die Wahrscheinlichkeit, dass ein Ingenieur, der mit der Codebasis interagieren muss, es spricht, ist immer noch geringer als die für Englisch.

Deshalb , wenn Sie ein Dutch-only Shop sind, und nicht planen , international expandieren immer , es ist fast immer eine gute Idee , um Ihre Codebasis einsprachigen zu halten, und verwenden Sie die beliebtestene Codierung Sprache.

Hinweis: Dieser Hinweis gilt nur für Programmcode . Benutzerdaten sollten definitiv nicht übersetzt, sondern unverändert verarbeitet werden. Selbst wenn Sie einen Kunden "Goldstein" haben, sollten Sie dessen Namen eindeutig nicht als "Goldstein" speichern.

Das Problem ist, dass es ein Kontinuum von Begriffen zwischen "Vom Benutzer bereitgestellt, nicht berühren" und "Codefragment, immer Englisch verwenden" gibt. Kundennamen befinden sich ganz in der Nähe des früheren Endes des Spektrums, Java-Variablen ganz in der Nähe des späteren Endes. Konstanten für enumWerte sind etwas weiter weg, vor allem , wenn sie bekannte, einzigartige externe Entitäten bezeichnen (wie Ihre Abteilungen). Wenn jeder in Ihrer Organisation die niederländischen Begriffe für die Abteilungen verwendet, planen Sie nicht, jemanden mit der Codebasis zu konfrontieren, der dies nicht tut, und der Satz der vorhandenen Abteilungen ändert sich selten. Die Verwendung der akzeptierten Namen der Abteilung kann mehr bewirken Sinn für Enum-Konstanten als für lokale Variablen. Ich würde es trotzdem nicht tun.

Vermeiden Sie nach Möglichkeit Übersetzungen, da jede Übersetzung zusätzlichen Aufwand bedeutet und Fehler verursachen kann.

Der Hauptbeitrag von "Domain Driven Design" zur modernen Softwareentwicklung ist das Konzept einer Ubiquitous Language , einer einzigen Sprache, die von allen Beteiligten eines Projekts verwendet wird. Laut DDD sollte die Übersetzung nicht innerhalb eines Teams (zu dem Domain-Experten gehören, auch wenn diese nur durch einen Vertreter eines Spezifikationsdokuments anwesend sind) erfolgen, sondern nur zwischen Teams (weiterlesen: "Domain Driven Design" von Eric Evans, insbesondere die Kapitel) über Ubiquitous Language und strategisches Design).

Das heißt, wenn Ihre Geschäftsexperten (oder Ihr Spezifikationsdokument) Niederländisch sprechen, verwenden Sie deren (niederländische) Terminologie, wenn Sie geschäftliche Bedenken im Quellcode äußern. Übersetzen Sie nicht unnötigerweise ins Englische, da dies ein künstliches Hindernis für die Kommunikation zwischen Geschäftsexperten und Programmierern darstellt, das Zeit in Anspruch nimmt und (durch mehrdeutige oder schlechte Übersetzungen) Fehler verursachen kann.

Wenn Ihre Geschäftsexperten dagegen sowohl auf Englisch als auch auf Niederländisch über ihr Geschäft sprechen können, sind Sie in der glücklichen Lage, die allgegenwärtige Sprache des Projekts zu wählen, und es gibt triftige Gründe, Englisch zu bevorzugen (wie "international verständlich und") eher von Standards verwendet werden "), aber dies bedeutet nicht, dass Programmierer übersetzen sollten, wovon die Geschäftsleute sprechen. Stattdessen sollten die Geschäftsleute die Sprache wechseln.

Eine allgegenwärtige Sprache ist besonders wichtig, wenn die Anforderungen komplex sind und präzise umgesetzt werden müssen. Wenn Sie nur CRUD ausführen, ist die Sprache, die Sie intern verwenden, weniger wichtig.

Persönliche Anekdote: Ich war in einem Projekt, in dem wir einige Geschäftsdienste als SOAP-Endpunkt bekannt gemacht haben. Das Unternehmen wurde vollständig in deutscher Sprache angegeben und es ist unwahrscheinlich, dass es wie in englischer Sprache wiederverwendet wird, da es sich um rechtliche Angelegenheiten handelte, die für eine bestimmte Gerichtsbarkeit spezifisch sind. Einige Architekten des Elfenbeinturms forderten jedoch, dass die SOAP-Schnittstelle englisch sein sollte, um die zukünftige Wiederverwendung zu fördern. Diese Übersetzung erfolgte bei hoc und mit geringer Koordination zwischen den Entwicklern, jedoch allein mit einem gemeinsamen Glossar, was dazu führte, dass derselbe Geschäftsbegriff mehrere Namen im Webservicevertrag und einige Geschäftsbegriffe denselben Namen im Webservicevertrag aufwiesen. Oh, und natürlich wurden einige Namen auf beiden Seiten der Kluft verwendet - aber mit unterschiedlichen Bedeutungen!

Wenn Sie sich dennoch für eine Übersetzung entscheiden, standardisieren Sie die Übersetzung in einem Glossar, fügen Sie der Definition von "erledigt" die Übereinstimmung mit diesem Glossar hinzu und überprüfen Sie sie in Ihren Überprüfungen. Sei nicht so sorglos wie wir.

Die richtige Lösung besteht darin, die Abteilungen überhaupt nicht hart zu codieren:

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

Oder, wenn Sie unbedingt einen Abteilungstyp benötigen:

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

Wenn Sie feststellen, dass bestimmte Abteilungen in Ihrem Code getestet werden müssen, müssen Sie allgemeiner nach den Besonderheiten dieser Abteilung fragen und akzeptieren, dass diese Abteilung als solche mit dieser Eigenschaft konfiguriert wird. Wenn beispielsweise eine Abteilung wöchentlich abgerechnet wird und der Code sich darum kümmert, sollte es eine WEEKLY_PAYROLL-Eigenschaft geben, die durch die Konfiguration an jede Abteilung angehängt werden kann.

Für alle, die sich fragen: Wir haben uns für die erste Option entschieden, vor allem, weil wir der Meinung sind, dass Sie sich für das Übersetzen keine Begriffe ausdenken sollten. Wenn jedoch irgendwann ein internationaler Entwickler an dem Projekt arbeitet, haben wir eine Dokumentation hinzugefügt, um dies zu erläutern:

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

Wenn Sie Bedenken haben, dass dem Benutzer eine Zeichenfolgendarstellung angezeigt wird, definieren Sie einfach ein Beschreibungsarray in Ihrer Enumeration und machen Sie eine Methode verfügbar.
ZB: Department.BUILD.getDescription();wird "BOUW" ausgeben

public enum Department { 
    BUILD,
    MAINTENANCE;

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

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

Ich weiß, dass Sie sich für etwas anderes entschieden haben, aber nur für den Fall, dass der Google-Strudel versehentlich Menschen hierher wirft.

BEARBEITEN: Wie von Pokechu22 bemerkt , können Sie Enum-Konstruktoren und private Eigenschaften wie diese verwenden:

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

    private final String description;

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

    public String getDescription() {
        return description;
    }
}

was auch diesen Effekt erzielen wird.

Es wird erwartet, dass bestimmte Invarianten Ihres Codes gültig sind. Eine dieser Invarianten ist, dass sich ein Programm beim Umbenennen eines Bezeichners nicht anders verhält. Insbesondere in diesem Fall würden Sie nicht erwarten, dass Ihr Code anders funktioniert, wenn Sie eine Aufzählung haben und ein Mitglied dieser Aufzählung umbenennen und alle Verwendungen dieses Mitglieds aktualisieren.

Beim Parsen werden Daten gelesen und daraus Datenstrukturen abgeleitet. Wenn Sie die externen Daten erfassen, lesen und Instanzen Ihrer Aufzählung erstellen, analysieren Sie die Daten. Dieser Parsing-Prozess ist der einzige Teil Ihres Programms, der für die Aufrechterhaltung der Beziehung zwischen der Datendarstellung, wie Sie sie erhalten, und der Form und Benennung der Mitglieder Ihrer Datentypen verantwortlich ist.

Daher sollte es keine Rolle spielen, welche Namen Sie den Mitgliedern der Aufzählung zuweisen. Dass sie zufällig mit Zeichenfolgen übereinstimmen, die in den von Ihnen gelesenen Daten verwendet werden, ist ein Zufall.

Wenn Sie Ihren Code zum Modellieren der Domäne entwerfen, sollten die Namen der Mitglieder nicht mit dem Serialisierungsformat der Daten zusammenhängen. Es sollten weder die niederländischen Begriffe noch Übersetzungen der niederländischen Begriffe sein, aber es sollte das sein, was Sie für das Domain-Modell am besten finden.

Der Parser übersetzt dann zwischen dem Datenformat und Ihrem Domain-Modell. Dies ist der letzte Einfluss, den das Datenformat auf Ihren Code haben sollte.