Executando verificação de segurança...
6

Código em português: o lado do domínio

Fala pessoal, comecei a ler o livro Domain-Driven Design do Eric Evans (2003) e fiquei repensando a escolha feita de escrever o código do sistema em que trabalho em inglês. Além do fato de que pra várias pessoas da equipe o inglês é difícil, o livro traz a ideia de que, ao menos em alto nível, idealmente, o código deve ser legível pelos experts do domínio. Eu entendo que isso não é esperar que a equipe de negócio tenha fluência na leitura do código, mas que, ao discutir o desenvolvimento de uma funcionalidade, eu possa compartilhar minha tela e guiar a pessoa pelo código, discutindo a implementação das regras negociais (e ela entender). Considerando que a equipe de negócio também não tem um inglês avançado, não sei se foi a melhor escolha.
Como vocês veem isso?

Carregando publicação patrocinada...
7

Na nossa empresa, uma parte considerável dos projetos é integração entre outros sistemas.

A maior parte dessas integrações é baseada em um sistema chamado Winthor (um dos projetos TOTVS), esse sistema possui um domínio rico e complexo. Traduzir os termos para inglês nos trazia mais confusões do que esclarecimentos, e por estarmos fazendo uma integração em uma parte pequena desse domínio gigante, tentar usar outras palavras que os usuários usavam não era nada eficiente.

Então para integrações com outros sistemas, adotamos os termos usados pelos usuários. É claro que o resultado passa a ser um emaranhado de termos, como RequisicaoService, PedidoController, OrdemPagamentoManager e etc, mas no contexto do domínio do Winthor, traduzir Requisição para Request não faz sentido, gera ruído e o significado se perde. É possível que ao ler a palavra Request você pode ter achado que entendeu o termo, e certamente se surpreenderá quando um usuário do Winthor te explicar o que é uma Requisição para ele. Então, mesmo como essa "mistura feia" de português com inglês, após várias tentantivas, foi a que deu mais certo nesse ambiente.

Porém, para projetos que não são integrações, ou seja, aqueles que temos total controle do domínio e da documentação do mesmo, nos passamos a adotar o padrão em inglês para todo o código, menos para a mensagens de commit e documentação. Dois pontos importantes aqui:

  1. Na documentação, sempre mantemos um "dicionário", para quem estiver chegando entender o que o termo significa, não apenas a tradução mas também o que representa no domínio.
  2. Mensagens de commit e documentação em português, se expressar em código usando inglês é fácil, mas em mensagens de commit e documentação usar o português é muito mais simples e a comunicação é mais efetiva. A não ser que o time seja multinacional, mas não é nosso caso.
4

Eu acho um trabalho desnecessário e um aumento na carga cognitiva do desenvolvedor, ter que ficar traduzindo termos do português para o inglês. Até porque nem sempre existe uma tradução e será necessário usar o termo em português de qualquer forma (ex: RG, CPF, Boleto).

Misturar inglês com português nas nomenclaturas de símbolos (ex: nomes de funções, variáveis) é horrível. Por exemplo, ao invés de GetByAno acho mais adequado ObtemPorAno. A única exceção seriam os Getters e Setters em algumas linguagens (Ex: GetAno em uma classe java).

4

Foi discutido em uma das aulas no curso.dev uma temática parecida que acredito que pode ser extendida para o cenário de DDD. A discussão era sobre qual idioma as mensagens de commits deveriam ser escritas: português ou inglês.

Um consenso observado é de que se o único objetivo do mesmo for COMUNIÇÃO, seria mais indicado escolher o português (ou a língua nativa do time), uma vez que tanto você, quanto o time, teriam assim mais vocabulário. Mesmo que o inglês tenha palavras "melhores" ou mais "descritivas" para certos cenários, a maioria das pessoas irá se comunicar muito melhor, de uma forma mais exata e com muito menos esforço em português ~ vamos considerar o português como língua nativa desse contexto. Se isso não fosse verdade e o inglês fosse mais fácil, todas as empresas hoje em dia só se comunicariam em inglês.

Um experimento virtual fácil para provar isso, indicado pelo próprio Felipe Deschamps durante a aula, seria pedir para uma grande quantidade de pessoas escreverem ou falarem dois parágrafos, em inglês e português, e depois mensurar, de alguma forma, quanto de esforço vai levar pra deixar ambos com a mesma qualidade, clareza e cadência.

Todas essas considerações podem ser extendidas para a escolha da linguagem de código em DDD, uma vez que a comunicação é uma fator de extrema importância dentro dele, vide o conceito de Linguagem Ubíqua por exemplo. Claro que existem diversos contextos e variáveis únicas para cada cenário que devem ser levadas em conta para essa decisão, mas são pontos sempre importantes de serem discutidos e levantados.

3

repensando a escolha feita de escrever o código do sistema em que trabalho em inglês

Seu "sistema" é multinacional?

Quando o software é usado por pessoas de vários países recomendo escrever em inglês, até porque pode ser comprado por uma empresa maior e uma equipe internacional começar a trabalhar nele.

Se é algo 100% voltado para o Brasil e não tem planos de expansão a linguagem é indiferente.

Mas afinal inglês ou português?

Tanto faz, desde que a equipe esteja alinhada e o seu código tiver escrito em apenas uma linguagem.

Nada de getListPessoas

1

Acredito que o idioma no desenvolvimento não deveria ser um problema.
Para uma empresa nacional em que a aplicação será utilizada dentro do país, não vejo problema em ser em portugues.
Do mesmo modo caso seja uma empresa multinacional onde desenvolvedores de outros pais vão precisar acessar/dar manutenção no código, é interessante que seja em ingles para facilitar o entendimento e comunicação.

Particularmente não gosto de ficar misturando ingles/portugues no código, gosto sempre de pensar na legibilidade.