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

29

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?

naming

— Zeemee
fonte

11

Inglês. Língua franca para programação.

— Rig

6

Um dos 'desafiadores' mensagens de erro mais PHP tem uma torção hebraico interessante: unexpected T_PAAMAYIM_NEKUDOTAYIM. Tendo visto isso algumas vezes na minha vida, não tenho dúvidas de que se deva usar o inglês.

— precisa saber é o seguinte

3

Alguma das expressões específicas de domínio em alemão possui caracteres não padrão (por exemplo, umulauts (sp?))? Se você contratar programadores fora da sua região, eles poderão não encontrar um teclado com os caracteres necessários (o meu não). Sim, existem maneiras de mudar o idioma 'digitado', mas eu não gostaria desse aborrecimento.

— Clockwork-Muse

2

Grego - o uso de alfabetos não latinos é melhor segurança do que o klingon.

— Wyatt Barnett

3

@ O X-Zero saindo do ASCII comum abre a lata de "worms que codificação de caracteres usamos". Geralmente você é mordido e não vai lá novamente.

16

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.

— lurkerbelow
fonte

2

Esta resposta reflete mais minha opinião pessoal, depois de ler as outras respostas. Especialmente este ponto: "É uma complexidade desnecessária se todos os outros desenvolvedores também forem alemães" ao traduzir tudo.

— Zeemee 20/08/2012

1

@Mulmoth: "É uma complexidade desnecessária se todos os outros desenvolvedores também forem alemães" --- Como você pode ter certeza de que em algum momento, em alguns anos, o projeto não será terceirizado para outro país? Como você pode ter certeza de que um desenvolvedor que não fala alemão não será introduzido no projeto em algum momento?

— Coral Doe

5

@ Coral Doe - Eu acho que o desenvolvedor novo / outro / terceirizado já precisa se aprofundar no domínio comercial e em suas expressões específicas. Portanto, é mais fácil mapear o que o cliente (que ainda será alemão na época) sais para as classes nomeadas em alemão é o nome dos nomes em inglês com tradução incorreta / incorreta.

— Zeemee

2

As "coisas" relacionadas à cobrança / impostos na Alemanha nunca serão terceirizadas para um país que não fala alemão. Na universidade, alguém me disse que 85% de todos os livros de cobrança / impostos se referem às leis alemãs e são escritos em alemão. no mundo todo.

— Lurkerbelow 20/08/2012

3

Concordo, mas um problema que quase sempre acontece é que a linguagem usada pelos desenvolvedores vaza para os usuários e outras partes interessadas. Não como parte da interface do usuário, mas como você fala sobre o domínio do problema. Isso inevitavelmente levará a confusão, pois nem todos são tão fluentes em inglês quanto a maioria dos desenvolvedores.

— Mille Bessö 22/08/2012

14

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.

— Sylwester
fonte

5

Quase "faculdade" editada para o que eu suponho que seja "colega", mas eu não tinha certeza se era intencional.

— 27412 Jacob Schoen

Claro que eu queria dizer colega :)

— Sylwester

Of course some words or concepts might not have a English counterpart- Estou sempre curioso quando isso acontece na programação, quase como se você conhecesse um padrão de design que os falantes apenas em inglês não apresentariam. Você tem um exemplo rápido?

— Izkata

5

@ Izkata: a pergunta era sobre classes de negócios . Eles estão mais frequentemente vinculados a regras e regulamentos específicos de cada país. Por exemplo, se a lei obriga a rastrear a localização de todos os caminhões com produtos químicos perigosos, você pode muito bem nomear essa classe depois dessa lei.

— MSalters

9

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.

— Dimitrios Mistriotis
fonte

9

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.

— empi
fonte

4

Esse é um bom ponto: se todo o conhecimento do domínio estiver no idioma local e não existirem nomes em inglês acordados para os conceitos de domínio, usar o idioma local pode ser uma boa ideia.

— Joachim Sauer

7

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.

2

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.

1

Seu parágrafo final contradiz totalmente o seu primeiro, ao que parece

— James

@ James - obrigado! Eu removi essa seção porque não tenho tempo no momento para esclarecer o que eu quis dizer. Deveria estar apoiando, mas não importa.

1

Discordo fortemente. Como os principais conceitos de praticamente todos os idiomas que você conhece são escritos em inglês, o uso de terminologia que não seja o inglês leva a um código fonte menos legível. A mente constantemente precisa pular entre o inglês e o outro idioma. O código deve ser fluente e legível.

— 11558 Mike Adler

@ MikeAdler - não está claro se você discorda do que eu sugiro como regra geral (nomeie as coisas no idioma da equipe) ou o caso de exceção que deve ser muito raro.

Concedido. Vou esclarecer: eu discordo que qualquer objeto deve ser nomeado em um idioma que não seja o inglês. Seu primeiro cabeçalho 'Projetos de código aberto / de comunidade internacional' reflete muito bem meu ponto de vista. Tudo depois disso, não estou comprando. O motivo, como afirmado, é a manutenção, que deve ser uma preocupação primordial para praticamente todas as decisões de design (incluindo esquema de nomeação) que você toma, na minha opinião.

— Mike Adler