Traduzione di dati esterni nella lingua in cui stai programmando

Non sono sicuro di cosa fare con quanto segue:

Prendiamo i dati da uno strumento esterno all'interno del nostro strumento. Questi dati sono scritti in olandese. Stiamo scrivendo il nostro codice Java in inglese. Dovremmo quindi tradurre questo olandese in inglese o mantenerlo olandese? Ad esempio, abbiamo 2 dipartimenti: Bouw (costruzione in inglese) e Onderhoud (manutenzione in inglese).

Sarebbe quindi logico creare:

public enum Department { BOUW, ONDERHOUD }

o:

public enum Department { CONSTRUCTION, MAINTENANCE }

o anche:

public enum Afdeling { BOUW, ONDERHOUD }

(afdeling is Department in olandese)

In questo scenario, lascerei i valori enum in olandese:

public enum Department { BOUW, ONDERHOUD }

Perché la logica che usa queste costanti corrisponderà a dati che sono anche in olandese . Ad esempio, se l'input è "bouw", il codice di confronto potrebbe apparire come:

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

Trovo più facile il debug quando i valori corrispondono (anche se non so cosa significano i valori). La traduzione aggiunge solo un cerchio mentale. Come sviluppatore, non dovrei saltare attraverso per dimostrare la correttezza.

Tuttavia, puoi semplicemente commentare il codice se aiuta gli altri a capire il contesto dei dati:

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

L'inglese è una lingua franca / minimo comune denominatore per un motivo. Anche se la ragione è concettualmente debole come "Lo fanno tutti", è comunque una ragione piuttosto importante.

Andare contro la pratica comune significa che devi capire l'olandese per dare un senso alle strutture di dati nel tuo software. Non c'è niente di sbagliato nell'olandese, ma la probabilità che un determinato ingegnere che debba interagire con la base di codice parli è ancora inferiore a quella dell'inglese.

Pertanto, se non sei un olandese unico negozio, e non si prevede di espandersi a livello internazionale mai , è quasi sempre una buona idea per mantenere il vostro monolingue codebase, e usare il linguaggio di codifica più popolari.

Nota: questo consiglio si applica solo al codice del programma . I dati dell'utente non devono assolutamente essere tradotti, ma elaborati "così come sono". Anche se hai un cliente "Goldstein", chiaramente non dovresti memorizzare il suo nome come "pietra d'oro".

Il problema è che esiste un continuum di termini tra "fornito dall'utente, non toccare" e "frammento di codice, usa sempre l'inglese". I nomi dei clienti sono molto vicini alla prima estremità dello spettro, le variabili Java vicino alla seconda estremità. Le costanti per i enumvalori sono leggermente più lontane, in particolare se indicano entità esterne uniche e ben note (come i dipartimenti). Se tutti i membri della tua organizzazione utilizzano i termini olandesi per i dipartimenti, non prevedi di confrontarti con qualcuno con la base di codice che non lo fa, e l'insieme dei dipartimenti esistenti cambia di rado, quindi l'utilizzo dei nomi accettati del dipartimento potrebbe rendere più senso per le costanti di enum che per le variabili locali. Non lo farei comunque, comunque.

Evita la traduzione ove possibile, perché ogni traduzione è uno sforzo aggiuntivo e può introdurre bug.

Il contributo chiave di "Domain Driven Design" alla moderna ingegneria del software è il concetto di Ubiquitous Language , che è un unico linguaggio utilizzato da tutti gli stakeholder di un progetto. Secondo DDD, la traduzione non dovrebbe avvenire all'interno di un team (che include esperti di dominio, anche se presenti solo per delega di un documento di specifica), ma solo tra team (ulteriore lettura: "Domain Driven Design" di Eric Evans, in particolare i capitoli su Ubiquitous Language e design strategico).

Cioè, se i tuoi esperti aziendali (o il tuo documento di specifica) parlano olandese, usano la loro terminologia (olandese) quando esprimono preoccupazioni commerciali nel codice sorgente. Non tradurre inutilmente in inglese, perché ciò crea un impedimento artificiale alla comunicazione tra esperti di business e programmatori, che richiede tempo e può (attraverso una traduzione ambigua o errata) causare bug.

Se, al contrario, i tuoi esperti in affari possono parlare della loro attività sia in inglese che in olandese, ti trovi nella fortunata situazione di poter scegliere la lingua onnipresente del progetto e ci sono validi motivi per preferire l'inglese (come "comprensibile a livello internazionale e è più probabile che vengano utilizzati dagli standard "), ma farlo non significa che i programmatori dovrebbero tradurre ciò di cui parlano gli uomini d'affari. Invece, gli uomini d'affari dovrebbero cambiare lingua.

