Em que idioma devo nomear minhas classes de negócios?

Estou solicitando as melhores práticas com esta pergunta. Isso é apenas um problema se a empresa cliente for estritamente nacional e tiver um idioma nativo que não seja o inglês, eu acho.

Se o cliente tiver muitas expressões principalmente específicas do domínio (por exemplo, alemão), combinadas com algumas denominações específicas do domínio menores. O idioma dos comentários do código, nomes de classe / método / variável é inglês. Você traduziria todos os nomes específicos de domínio?

Estou trabalhando na Alemanha e prefiro escolher inglês.

Às vezes, por exemplo, coisas específicas do domínio, como criar um módulo para "DATEV" (software de faturamento / cobrança em alemão), eu uso nomes em alemão. Algumas palavras em alemão não podem ser traduzidas corretamente, por exemplo, "Referenzbuchungsnummer" (ReferenceBookingNum?) Ou "Sachkontenlaenge" (..?). Também acho que coisas específicas de domínio terminariam em horror de manutenção. Talvez você se lembre que o ReferenceBookingNum se relacionaria com "Referenzbuchungsnummer", mas e seus colegas de trabalho? Eles precisam estudar a documentação interna sobre nomeação, se houver documentação. Eles não estarão muito familiarizados com o módulo sem ter nomes próprios. É uma complexidade desnecessária se todos os outros desenvolvedores também forem alemães. Mas "CakeFactory" soa muito melhor que "KeksFabrik";)

Então tudo depende.

Sendo norueguês trabalhando em uma empresa norueguesa, nomeio meus objetos em inglês. É claro que algumas palavras ou conceitos podem não ter uma contrapartida em inglês e, nesse caso, pode-se argumentar que uma palavra nativa pode ser usada no lugar de uma substituição incorreta ou tradução literal que não tem significado. Obviamente, muitos desses problemas podem ser o fato de que alguns de nós devem ter um vocabulário melhor, então eu geralmente pergunto a um colega se não consigo pensar em um bom nome em inglês :)

Alguns de nossos funcionários não são noruegueses e, portanto, a escrita em inglês os beneficia. Ser capaz de contratar programadores da maior parte da Europa é bom para a economia, por isso minha empresa também se beneficia.

BTW: Lembro que li a fonte do Hermes uma vez (implementação do ebXML b2b) e teria dificuldade em escrever e comentar em mandarim.

Acredito que, como o inglês é a língua franca do domínio de TI, limitar o código-fonte a outro idioma cria obstáculos artificiais ao seu desenvolvimento. Primeiro você limita o número de pessoas que podem contribuir para aquelas que falam um idioma específico. O mesmo motivo que você pediu na troca de pilhas e não em um site local.

Além disso, você não sabe de onde virão as contribuições e para onde irá. E se você usar uma amostra de um site, você traduzirá isso? E se o produto se expandir para ser usado por clientes em outro país? Caso você precise contratar um contratado / terceirizar um pouco? Por que limitar a uma piscina e não obter o melhor ajuste de todo o mundo?

Pode-se supor que está bom para algumas estruturas específicas de domínio que não são mapeadas facilmente para outros idiomas ou se uma base de código existente é mantida.

Meu último objetivo do projeto foi modelar o domínio comercial de garantias e hipotecas. Todos os desenvolvedores e a empresa em que trabalhamos são da Polônia. Construímos o software seguindo os princípios de Design Orientado a Domínio. Usamos nomes poloneses para todas as entidades comerciais e acho que foi uma escolha muito boa. Penso que conseguimos evitar problemas de comunicação graças a esta abordagem. O domínio comercial consistia em muitos termos que eu nem conhecia em polonês, sem mencionar as traduções para o inglês. Utilizamos apenas letras latinas e todas as classes técnicas foram nomeadas em inglês.

Geralmente é mais fácil ler o código fonte escrito em um único idioma. Isso para a maioria das linguagens de programação implica que você deve escrevê-lo em inglês.

Dito isto, há um grande problema com os conceitos de domínio que não se traduzem facilmente para o inglês. Um exemplo típico é um identificador único que a sociedade fornece ao indivíduo - nos EUA, o conceito mais próximo é o número da previdência social, mas não é um mapeamento preciso. Nomes e números de telefone geralmente mapeiam muito bem.

Acredito que geralmente é necessário manter os termos do domínio sempre que um mapeamento preciso não estiver prontamente disponível em inglês, mas apenas aqueles - mantenha o restante em inglês. Isso resultará em identificadores incomuns, como o KommuneImpl, mas deve fazer sentido imediatamente para quem conhece o domínio.

Projetos de código-fonte aberto / internacionais da comunidade

O idioma comum dos projetos de código aberto e da comunidade internacional é o inglês. Caso em questão, o idioma dos sites do Stack Exchange é o inglês. Para uma acessibilidade mais ampla, o inglês deve ser usado para todos os nomes de código e objeto.

Projetos Comerciais

A maioria das empresas internacionais de software exige que o código seja escrito em inglês. É o maior denominador comum, por isso faz sentido usar o inglês como um meio para criar consistência.

Muitas empresas de software regionais escrevem em seu idioma nativo. Nem todos seguem essa abordagem, mas faz sentido do ponto de vista deles - eles usam a linguagem comum para todos os seus desenvolvedores.

Nomeando objetos de negócios

A linguagem de codificação da equipe deve ser usada para nomear objetos.
A prioridade é que os desenvolvedores possam se comunicar uns com os outros sobre os objetos e os requisitos do projeto. Se a equipe escrever em francês, os objetos de negócios deverão ser nomeados em francês. Se eles codificarem em inglês, nomeie os objetos em inglês.

Sua pergunta adiciona uma ruga porque o cliente fala um idioma nativo que não seja o idioma de codificação da sua equipe. Você ainda deve usar a linguagem de codificação da sua equipe para nomear os objetos.
Quando os analistas de negócios ou desenvolvedores precisam se comunicar com o cliente sobre os objetos de negócios específicos, pode ser necessária uma tradução conforme o nome do objeto da linguagem de codificação para a linguagem do cliente. Pela minha experiência, é muito raro falar sobre objetos de código específicos com o cliente, para que a tradução de volta para o idioma do cliente não seja realmente necessária.

A única exceção à regra de nomeação é quando um objeto não possui outro termo suficientemente conciso para capturar a intenção do objeto. IMO, isso é realmente raro, mas pode ocorrer. Na realidade, porém, é a mesma coisa que as línguas faladas fazem para expressar conceitos particulares. " Fachada " é originalmente um termo francês, mas foi adaptado pelo inglês para expressar o conceito e é um padrão de design comum. " Schadenfreude " é outro bom exemplo de um termo emprestado, embora eu não ache que ele tenha um padrão correspondente.