Nomes de métodos e variáveis devem ser no idioma do cliente

Recentemente Carlos Brando escreveu um excelente artigo em seu blog sobre nomes de métodos e variáveis. Dentre as diversas dicas, uma eu não concordei, comentei lá sobre isso, e o argumento de resposta não me foi convincente.

O ponto de discordância dizia respeito a necessidade de evitar código bilingue. Segundo ele, já que a maioria das linguagens de programação são em inglês, nada mais correto do que escrever o nome das classes e metódos também em inglês. Para começar vou contar uma pequena historinha:

Experiência própria: Laboratório geológico

Há um bom tempo atrás trabalhei em uma empresa que desenvolvia um sistema para um laboratório geológico. Um dia, um dos desenvolvedores do time ligou para tirar duvidas com o cliente e fez a seguinte pergunta "Quando um sample alcança um result no segundo stage em determinado job, ele pode parar os próximos stages ou deve seguir até a conclusão de todos".

O rapaz na outra ponta ficou completamente confuso. Era novo no laboratório, conhecia toda cadeia de análises de amostras mas não conhecia os estranhos termos que a equipe de desenvolvimento vira e mexe falava. Sample, result e stage não eram palavras de domínio do laboratório, e sim os seus similares em português. Mas como o sistema estava sendo desenvolvido com os termos em inglês, constantemente os membros do time de desenvolvimento, eu incluso, os citava, atrapalhando a comunicação e o entendimento dos problemas.

Eis então a pergunta: Será que um código que mistura termos em inglês e português causa mais problemas que os ruídos na comunicação com o cliente? Pode-se alegar que o código nem será mostrado ao usuário, mas na hora em que o desenvolvedor precisa se comunicar com o cliente, na mente dele ele não está trabalhando com amostras, ele está trabalhando com samples.

Mas o mais interessante é que dentre o domínio do laboratório geológico, um item era em inglês, o Job. Eles falavam amostras, estágio, resultados, mas falavam Job. Isso então nos leva a uma conclusão.

O idioma como ferramenta

A grande questão é que o idioma é apenas uma ferramenta para a comunicação. O primeiro item do manifesto ágil fala "Indivíduos e interação entre eles mais que processos e ferramentas". No caso, acredito que a interação entre os individuos, no caso a comunicação, é mais importante do que a ferramenta, que no caso é o idioma. Portanto eu prefiro priorizar a comunicação independente do idioma. Se meu cliente possuir termos em seu negócio em francês e outros em alemão, eu prefiro utilizá-los no meu sistema para que ao conversar com ele eu não me confunda com os termos usados na programação.

Um contra-argumento muito usado é dizer que utilizar termos em português em uma linguagem de programação em inglês torna o código sujo. Mas será que isso é realmente verdade?

Código limpo depende do idioma?

Antes de discutir é preciso definir o que é um código limpo. Em minha concepção código limpo é aquele fácil de entender. As técnicas apresentadas pelo Carlos Brando são realmente importantes. Mas será que o seguinte código é complicado de entender?

amostras = Amostra.obter_amostras_com_resultado_positivo
amostras.each do |amostra|
  puts amostra.produto.sigla
end

Será que o fato de utilizarmos inglês misturado com o português tornou mais dificil o seu entendimento? Eu não só creio que não, como acredito que por conta das expressões utilizadas pelo cliente serem idênticas ao do programa, o entendimento fica mais fácil ainda.

Dizer o contrário é o mesmo que defender o uso de arcabouço e chamada de retorno ao invés de framework e callback, em trabalhos acadêmicos somente por uma questão de purismo idiomático. É nesse público que políticos como o deputado Aldo Rebelo se mira, tentando aprovar projetos de lei perigosos.

Mas e o mercado internacional?

Outro ponto levantado para defender o uso de termos diferentes dos do domínio do cliente é a possibilidade de venda do software ao exterior em algum remoto dia. Ao meu entender isso é um pouco de síndrome do mapa de calor. Um problema comum em empresas de desenvolvimento que não seguem o manifesto ágil. Este tipo de argumento futurista era muito utilizado para defender que aplicações fossem escritas em Java. Coisas do tipo "E se um dia quisermos colocar esse software numa geladeira".

O interessante é que na resposta que recebi, foi citado que para não haver confusão nas conversas com o cliente poderíamos fazer as especificações em português. Mas oras, quando um software é vendido, as especificações vão juntas. Se for vendido para o exterior teríamos o mesmo problema. E pior ainda, as especificações, que dizem exatamente o que o sistema faz estariam em uma lingua diferente da do cliente.

O fato é que a possibilidade de se vender um sistema ao exterior em algum futuro remoto não deve se tornar um empecilho na comunicação com o cliente local, que é quem vai gerar receita mais brevemente. Se um dia realmente a venda for uma possibilidade real faz-se um refactory.

Só para constar, a desculpa para desenvolver o sistema exemplificado no ínicio do post em inglês foi exatamente esta. Hoje, 6 anos depois o foco da empresa mudou totalmente, nenhum outro sistema de laboratório foi vendido ou criado. Somente este continua em manutenção. Dos outros que desenvolvi em Java nenhum precisou trocar de sistema operacional ou mesmo ser instalado em geladeiras.

Enfim a conclusão

O que defendo não é programar em um idioma e não em outro. Defendo que deve-se programar o mais próximo da realidade. Se o seu cliente tiver todos os termos do seu negócio em inglês, ótimo, programe em inglês. Fora isso, vejo apenas dois outros motivos para basear sua programação no idioma britânico: O software que você está desenvolvendo é uma biblioteca ou framework open-source; Ou a maioria dos membros da sua equipe só fala inglês.