Olá! Este é um post da seção Além do Código, onde pretendo discutir algumas questões que influenciam o desenvolvimento de software mas não necessariamente tratam de implementações.

Neste post falarei um pouco sobre a relação entre Linguagem Ubíqua e o idioma utilizado no código. Esta é uma questão bastante frequente e, muito embora pareça simples, não é exatamente assim.

Vamos lá!

O que é a Linguagem Ubíqua

A Linguagem Ubíqua é um dos aspectos centrais em Domain-Driven Design (DDD) e diz respeito à forma como é feita a comunicação entre pessoas de negócio (especialistas de domínio) e engenharia dentro do que o DDD vai chamar de Contextos Delimitados, conceito que ficará para futuros posts.

Aqui temos uma definição muito boa de Martin Fowler a respeito, em tradução livre:

É a prática de construir uma linguagem comum e rigorosa entre desenvolvedores e usuários.
Deve se basear no modelo de domínio e, por isso, precisa ser rigorosa pois software não lida bem com ambiguidade.

Repare na palavra "rigorosa" acima. Ela indica que a linguagem deve ser a mais precisa possível a ponto de não admitir mais de um termo para se referir a um mesmo elemento do Modelo de Domínio (este também assunto para futuros posts), pois, desta forma, o risco de ruído na comunicação é drasticamente reduzido.

A questão do idioma

Quero discutir essa questão à luz do DDD, ou seja, como um praticante lidaria com ela. Ao mesmo tempo, levarei em consideração o fato de estarmos no Brasil e como isso influencia a decisão.

Código em Inglês

Muita gente acredita que codificar em inglês é o padrão e assim deve ser porque as linguagens de programação utilizam a lingua inglesa para oferecer suas instruções.

Quero desafiar esta noção com as seguintes perguntas:
1- Sendo a Linguagem Ubíqua baseada em elementos do negócio, faz sentido traduzi-los para o inglês no código se não for o idioma falado pelos especialistas de domínio? Seu time é capaz de garantir que não confundirá termos nos dois idiomas ao se comunicar com os especialistas de domínio de modo a levar esta confusão ao código?

2- Seu time tem fluencia não apenas em inglês como, também, nos termos de negócio quando nesse idioma? O código poderia ser lido por um anglófono (falante de inglês) de modo a ser compreendido sem a necessidade de recorrer a membros do time para "traduzir a tradução"?

Aqui é preciso lembrar que apenas 1% da população brasileira tem fluência em inglês e que, com certeza, nem todos nesse 1% atuam desenvolvendo software. Ou seja, as chances de haver erros importantes no código que possam criar confusão são grandes o bastante para gerar preocupação.

Exemplos simples

No mercado de capitais é muito comum falarmos em "ações". Ações são uma fração da propriedade de uma empresa e, em inglês, diz-se "stocks". Entretanto, em códigos que já tive a oportunidade de atuar, vi este termo traduzido literalmente como "actions".
Ao mesmo tempo, em contabilidade, há o termo "lançamento contábil", que é o ato de registrar uma movimentação financeira, que, em inglês, é chamado de "journal entry", e já o vi sendo traduzido como "launch", que é lançamento no sentido de projeção, como no lançamento de foguetes.

Partindo desses exemplos, deixo a pergunta: como um falante de inglês interpretaria esses termos? Faria sentido pra ele? E mais, se não é objetivo promover a interação de um anglófono, qual o sentido em traduzir os termos em primeiro lugar?

Código Híbrido

Esta é uma modalidade de código onde elementos técnicos são tratados em inglês, mas elementos do domínio são tratados, no nosso caso, em portugês.

Um exemplo simples seria uma classe chamada BoletoRepository, responsável pela persistência e recuperação de boletos junto a um banco de dados, cujo método de persistência seja Save e o de recuperação se chame GetById.

Aqui já temos um sinal claro de como essa abordagem pode ser problemática. Uma pergunta que eu faria é: o ID de um boleto é algo conhecido pelo negócio? Em caso positivo, é chamado de ID? Ou "identificador"? Se for chamado de identificador, há uma tradução que se torna difícil saber se este é um aspecto técnico (um ID na base de dados por exemplo) ou um aspecto de negócio. Ou seja, perde-se a rigidez pretendida pela Linguagem Ubíqua e pode-se gerar confusão, inclusive, caso um novo membro chegue à equipe, já que ele provavelmente entenderia, ao ler o código, tratar-se de uma questão técnica e não de negócio até que isso fosse esclarecido.
E aqui estamos falando apenas de um ID. Agora considere esse mesmo tipo de confusão distribuída pelo código por meio de diversos termos. Faz sentido assumir esse risco?

Código em Português

Este, talvez, seja o mais controverso entre os modelos possíveis. Isso porque existe, da mesma forma que uma predileção pelo inglês, uma forte rejeição ao português.

Vamos pegar o exemplo acima, de código híbrido, e fazer um teste:
Para o caso do repositório de boletos teríamos uma classe chamada RepositorioDeBoletos, com os métodos Salvar e ObterViaIdentificador. E então fica a pergunta: qual o real problema com este código? Ele é claro o bastante para indicar a ação sendo realizada bem como seu propósito e, mais importante, sendo português o idioma do negócio, o custo de tradução entre idiomas é zero. Ao mesmo tempo, por estar no idioma do negócio, um novo membro do time entenderia que o Identificador é um conceito de negócio e não um componente técnico. Parece bom. Não?

Isso significa que estou recomendando o uso de português? Não. Lembre-se de que, acima, afirmei que parece uma questão simples mas não é tanto, e agora vou explicar o porquê.

Determinismo Organizacional

Esse termo serve para dizer o seguinte: essa é uma questão cultural na organização. E aqui deixo três perguntas para provocar uma reflexão:
1- Sua organização tem/terá especialistas de domínio anglófonos, ou falantes de outros idiomas, demandando que toda a comunicação seja feita em inglês como língua franca?
2- Os membros do time estão aptos a codificar em inglês sem perder significados, evitando cair no problema da "tradução da tradução"?
3- Assumindo que sua organização contrate desenvolvedores de outros países, mas que mantenha o idioma do negócio em português, o que é mais barato? Qualificar os envolvidos para se comunicar em inglês? Ou trazer os anglófonos para o português?

Conclusão

Perceba que não há uma resposta simples e definitiva para esta pergunta. Cada organização precisa tratar do assunto com cautela, lembrando: caso optem por utilizar DDD como ferramenta para descrever o domínio, pois o custo de mudança é alto e as consequências podem ser negativas a depender da abordagem escolhida – é uma decisão mais importante do que parece!

Gostou deste post? Me deixe saber pelos indicadores. Fique à vontade para comentar ou me procurar em minhas redes sociais para prosseguir com o assunto.

Muito obrigado pela leitura, e até o próximo post.