Traduire des données externes dans la langue dans laquelle vous programmez

Je ne sais pas quoi faire avec ce qui suit:

Nous prenons les données d'un outil externe dans notre propre outil. Ces données sont écrites en néerlandais. Nous écrivons notre code Java en anglais. Devrions-nous alors traduire ce néerlandais en anglais ou le garder en néerlandais? Par exemple, nous avons 2 départements: Bouw (Construction en anglais) et Onderhoud (Maintenance en anglais).

Serait-il alors logique de créer:

public enum Department { BOUW, ONDERHOUD }

ou:

public enum Department { CONSTRUCTION, MAINTENANCE }

ou même:

public enum Afdeling { BOUW, ONDERHOUD }

(afdeling est Department en néerlandais)

Dans ce scénario, je laisserais les valeurs enum en néerlandais:

public enum Department { BOUW, ONDERHOUD }

Parce que la logique utilisant ces constantes correspondra à des données également en néerlandais . Par exemple, si l'entrée est "bouw", le code de comparaison peut ressembler à:

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

Je trouve plus facile de déboguer lorsque les valeurs correspondent (même si je ne sais pas ce que signifient les valeurs). La traduction ajoute simplement un cerceau mental et, en tant que développeur, je ne devrais pas avoir à passer à travers pour prouver l'exactitude.

Néanmoins, vous pouvez simplement commenter le code s'il aide les autres utilisateurs à comprendre le contexte des données:

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

L'anglais est un linguiste commun / plus petit dénominateur commun pour une raison. Même si, théoriquement, la raison est aussi faible que "Tout le monde le fait", cela reste une raison assez importante.

Aller contre la pratique courante signifie que vous devez comprendre le néerlandais pour donner un sens aux structures de données dans votre logiciel. Il n'y a rien de mal avec le néerlandais, mais la probabilité pour un ingénieur donné d'interagir avec la base de code est toujours inférieure à celle de l'anglais.

Par conséquent, à moins que vous êtes un Néerlandais seule boutique, et ne prévoyez pas d'étendre au niveau international jamais , il est presque toujours une bonne idée de garder votre base de code monolingue et utiliser le langage de codage les plus populaires.

Remarque: Ce conseil s’applique uniquement au code de programme . Les données utilisateur ne doivent en aucun cas être traduites, mais traitées "telles quelles". Même si vous avez un client "Goldstein", il est clair que vous ne devriez pas stocker son nom sous le nom "pierre dorée".

Le problème, c'est qu'il existe un continuum de termes entre "fourni par l'utilisateur, ne touchez pas" et "fragment de code, utilisez l'anglais à tout moment". Les noms de clients sont très proches de la première extrémité du spectre, les variables Java près de la dernière extrémité. Les constantes des enumvaleurs sont légèrement plus éloignées, en particulier si elles désignent des entités externes uniques et connues (comme vos services). Si tout le monde dans votre organisation utilise les termes néerlandais pour les départements, vous ne prévoyez pas de confronter les utilisateurs avec la base de code qui ne le sait pas, et l'ensemble des départements existants change rarement. sens pour les constantes enum que pour les variables locales. Je ne le ferais toujours pas, cependant.

Évitez autant que possible la traduction, car chaque traduction représente un effort supplémentaire et peut introduire des erreurs.

La contribution essentielle de "Domain Driven Design" au génie logiciel moderne est le concept de langage ubiquitaire , qui est un langage unique utilisé par toutes les parties prenantes d'un projet. Selon DDD, la traduction ne devrait pas être effectuée au sein d’une équipe (y compris les experts du domaine, même si elle n’est présente que par procuration d’un document de spécification), mais uniquement entre les équipes. sur la langue omniprésente et la conception stratégique).

Autrement dit, si vos experts métier (ou votre document de spécification) parlent le néerlandais, utilisez leur terminologie (néerlandaise) pour exprimer des préoccupations d’entreprise dans le code source. Ne traduisez pas inutilement en anglais, car cela créerait un obstacle artificiel à la communication entre experts métier et programmeurs, ce qui prend du temps et peut (par une traduction ambiguë ou incorrecte) causer des bugs.

Si, au contraire, vos experts métier peuvent parler de leurs affaires en anglais et en néerlandais, vous êtes dans la situation privilégiée de pouvoir choisir la langue omniprésente du projet et il existe des raisons valables de préférer l'anglais (comme "internationalement compréhensible et plus susceptibles d’être utilisées par les normes "), mais cela ne veut pas dire que les codeurs doivent traduire ce que les gens d’affaires parlent. Au lieu de cela, les gens d’affaires devraient changer de langue.

