Traducir datos externos al lenguaje en el que está programando

En este escenario, dejaría la enumeración valores en holandés:

public enum Department { BOUW, ONDERHOUD }

Debido a que la lógica que usa estas constantes coincidirá con los datos que también están en holandés . Por ejemplo, si la entrada es "bouw", el código de comparación podría verse así:

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

Me resulta más fácil depurar cuando los valores coinciden (incluso si no sé qué significan los valores). La traducción solo agrega un aro mental que, como desarrollador, no debería tener que saltar para demostrar la corrección.

Sin embargo, solo puede comentar el código si ayuda a otros a comprender el contexto de los datos:

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

Inglés es un lingua franca / mínimo común denominador por una razón. Incluso si la razón es conceptualmente tan débil como "Todo el mundo lo hace", sigue siendo una razón bastante importante.

Ir en contra de la práctica común significa que debe entender holandés para entender las estructuras de datos en su software. No hay nada malo con el holandés, pero la probabilidad de que un ingeniero determinado que tenga que interactuar con el código base sea tan bajo como el inglés.

Por lo tanto, a menos que sea una tienda exclusiva de Holanda y no planee expandirse internacionalmente alguna vez , casi siempre es una buena idea mantener su base de código monolingüe y usar la codificación más popular idioma.

Nota: Este consejo se aplica solo al código de programa . Los datos del usuario definitivamente no deben ser traducidos, sino procesados "como están". Incluso si tiene un cliente "Goldstein", claramente no debe guardar su nombre como "piedra dorada".

El problema es que hay un continuo de términos entre "suministrado por el usuario, no toque" y "fragmento de código, use inglés en todo momento". Los nombres de los clientes están muy cerca del extremo anterior del espectro, las variables de Java están cerca del último extremo. Las constantes para los valores de enum están un poco más alejadas, especialmente si denotan entidades externas únicas y conocidas (como sus departamentos). Si todos los miembros de su organización utilizan los términos holandeses para los departamentos, no planea confrontar a nadie con el código base que no lo hace, y el conjunto de departamentos existentes cambia raramente, entonces usar los nombres aceptados del departamento puede hacer más sentido para las constantes de enumeración que para las variables locales. Aunque todavía no lo haría.

Evite la traducción siempre que sea posible, porque cada traducción es un esfuerzo adicional y puede presentar errores.

La contribución clave de "Domain Driven Design" a la ingeniería de software moderna es el concepto de un Ubiquitous Language , que es Un solo idioma utilizado por todos los interesados en un proyecto. De acuerdo con DDD, la traducción no debe ocurrir dentro de un equipo (que incluye expertos en el dominio, incluso si está presente solo por el poder de un documento de especificación), sino solo entre equipos (lectura adicional: "Diseño dirigido por el dominio" por Eric Evans, en particular los capítulos). sobre Lenguaje Ubicuo y diseño estratégico).

Es decir, si sus expertos comerciales (o su documento de especificaciones) hablan holandés, utilicen su terminología (holandesa) cuando expresen sus preocupaciones comerciales en el código fuente. No se traduzca innecesariamente al inglés, ya que hacerlo crea un impedimento artificial para la comunicación entre los expertos en negocios y los programadores, lo que lleva tiempo y puede (a través de una traducción ambigua o mala) causar errores.

Si, por el contrario, sus expertos en negocios pueden hablar de sus negocios tanto en inglés como en holandés, tiene la suerte de poder elegir el idioma ubicuo del proyecto, y existen razones válidas para preferir el inglés (como " Entendible internacionalmente y es más probable que sea utilizado por las normas "), pero hacerlo no significa que los programadores deban traducir lo que los empresarios están hablando. En cambio, la gente de negocios debería cambiar de idioma.

Tener un lenguaje ubicuo es particularmente importante si los requisitos son complejos y deben implementarse con precisión, si solo estás haciendo CRUD, el lenguaje que usas internamente no importa.

Anécdota personal: estaba en un proyecto donde expusimos algunos servicios empresariales como un punto final SOAP. El negocio se especificó por completo en alemán, y es poco probable que se reutilice como en inglés, porque se trataba de asuntos legales específicos de una jurisdicción en particular. Sin embargo, algunos arquitectos de la torre de marfil ordenaron que la interfaz SOAP fuera inglesa para promover la reutilización futura. Esta traducción se realizó en hoc, y con poca coordinación entre los desarrolladores, pero solo un glosario compartido, que dio como resultado que el mismo término comercial tuviera varios nombres en el contrato de servicio web, y algunos términos comerciales que tuvieran el mismo nombre en el contrato de servicio web. Ah, y por supuesto, algunos nombres se usaron a ambos lados de la división, ¡pero con diferentes significados!

Si elige traducir de todos modos, estandarice la traducción en un glosario, agregue el cumplimiento de ese glosario a su definición de hecho y verifíquelo en sus revisiones. No seas tan descuidado como hemos sido nosotros.

La solución correcta es no codificar los departamentos en absoluto:

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

O, si es absolutamente necesario un tipo de departamento:

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

Si encuentra la necesidad de realizar pruebas contra departamentos específicos en su código, debe preguntar de forma más genérica qué tiene de especial ese departamento y aceptar que ese departamento tenga esa propiedad. Por ejemplo, si un departamento tiene una nómina semanal, y eso es lo que le importa al código, debería haber una propiedad WEEKLY_PAYROLL que se pueda adjuntar a cualquier departamento mediante la configuración.

Para cualquier persona que se pregunte: hemos elegido la primera opción, principalmente porque pensamos que no deberías inventar los términos por el hecho de traducir. Sin embargo, si en algún momento un desarrollador internacional trabajara en el proyecto, agregamos algunos documentos para explicarlo:

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

Si le preocupa tener una representación de cadena para mostrar al usuario o algo, simplemente defina una matriz de descripciones dentro de su enumeración y exponga un método.
Por ejemplo: Department.BUILD.getDescription(); generará "BOUW"

public enum Department { 
    BUILD,
    MAINTENANCE;

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

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

Sé que eligió lo contrario, pero por si acaso el vórtice de Google arroja gente aquí por accidente.

EDITAR: Como se señala en Pokechu22 puede usar enumres constructores y propiedades privadas como esta:

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

    private final String description;

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

    public String getDescription() {
        return description;
    }
}

que también logrará ese efecto.

Se espera que ciertos invariantes de tu código se mantengan. Una de esas invariantes es que un programa no se comportará de manera diferente cuando se cambia el nombre de un identificador. En este caso en particular, cuando tiene una enumeración y cambia el nombre de cualquier miembro de esa enumeración y actualiza todos los usos de ese miembro, no esperaría que su código comience a funcionar de manera diferente.

El análisis es el proceso de leer datos y derivar estructuras de datos a partir de ellos. Cuando toma los datos externos, los lee y crea instancias de su enumeración, está analizando los datos. Ese proceso de análisis es la única parte de su programa responsable de mantener la relación entre la representación de datos de cómo la recibe y la forma y el nombre de los miembros de sus tipos de datos.

Como tal, no debería importar qué nombres asigne a los miembros de la enumeración. Que coincidan con las cadenas utilizadas en los datos que lees es una coincidencia.

Cuando diseña su código para modelar el dominio, los nombres de los miembros no deben estar relacionados con el formato de serialización de los datos. No deben ser los términos en holandés, ni deben ser traducciones de los términos en holandés, pero deben ser lo que usted decida que se ajuste mejor al modelo de dominio.

El analizador que se traduce entre el formato de datos y su modelo de dominio. Esa es la última influencia que debe tener el formato de datos en su código.