Traduire des données externes dans la langue dans laquelle vous programmez
Je ne sais pas quoi faire des éléments suivants:
Nous prenons les données d'un outil externe dans notre propre outil. Ces données sont écrites en néerlandais. Nous écrivons notre Java en anglais. Devrions-nous alors traduire ce néerlandais en anglais ou le garder néerlandais? Par exemple, nous avons 2 départements: Bouw (Construction en anglais) & 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 Département en néerlandais)
Dans ce scénario, je laisserais l'énumération valeurs en néerlandais:
public enum Department { BOUW, ONDERHOUD }
Parce que la logique utilisant ces constantes correspondra aux données c'est aussi en néerlandais. Par exemple, si l'entrée est "bouw", le code de comparaison pourrait 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 juste un cerceau mental que je, en tant que développeur, ne devrait pas avoir à parcourir pour prouver l'exactitude.
Néanmoins, vous pouvez simplement commenter le code s'il aide les autres à comprendre le contexte des données:
public enum Department {
BOUW, /* build */
ONDERHOUD /* maintenance */
}
L'anglais est une lingua franca/plus petit dénominateur commun pour une raison. Même si la raison est conceptuellement aussi faible que "Tout le monde le fait", c'est toujours une raison assez importante.
Aller à l'encontre de la pratique courante signifie que vous devez comprendre le néerlandais pour comprendre les structures de données de votre logiciel. Il n'y a rien de mal avec le néerlandais, mais la probabilité qu'un ingénieur donné qui devra interagir avec la base de code le parle soit toujours inférieure à celle de l'anglais.
Par conséquent, à moins que vous ne soyez un magasin exclusivement néerlandais et que vous ne prévoyez pas de vous développer à l'international jamais, c'est presque toujours une bonne idée de garder votre base de code monolingue et d'utiliser le langage de codage le plus populaire.
Remarque: Ce conseil s'applique uniquement au code de programme . Les données des utilisateurs ne doivent certainement pas être traduites, mais traitées "telles quelles". Même si vous avez un client "Goldstein", il est clair que vous ne devez pas enregistrer son nom comme "pierre dorée".
Le problème 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 des clients sont très proches de la première extrémité du spectre, Java variables près de la dernière extrémité. Les constantes des valeurs de enum sont légèrement plus éloignées, en particulier si elles dénotent des éléments bien connus, entités externes uniques (comme vos départements). Si tout le monde dans votre organisation utilise les termes néerlandais pour les départements, vous ne prévoyez pas de confronter quiconque avec la base de code qui ne le fait pas, et l'ensemble des départements existants change rarement, puis en utilisant les noms acceptés du département peuvent avoir plus de sens pour les constantes enum que pour les variables locales, mais je ne le ferais toujours pas.
Évitez la traduction lorsque cela est possible, car chaque traduction représente un effort supplémentaire et peut introduire des bogues.
La contribution clé de "Domain Driven Design" à l'ingénierie logicielle moderne est le concept d'un biquitous Language , qui est un langage unique utilisé par toutes les parties prenantes d'un projet. Selon DDD, la traduction ne devrait pas se produire au sein d'une équipe (qui comprend des experts du domaine, même s'ils ne sont présents que par proxy d'un document de spécification), mais uniquement entre des équipes (lecture supplémentaire: "Domain Driven Design" par Eric Evans, en particulier les chapitres sur le langage ubiquitaire et la conception stratégique).
Autrement dit, si vos experts commerciaux (ou votre document de spécification) parlent le néerlandais, utilisez leur terminologie (néerlandaise) lors de l'expression des préoccupations commerciales dans le code source. Ne traduisez pas inutilement en anglais, car cela crée un obstacle artificiel à la communication entre les experts commerciaux et les programmeurs, ce qui prend du temps et peut (par une traduction ambiguë ou incorrecte) provoquer des bogues.
Si, en revanche, vos experts commerciaux peuvent parler de leur entreprise en anglais et en néerlandais, vous êtes dans la chance de pouvoir choisir la langue omniprésente du projet, et il y a des raisons valables de préférer l'anglais (comme "internationalement compréhensible et plus susceptibles d’être utilisés par les normes "), mais cela ne signifie pas que les codeurs doivent traduire ce dont parlent les hommes d’affaires. Au lieu de cela, les gens d'affaires devraient changer de langue.
Avoir une langue omniprésente est particulièrement important si les exigences sont complexes et doivent être implémentées avec précision, si vous faites juste CRUD, la langue que vous utilisez en interne importe moins.
Anecdote personnelle: j'étais dans un projet où nous avons exposé certains services commerciaux en tant que point de terminaison SOAP. L'entreprise a été entièrement spécifiée en allemand, et il est peu probable qu'elle soit réutilisée telle quelle en anglais, car il s'agissait de questions juridiques spécifiques à une juridiction particulière. Néanmoins, certains architectes de la tour d'ivoire ont exigé que l'interface SOAP soit en anglais pour promouvoir la réutilisation future. Cette traduction s'est produite à l'occasion, et avec peu de coordination entre les développeurs, mais seuls un glossaire partagé, ce qui fait que le même terme commercial a plusieurs noms dans le contrat de service Web et certains termes commerciaux ont le même nom dans le contrat de service Web. Oh, et bien sûr certains noms sont utilisés de chaque côté de la fracture - mais avec des significations différentes!
Si vous choisissez de traduire de toute façon, veuillez standardiser la traduction dans un glossaire, ajouter la conformité avec ce glossaire à votre définition de terminé et le vérifier dans vos critiques. Ne soyez pas aussi insouciant que nous l'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 trouvez la nécessité de tester des services spécifiques dans votre code, vous devez demander de manière plus générique ce qui est spécial à propos de ce service et accepter de configurer ce service comme ayant cette propriété. Par exemple, si un département a une paie hebdomadaire, et c'est ce qui importe au code, il devrait y avoir une propriété WEEKLY_PAYROLL qui peut être attachée à n'importe quel département par la configuration.
Pour toutes les personnes qui se demandent: nous avons choisi la première option, principalement parce que nous pensons que vous ne devez pas inventer de termes pour traduire. Cependant, si un jour un développeur international travaillait 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 avez peur d'avoir une représentation sous forme de chaîne pour montrer l'utilisateur ou quelque chose, définissez simplement un tableau de descriptions à l'intérieur de votre énumération et exposez une méthode.
Par exemple: 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 juste au cas où le vortex de Google jetterait des gens ici par accident.
EDIT: Comme indiqué par Pokechu22 vous pouvez utiliser des constructeurs d'énumération 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 aura également cet effet.
Certains invariants de votre code devraient 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 énumération, que vous renommez un membre de cette énumération et mettez à jour toutes les utilisations de ce membre, vous ne vous attendez pas à ce que votre code commence à fonctionner différemment.
L'analyse est le processus de lecture des données et d'en dériver des infrastructures de données. Lorsque vous prenez les données externes, les lisez et créez des instances de votre énumération, vous analysez les données. Ce processus d'analyse est la seule partie de votre programme chargée de maintenir la relation entre la représentation des données comment vous les recevez et la forme et la dénomination des membres de vos types de données.
En tant que tel, peu importe les noms que vous attribuez aux membres de l'énumération. Le fait 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. Il ne doit pas s'agir de termes néerlandais, ni de traductions des termes néerlandais, mais ils doivent correspondre à ce que vous décidez qui correspond le mieux au modèle de domaine.
L'analyseur qui traduit entre le format de données et votre modèle de domaine. C'est le dernier de l'influence que le format de données devrait avoir sur votre code.