segunda-feira, 16 de março de 2009

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.

21 comentários:

  1. Concordo 100%. Trata-se da Linguagem Ubíqua do Domain-Driven Design!

    ResponderExcluir
  2. Tiago,

    No exemplo que você deu, até concordo que não parece tão ruim, mas o que dizer de algo assim:

    Amostra.new.should_not be_nil

    Ou algo assim:

    number_to_currency(amostra.produto.preco, :unit => "R$ ", :separator => ",", :delimiter => ".")

    É a minha opinião, não me leve a mal, mas quando vejo coisas assim não consigo imaginar que isto seja um bom trabalho.

    ResponderExcluir
  3. Carlos, acho que um bom trabalho é não perder o foco na comunicação com o cliente. De qualquer forma o seu exemplo também não é ruim, até porque o seguinte exemplo também não é tão bom do ponto de vista de inglês não é?

    Sample.new.should_not be_nil

    Pense bem, no inglês o correto seria new Sample. Então pela sua concepção o correto é usar outra linguagem, como Java por exemplo.

    E tem mais, se é feio Amostra.new, é mais feio ainda o sugerido por você:

    describe Sample do
    it 'deveria não ser nulo' do
    Sample.new.should_not be_nil
    end
    end

    Até não acho que seja um trabalho ruim, desde que Sample esteja no domínio do cliente.

    ResponderExcluir
  4. Concordo com o Tiago Motta. Essa visão é algo que Eric Evans fala em seu livro DDD (Domain Driven Design) sobre Ubiquitous Language.

    O código deve refletir os termos que o cliente usa. Isso facilita a comunicação com o cliente, entre desenvolvedores e a manutenção do sistema.

    Se os termos são em ingles, programe as classes com nomes em ingles.

    ResponderExcluir
  5. Seus argumentos são bons, mas o desenvolvedor do time usar termos "técnicos" (digo "técnicos" por que usando os termos em inglês ele se referia aos modelos no sistema, e não o que ela representa na realidade) para falar com o cliente seria o mesmo que um advogado usasse termos técnicos para explicar para um leigo o resultado de um processo.

    Acho que para uma boa comunicação é importante também saber com quem e para quem se está falando ;)

    Eu prefiro programar com tudo em inglês, e sempre que vou perguntar/explicar/conversar com alguém sobre o sistema falo na lingua da pessoa, as vezes é o atendimento da conta, as vezes é o gerente do projeto, as vezes é outro desenvolvedor, e algumas vezes é o usuário/cliente.

    ResponderExcluir
  6. Eu não concordo Tiago. Tenho trabalhado com projetos em que tudo estava em ingles e nos momentos de conversação com o cliente tudo mundo conseguia falar tudo em portugues sem dificuldades, pelo que acredito que o problema mencionado no post seja por causa do desenvolvedor e não do sistema.

    E se tiver programando em Java por exemplo, e o cliente dizer que tal processo receve um texto e o outro devolve um texto e um monte de coisa com texto, você acha que deveria criar uma classe Texto? String estaria fora do dominio correto?

    abs

    ResponderExcluir
  7. Diego, nem tanto, acredito que não vale a pena reimplementar algo que já exista. Além disso o termo "String" tanto não é o equivalente a "texto" em inglês como não é em português. Ou seja, usá-lo para esse domínio mostra que nem assim você está programando em inglês.

    Assim como quando se usa o método gsub você não está programando em inglês. O fato é que idiomas se misturam tanto na fala quanto na programação. No caso da String já é comum para todos os programadores a associação com texto. Assim como Integer é comum para inteiro. No caso de um domínio de um cliente, um domínio totalmente diferente, onde não há tipos ou classes definidas não faz sentido defini-las em inglês somente com a desculpa de deixar o código bonitinho. Até porque como já expliquei no post:

    "Antes de discutir é preciso definir o que é um código limpo. Em minha concepção código limpo é aquele fácil de entender"

    Se você não entende um "Amostra.new" é porque ou você não sabe português, ou não sabe inglês. Como provavelmente você sabe os dois, é bem mais fácil você programar assim, pois é menos conflituoso na hora de conversar com o cliente. Embora, como você mesmo citou isso não quer dizer que com certeza a comunicação sairá errada se fizer o contrário. Mas é no mínimo desnecessário manter essa ambiguidade somente por uma questão de estética duvidosa de código.

    O que é mais fácil? Você se confundir com um código Amostra.new ou o cliente não entender uma pergunta quando você sem querer pergunta falando uma palavra que não está no dominíno dele?

    Se a sua resposta é que você se confundiria mais com um código misturando português com inglês. Bom, tá aí o problema.

    ResponderExcluir
  8. Também não concordo. Se a idéia, principalmente do Ruby é uma linguagem mais humana e legível, creio que o melhor seja unificar o idioma, de forma que o código pareça mais um texto do que um algoritimo.

    No caso de um desenvolvedor se comunicar com o cliente, já tive essa experiência e era um bacalhau só na hora de trocar informações, mas eu programava de forma única e falava misturado, de forma que o cliente e eu entendêssemos.

    ResponderExcluir
  9. Joe, exatamente, com um só desenvolvedor pode ser até simples. Mas normalmente desenvolve-se em time. Times que mudam ao longo do tempo e que precisam se acostumar aos novos termos.

    E não concordo com a opinião de que unificar idioma faça o programa parecer mais texto do que algoritimo. Isso é similar a indicar que usar termos inglês em um texto em português faça-o parecer algoritimo. Não faz sentido.

    Idioma é ferramenta de entendimento. Se você entende os dois ou três idiomas utilizados. Você entende o código. gsub, [], => não são termos em inglês.

    ResponderExcluir
  10. Também acho que códigos devem ser 100% em inglês. como já disseram anteriormente, é obrigação de quem está prestando atendimento falar num indioma que o cliente entenda (no caso, ele vai usar os termos em portugues para falar, mas ingles para codificar).

    Acho que o maior problema em geral para fazerem isso é na falta de conhecimento de inglês, que eu considero uma lástima para quem está na área de informatica, onde se você não souber inglês, você vai estar sempre um passo atrás dos outros (porque sim, sempre que alguem cria livros ou cria novos artigos, quando se quer antingir o maior público possível sempre se escreve em inglês, mesmo que não seja seu indioma nativo, e para quem não sabe inglês vai ter que esperar alguem fazer uma tradução, então já vai estar um passo atrás dos outros).

    Para casos expecíficos onde o indioma do cliente é mais difícil e você não conhece tantas palavras, fica com o Carlos disse, tradutor do google ta por ai :P

    ResponderExcluir
  11. Wilker, concordo que é obrigação de quem é da área saber inglês. Isso nem está em discussão. Contudo, não podemos obrigar o cliente a saber inglês.

    ResponderExcluir
  12. Então, o que vocês estão dizendo é que o nome das variáveis e dos objetos devem ser NO MESMO IDIOMA da linguagem que eu estou programando? É esse o parâmetro? Então caso eu esteja programando em uma linguagem em que as palavras-chave são em português, então as variáveis e objetos devem ter nome em português, né? É isso que vocês estão dizendo??? Não faz o menor sentido. Vão ler sobre DDD, por favor!

    ResponderExcluir
  13. Anselmo, pois é eu também gostaria que as pessoas lessem sobre DDD. E um pouco mais sobre metodologia ágil: Indivíduos e interação entre eles mais que processos e ferramentas.

    Idioma é ferramenta!

    ResponderExcluir
  14. "todo o comportamento do sistema deveria estar implementado em classes cujos nomes fazem parte do domínio do problema. Nomes que têm o mesmo significado tanto para a equipe técnica quanto para clientes e usuários finais"

    http://gcirne.wordpress.com/tag/ubiquitous-language/

    ResponderExcluir
  15. O ponto de usar os termos na mesma língua que o cliente usa é facilitar a comunicação. A comunicação é certamente o principal fator de falha de projetos de software. O processo mental desnecessário de tradução entre o que está no código e o que o cliente entende só contribui para piorar essa comunicação.

    Note que isso vale para termos na mesma língua tb. Se o cliente usa "notícia" não faz sentido nenhum termos no código o termo "reportagem" para significar notícia. Criamos um mapeamento totalmente desnecessário que só atrapalha.

    ResponderExcluir
  16. Unica coisa que vale a pena ler nessa pagina eh o comentario do Carlos Brando.

    ResponderExcluir
  17. nofxx, sem dúvida, embora não haja um contra-argumento no comentário dele, apenas uma citação abstrata do que "acha" . Todos os comentários são válidos para a discussão.

    ResponderExcluir
  18. Quem suja o código é o programador, não o idioma. Depende apenas dos caprichos de quem programa.


    Em particular, sempre preferi programar em inglês por alguns motivos ortográficos e gramaticais:
    - É gramaticalmente mais sucinto. Não há uma presença forte de preposições e estatisticamente acredito que a palavras são menores que suas correspondentes no idioma tupiniquim.
    - É mais coerente. As linguagens de programação estão em inglês e, para mim, códigos são como textos e devem ser lidos como tal. Misturar seria como ter vários parágrafos em línguas distintas.
    - É ortograficamente mais consistente. Não há recursos como acentos, cedilhas, tremas e hífens. Retire os acentos de "é" e "está" e você tem duas palavras bem diferentes.
    - Sensação de formalidade.
    - Boa parte da literatura de programação está toda em inglês. Isso aproxima teoria e prática.


    Contudo, programar em português também traz algumas vantagens:
    - Não há choque com palavras-reservadas
    - Diferenciação clara entre identificadores de métodos e variáveis nativos e os definidos pelo programador (como bem notou o autor numa conversa que tivemos).
    - É nossa língua natural. Flui mais facilmente para ler/escrever.
    - Nivela por baixo. Sempre tem alguém na equipe que tem dificuldades com inglês.


    Agora, vamos ao principal argumento do Tiago. Realmente acho muito pertinente ele trazer à luz essa questão da comunicação com cliente. A conversão do jargão técnico para outro idioma gera dois trabalhos desnecessários: o tempo que se busca para encontrar as palavras adequadas em inglês e o esforço para se traduzir ou explicar os termos para o cliente. Isso não impossibilita mas certamente dificulta um pouco esse aspecto tão tortuoso e delicado da comunicação: o diálogo.


    Todavia, isso não significa necessariamente que todos os métodos e variáveis devem ser totalmente em português. Vejamos o que acontece no mundo real. Em nossa linguagem natural, principalmente na cultura ocidental, o estrangeirismo está bastante presente em textos escritos e falados. É muito comum se falar em "acessar web", "mover o mouse" ou "desligar o abajour".
    Assim, assumindo que códigos devem ser como textos, considero perfeitamente plausível construções como "isAmostra", "getEstagio()" ou "onTesteReady".


    Por ora, continuo com inglês sem condenar o português. Espero ter acrescentado algo ou, pelo menos, ter botado mais lenha na fogueira. :D

    ResponderExcluir
  19. Mas nem sempre escrever como o cliente fala é o melhor jeito. Todas as formas tem seus problemas.

    Trabalhei 3 anos em uma empresa que um mesmo processo mudou de nome 4 vezes. E cada um chamava de um jeito.

    Eu ainda prefiro tudo em inglês.

    ResponderExcluir
  20. Tiago,

    Assim como comentei no post original eu concordo com você, não faz muito sentido se comunicar em português com o cliente em que todos os termos, jargões, documentos e discussões estão/são em português, e no final das contas programar em inglês apenas por capricho.

    Existem casos e restrições em projetos em que o idioma é um deles (desenvolver uma API open-source, projeto de fora sob-demanda, exigência do cliente etc), mas daí são exceções e não regras.

    Enfim, excelente post.
    Abraços.

    ResponderExcluir