Linguagens de programação: com quantas trabalhar em uma empresa de tecnologia?

Desenvolvedores passam mais tempo lendo código do que escrevendo, e por essa razão a organização do código afeta a produtividade de qualquer empresa, seja pública ou privada. Um número menor de linguagens e a padronização de formatos contribuem para que o profissional entenda rapidamente:

• O que está lendo 
• Se precisa ou não fazer mudanças
• Se há problemas

Em vez de impor diretrizes determinando como o código deve ser escrito, o ideal é que as ferramentas adotadas pela empresa assegurem automaticamente essa padronização.

Um conceito básico em programação é que tudo o que se faz com uma linguagem pode ser feito com outra. Não existe uma linguagem que permita criar mais possibilidades, exatamente do mesmo modo como na linguagem humana: tudo o que se pode produzir em português, seja prosa, poesia ou post de mídia social, também pode ser feito em francês ou em grego. No computador é igual, porque Python não faz algo que Java não faça.

Ainda que o resultado seja o mesmo, entretanto, há vantagens em padronizar e limitar o número de linguagens de programação usadas em uma organização.

Não existe uma linguagem que permita criar mais possibilidades, exatamente do mesmo modo como na linguagem humana: tudo o que se pode produzir em português, seja prosa, poesia ou post de mídia social, também pode ser feito em francês ou em grego.

Menos linguagens = mais comunalidade

É frequente encontrar nas empresas, além da multiplicidade de repositórios e serviços terceirizados, uma torre de Babel de linguagens de programação, às vezes com mais de 20 delas em uso, como consequência de um crescimento desordenado de tecnologia e da falta de direcionamento nesse aspecto, que costuma ser negligenciado. O instinto dos desenvolvedores é elaborar processos personalizados, que se adaptem a suas preferências. 

A situação fica ainda pior quando a companhia tem departamentos que não se comunicam adequadamente e vivem em silos, com cada um tocando projetos à sua moda, sem ter ideia de como o pessoal da engenharia de outro departamento está se defrontando com processos e problemas semelhantes. Não há ninguém ditando como as ferramentas devem ser usadas nem quais linguagens são preferenciais.

O melhor dos mundos é quando a empresa começa do jeito certo, porque isso evita muitos débitos técnicos futuros e dá a ela uma vantagem perpétua. Uma vez que isso não ocorra, quanto mais cedo se faz uma intervenção para focar nas ferramentas e aumentar a padronização, melhor, porque com o crescimento da empresa e a proliferação de linguagens e serviços de terceiros, mais tarde qualquer tentativa de mudança parece impositiva e limitante para os programadores. A tendência é que cada desenvolvedor queira continuar trabalhando na linguagem e nas ferramentas de que mais gosta e tente preservar o código que já escreveu. 

Usar ferramentas e softwares comuns leva as equipes a terem interdependência e a trabalharem juntas, o que é positivo para a empresa como um todo. Às vezes é preciso forçar um pouco a colaboração, porque as funcionalidades que precisam ser produzidas para o negócio são sempre mais complexas do que aquilo que cada colaborador poderia executar sozinho.

Uma das formas de incentivar trocas é usar o código como colaboração. Um código claro, com linguagens e padrões em comum, aumenta a capacidade de entendimento entre os times.

Existem discussões homéricas sobre onde se coloca o parêntese no código, se o conteúdo do parêntese vai na mesma linha, o que se coloca na próxima linha, se cada linha deve ter no máximo 80 caracteres porque esse é o tamanho adequado para imprimir, ou se isso tudo é irrelevante.

Quando uma empresa conta com uma única ferramenta integrada para todo mundo, a formatação pode ser feita automaticamente, não importa como a pessoa tenha digitado, e os olhos dos desenvolvedores ficam muito mais treinados para ler com eficiência, inclusive em momentos críticos, como quando ocorre um incidente. Ninguém precisa despender energia fiscalizando se o código está formatado corretamente ou reforçando culturalmente essas diretrizes, porque elas são simplesmente automáticas.

Com menos linguagens de programação, cria-se maior mobilidade para os engenheiros dentro da organização, porque fica mais fácil mudar de um time para o outro. Se cada time resolve escrever código de uma maneira diferente e alguém trocar de equipe, a pessoa nova tem de perder tempo aprendendo as ferramentas e padrões novos e vai demorar mais para se tornar produtiva ali. Se houver um projeto atrasado, as pessoas-chaves de outros times podem socorrer e atuar para solucionar o problema. Sem as ferramentas padronizadas, toda essa colaboração fica prejudicada, porque quem for ajudar precisa aprender os padrões do zero.

O ganho em agilidade é ainda mais decisivo em situações-limite, como quando ocorre um incidente e se forma uma força-tarefa emergencial para algum projeto prioritário. Nesses casos, cada minuto que passa sem uma solução pode representar enormes prejuízos, e a possibilidade de o problema ser localizado e resolvido mais rapidamente é muito maior se os contribuidores individuais mais sêniores da empresa são acionados e conhecem bem o código para opinar.