Avoir un langage omniprésent est particulièrement important si les exigences sont complexes et doit être mis en œuvre avec précision. Si vous ne faites que du CRUD, le langage que vous utilisez en interne est moins important.

Anecdote personnelle: J'étais dans un projet où nous avons exposé certains services métier en tant que point de terminaison SOAP. L’entreprise était entièrement spécifiée en allemand et ne serait probablement pas réutilisée telle quelle, car il s’agissait de questions juridiques propres à une juridiction donnée. Néanmoins, certains architectes de tours d’ivoire ont demandé que l’interface SOAP soit en anglais afin de promouvoir la réutilisation future. Cette traduction s’est produite de manière ponctuelle, avec peu de coordination entre les développeurs, mais un glossaire partagé a été trouvé, le même terme commercial ayant plusieurs noms dans le contrat de service Web et certains termes commerciaux ayant le même nom dans le contrat de service Web. Oh, et bien sûr, certains noms ont été utilisés de part et d'autre de la ligne de démarcation - mais avec des significations différentes!

Si vous choisissez malgré tout de traduire, normalisez la traduction dans un glossaire, ajoutez la conformité avec ce glossaire à votre définition de done et vérifiez-la dans vos avis. Ne soyez pas aussi insouciant que nous avons été.

La bonne solution consiste à ne pas coder en dur les départements:

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

Ou, si vous avez absolument besoin d'un type de département:

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

Si vous avez besoin de tester des départements spécifiques dans votre code, vous devez demander de manière plus générique ce qui est spécial à propos de ce département et accepter de configurer ce département comme ayant cette propriété. Par exemple, si un service a une masse salariale hebdomadaire et que le code importe, il devrait y avoir une propriété WEEKLY_PAYROLL pouvant être attachée à tout service par la configuration.

Pour tous ceux qui s’interrogent: nous avons choisi la première option, principalement parce que nous pensons qu’il ne faut pas inventer de termes pour traduire. Cependant, si un développeur international travaille parfois sur le projet, nous avons ajouté de la documentation pour l'expliquer:

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

Si vous êtes inquiet à l'idée d'avoir une représentation sous forme de chaîne à montrer à l'utilisateur ou à quelque chose, définissez simplement un tableau de descriptions à l'intérieur de votre enum et exposez une méthode.
Ex: Department.BUILD.getDescription();affichera "BOUW"

public enum Department { 
    BUILD,
    MAINTENANCE;

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

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

Je sais que vous avez choisi le contraire, mais au cas où Google Vortex jette les gens ici par accident.

EDIT: Comme noté par Pokechu22, vous pouvez utiliser des constructeurs d’ énum et des propriétés privées comme ceci:

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

    private final String description;

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

    public String getDescription() {
        return description;
    }
}

qui permettra également d'atteindre cet effet.

Certains invariants de votre code sont censés tenir. L'un de ces invariants est qu'un programme ne se comportera pas différemment lorsqu'un identifiant est renommé. Dans ce cas en particulier, lorsque vous avez une enum, et que vous renommez un membre de cette enum et mettez à jour toutes les utilisations de ce membre, vous ne vous attendez pas à ce que votre code commence à fonctionner différemment.

L'analyse syntaxique est le processus de lecture de données et de dérivation de ses infrastructures de données. Lorsque vous prenez les données externes, les lisez et créez des instances de votre enum, vous analysez les données. Ce processus d’analyse est la seule partie de votre programme responsable du maintien de la relation entre la représentation des données, de la façon dont vous la recevez, et de la forme et de la désignation des membres de vos types de données.

En tant que tel, peu importe les noms que vous attribuez aux membres de l’énum. Qu'elles coïncident avec les chaînes utilisées dans les données que vous lisez est une coïncidence.

Lorsque vous concevez votre code pour modéliser le domaine, les noms des membres ne doivent pas être liés au format de sérialisation des données. Ils ne doivent ni être les termes néerlandais ni des traductions des termes néerlandais, mais ils devraient correspondre à ce que vous choisissez le mieux adapté au modèle de domaine.

L'analyseur effectue la traduction entre le format de données et votre modèle de domaine. C'est la dernière influence du format de données sur votre code.