Avere un linguaggio onnipresente è particolarmente importante se i requisiti sono complessi e devono essere implementati con precisione, se stai semplicemente facendo CRUD la lingua che usi internamente è meno importante.

Aneddoto personale: ero in un progetto in cui abbiamo esposto alcuni servizi aziendali come endpoint SOAP. L'attività è stata interamente specificata in tedesco, ed è improbabile che possa essere riutilizzata come in inglese, poiché si trattava di questioni legali specifiche di una determinata giurisdizione. Tuttavia, alcuni architetti delle torri d'avorio hanno richiesto che l'interfaccia SOAP fosse inglese per promuovere il riutilizzo futuro. Questa traduzione è avvenuta ad hoc e con uno scarso coordinamento tra gli sviluppatori, ma solo un glossario condiviso, con lo stesso termine commerciale con diversi nomi nel contratto di servizio Web e alcuni termini commerciali con lo stesso nome nel contratto di servizio Web. Oh, e ovviamente alcuni nomi erano usati su entrambi i lati della divisione, ma con significati diversi!

Se si sceglie di tradurre comunque, si prega di standardizzare la traduzione in un glossario, aggiungere la conformità con quel glossario alla propria definizione di fatto e verificarlo nelle proprie recensioni. Non essere negligente come noi.

La soluzione corretta è di non codificare affatto i reparti:

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

Oppure, se hai assolutamente bisogno di un tipo di dipartimento:

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

Se trovi la necessità di testare dipartimenti specifici nel tuo codice, devi chiedere in modo più generico ciò che è speciale di quel dipartimento e accettare di configurare quel dipartimento con quella proprietà. Ad esempio, se un reparto ha un libro paga settimanale, ed è quello che interessa al codice, dovrebbe esserci una proprietà WEEKLY_PAYROLL che può essere collegata a qualsiasi reparto dalla configurazione.

Per chiunque si chieda: abbiamo scelto la prima opzione, principalmente perché pensiamo che non dovresti inventare termini per il bene della traduzione. Tuttavia, se qualche volta, uno sviluppatore internazionale lavorasse al progetto, abbiamo aggiunto della documentazione per spiegarlo:

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

Se sei preoccupato di avere una rappresentazione in forma di stringa per mostrare l'utente o qualcosa del genere, basta definire un array di descrizioni all'interno del tuo enum ed esporre un metodo.
Ad esempio: Department.BUILD.getDescription();verrà visualizzato "BOUW"

public enum Department { 
    BUILD,
    MAINTENANCE;

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

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

So che hai scelto diversamente, ma nel caso in cui il vortice di Google butti le persone qui per caso.

EDIT: Come notato da Pokechu22 puoi usare enum builder e proprietà private come questa:

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

    private final String description;

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

    public String getDescription() {
        return description;
    }
}

che otterrà anche questo effetto.

Ci si aspetta che alcuni invarianti del tuo codice siano in possesso. Una di quelle invarianti è che un programma non si comporterà diversamente quando viene rinominato un identificatore. In questo caso, in particolare, quando si dispone di un enum e si rinomina un membro di tale enum e si aggiornano tutti gli usi di quel membro, non ci si aspetterebbe che il codice inizi a funzionare in modo diverso.

L'analisi è il processo di lettura dei dati e derivazione di strutture dati da esso. Quando prendi i dati esterni, li leggi e crei istanze del tuo enum, stai analizzando i dati. Tale processo di analisi è l'unica parte del programma responsabile di mantenere la relazione tra la rappresentazione dei dati su come li ricevi e la forma e la denominazione dei membri dei tuoi tipi di dati.

Pertanto, non dovrebbe importare quali nomi si assegnano ai membri dell'enum. Che coincidano con le stringhe utilizzate nei dati letti è una coincidenza.

Quando si progetta il codice per modellare il dominio, i nomi dei membri non devono essere correlati al formato di serializzazione dei dati. Non dovrebbero essere né i termini olandesi, né dovrebbero essere traduzioni dei termini olandesi, ma dovrebbero essere ciò che decidi si adatti meglio al modello di dominio.

Il parser che si traduce tra il formato dei dati e il modello di dominio. Questa è l'ultima influenza che il formato dei dati dovrebbe avere sul tuo codice.