Seja Poliglota, saia do arroz com feijão!

Ser um programador poliglota implica em saber várias linguagens de programação, não apenas para resolver problemas distintos, mas para resolver os mesmos problemas também. Saber pensar em uma solução em diferentes linguagens aumenta a capacidade de criação e de solução de um desenvolvedor, por isso é tão importante saber diversas linguagens.

É muito comum em um projeto usarmos mais de um linguagem de programação. Isso se torna evidente em projetos WEB, nos quais utilizamos HTML, Javascript e CSS para o frontend com Java, Ruby, Python, etc para o backend, mas também é verdade em outros sistemas. Repare que em todos os sistemas empresariais, se não em todos os sistemas, são utilizados bancos de dados, os quais possuem uma DSL própria, como o SQL por exemplo.

Na STI temos duas linguagens de desenvolvimento para o backend: Java e Ruby. Inicialmente eu trabalhava em projetos Java e posteriormente comecei a dar um suporte para projetos em ambas as linguagens. Na maioria das vezes minha ajuda era em modelagem, levantamento de requisitos, gerência de  configuração de forma geral, mas muitas vezes entravamos em discussões de implementação muito divertidas. Nesse tempo, fui aprendendo sobre o ecossistema Rails e vendo um monte de coisas bacanas que não tínhamos em Java, como migrations.

Saber como fazer as coisas de outra forma ou das capacidades de outra linguagem de programação me deixavam curioso sobre como fazer essas coisas em Java e como ter essas facilidades. Mais do que isso, me fazia questionar se minha forma de fazer algumas coisas era a mais adequada ou se eu podia fazer ainda melhor! Eu questionava não apenas como fazer em Java as coisas que eu via em Ruby, mas também o contrário. Isso também aconteceu quando aprendi LISP e PROLOG e oturas linguagens.

Vou relatar uma das coisas que aprendi assim. Uma das coisas em Rails que mais me ajudou em Java foi a parte de testes com Rspec e Cucumber. Quando conheci o Cucumber achei surpreendente a forma de escrever testes mais legíveis, ainda mais, testes que poderiam ser usados como documentação do projeto. Isso me ajudou a pensar em como escrever meu código, em geral, de forma mais legível e organizada, sempre visando a manutenção (qualidade). Eu já fazia testes em Java usando JUnit, mas apenas isso não era mais suficiente, eu precisava de uma forma melhor de fazer isso! Busquei outras ferramentas para teste e fui estudar melhor como fazer testes melhores, para ir além do feijão com arroz que eu comia  programava meus testes naquela época. 

Assim, eu fui estudar mais sobre testes e conheci os conceitos de Test Doubles, tipos de testes, o que automatizar e o que não automatizar, etc. Nessa época, encontrei o Mockito, uma ótima ferramenta em Java para trabalhar com Test Doubles. Achei muito limpa sua forma de "mockar" esses objetos todos e facilitar imensamente a fazer Testes Unitários. Posso dizer que só depois do Mockito eu aprendi a fazer Testes Unitários de verdade. 

Acho interessante ver que tem tanta gente que trabalha com testes automatizados sem nem saber sobre Test Doubles ou tipos de teste corretamente. é Comum ouvir que se esta "mockando" tudo. Mas muitas vezes não sabe a diferença entre os tipos de Test Dubles, ou seja, chamam tudo de mock, pois no framework o método usado para criar stubs e mocks é o mesmo mock(...). Algumas vezes um stub seria a melhor opção e o programador está usando um mock, ou ainda, ele está fazendo um spy e chamando de mock. Conhecer sobre a teoria por trás de uma ferramenta é a melhor forma de usá-la na hora certa e, apenas, sabendo usar na hora certa é que se usa corretamente uma ferramenta. Sabe aquela história de que pra quem tem martelo tudo é prego? Então... mas esse papo é pra outro post.

Concluindo, vamos aprender a programar em outras linguagens, não apenas úteis para o seu dia a dia, mas úteis para sua capacidade de solução! Alguém ai já fez algum programa em PROLOG ou LISP? Se sim, vocês sabem a dor de cabeça que é deixar de entender o mundo de forma estruturada e pensar de maneira funcional, lógica. Que desafio desgastante, mas prazeroso ao fazer o programa funcionar! =)

Vou deixar uma dica de leitura: Sevem languages in seven weeks. Eu não li ainda, mas está na minha lista!