Traduzione di dati esterni nella lingua in cui stai programmando

In questo scenario, lascerei l'enum valori in olandese:

public enum Department { BOUW, ONDERHOUD }

Poiché la logica che utilizza queste costanti corrisponderà ai dati che sono anche in olandese . Ad esempio, se l'input è "bouw", il codice di confronto potrebbe essere simile a:

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

Trovo più facile eseguire il debug quando i valori corrispondono (anche se non so cosa significano i valori). La traduzione aggiunge semplicemente un cerchio mentale. Io, come sviluppatore, non dovrei saltare 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 una ragione. Anche se la ragione è concettualmente debole come "Tutti lo fanno", questa è ancora una ragione piuttosto importante.

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

Pertanto, a meno che tu non sia un negozio solo olandese e non prevedi di espandere a livello internazionale mai , è quasi sempre una buona idea mantenere la base di codici monolingue e utilizzare la codifica più popolare lingua.

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

Il problema è che esiste un continuum di termini tra "utente fornito, non toccare" e "frammento di codice, usa l'inglese in ogni momento". I nomi dei clienti sono molto vicini alla precedente estremità dello spettro, le variabili Java vicino all'estremità finale. Le costanti per i valori di enum sono leggermente più lontane, in particolare se indicano ditte esterne uniche e ben note (come i tuoi reparti). Se tutti i membri della tua organizzazione utilizzano i termini olandesi per i dipartimenti, non hai intenzione di confrontarti con nessuno con il codice di base che non lo fa, e l'insieme dei reparti esistenti cambia raramente, quindi usare i nomi accettati del dipartimento potrebbe fare di più senso per le costanti enum che per le variabili locali. Non lo farei comunque.

Evita la traduzione dove 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 Lingua Ubiquitous , che è una singola lingua utilizzata da tutti i portatori di interesse 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 proxy di un documento di specifiche), ma solo tra i gruppi (ulteriore lettura: "Domain Driven Design" di Eric Evans, in particolare i capitoli su Ubiquitous Language e design strategico).

Cioè, se i tuoi esperti di business (o il tuo documento delle specifiche) parlano olandese, usa la loro terminologia (olandese) quando esprimi preoccupazioni commerciali nel codice sorgente. Non tradurre inutilmente in inglese, perché così facendo si crea un impedimento artificiale per la comunicazione tra esperti di business e programmatori, che richiede tempo e può (tramite traduzione ambigua o errata) causare bug.

Se, al contrario, i tuoi esperti di business possono parlare della loro attività sia in inglese che in olandese, sei nella fortunata situazione di poter scegliere il linguaggio onnipresente del progetto e ci sono validi motivi per preferire l'inglese (come " comprensibile a livello internazionale e più probabile che venga utilizzato dagli standard "), ma farlo non significa che i programmatori debbano 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, perché riguardava aspetti legali specifici di una particolare giurisdizione. Tuttavia, alcuni architetti di torri d'avorio impongono che l'interfaccia SOAP sia l'inglese per promuovere il riutilizzo futuro. Questa traduzione si è verificata ad hoc e con poco coordinamento tra gli sviluppatori, ma da solo un glossario condiviso, che ha portato allo stesso termine commerciale diversi nomi nel contratto di servizio Web e alcuni termini commerciali che hanno lo stesso nome nel contratto di servizio web. Oh, e naturalmente alcuni nomi usati su entrambi i lati della divisione, ma con significati diversi!

Se decidi di tradurre comunque, ti preghiamo di standardizzare la traduzione in un glossario, aggiungere la conformità con quel glossario alla tua definizione di fatto e verificarlo nelle tue recensioni. Non essere così incurante come lo siamo stati noi.

La soluzione corretta è di non codificare a fondo 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 specifici reparti nel tuo codice, devi chiedere più genericamente ciò che è speciale in quel dipartimento e accettare la configurazione di quel dipartimento come avente quella proprietà. Ad esempio, se un dipartimento ha una busta paga settimanale, ed è a questo che interessa il codice, dovrebbe esserci una proprietà WEEKLY_PAYROLL che può essere allegata a qualsiasi reparto dalla configurazione.

Per le persone che si chiedono: abbiamo scelto la prima opzione, principalmente perché pensiamo che non si debbano inventare termini per la traduzione. Tuttavia, se a volte uno sviluppatore internazionale avrebbe lavorato 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 di stringhe per mostrare all'utente o qualcosa del genere, basta definire una matrice di descrizioni all'interno dell'enum ed esporre un metodo.
Ad esempio: Department.BUILD.getDescription(); mostrerà "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 lanciasse la gente qui per caso.

MODIFICA: come notato da Pokechu22 puoi usare costruttori enum 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.

Si prevede che alcune invarianti del codice siano valide. Uno di questi invarianti è che un programma non si comporterà diversamente quando viene rinominato un identificatore. In questo caso, in particolare, quando si ha un enum e si rinomina qualsiasi membro di quell'enumerazione 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 datastrutture da esso. Quando prendi i dati esterni, li leggi e crei istanze del tuo enum, stai analizzando i dati. Questo processo di analisi è l'unica parte del tuo programma responsabile del mantenimento della relazione tra la rappresentazione dei dati come la ricevi e la forma e la denominazione dei membri dei tuoi tipi di dati.

In quanto tale, non dovrebbe importare quali nomi assegni ai membri dell'enum. Che coincidano con le stringhe usate nei dati che leggi è una coincidenza.

Quando si progetta il codice per modellare il dominio, i nomi dei membri non dovrebbero essere correlati al formato di serializzazione dei dati. Non dovrebbero essere né i termini olandesi, né dovrebbero essere le traduzioni dei termini olandesi, ma dovrebbero essere ciò che decidi si adatta 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.