Ferramentas de engenharia: produtividade e colaboração para a empresa

Muitos gestores sêniores por vezes não medem a importância que as ferramentas de engenharia têm para facilitar a colaboração entre desenvolvedores e entre times, e consideram os processos do dia a dia – as linguagens usadas, os ambientes de testes, o sistema de validação – questões menores, que não precisam nem de investimento nem de planejamento devido à enorme oferta de ferramentas no mercado e aos processos internos que cada equipe cria para  executar seus próprios projetos. 

Acreditar que esses processos cotidianos têm menos relevância é um equívoco. A padronização das ferramentas gera o potencial de um enorme ganho de produtividade para a organização como um todo. O compartilhamento de repositórios, a cultura de testes e de revisão de código e a integração de diretrizes nas ferramentas facilitam o fluxo de trabalho e permitem que os engenheiros consigam produzir e organizar as plataformas que serão o diferencial para proporcionar eficiência e inovação.

O que é o ferramental de engenharia

O ferramental de engenharia é o que os engenheiros de software usam no trabalho. Um desenvolvedor passa a vida escrevendo, compilando e testando códigos. Quando está satisfeito com os testes, submete tanto o código que escreveu quanto os testes para revisão (code review), idealmente feita por engenheiros tecnicamente experientes.

Quem revisa pode e deve fazer comentários e pedir alterações, e, quando tudo está certo e aprovado, o código entra em uma esteira chamada CI/CD (continuous integration e continuous delivery, integração e entrega contínuas), um mecanismo de validações automáticas daquele código, por exemplo verificando aspectos de segurança, ou checando se a formatação está toda correta. 

Depois de passar por esse ambiente de validação, o código entra em produção, ou seja, entra para o repositório – antes estava só na máquina do desenvolvedor – e é integrado a ele. É um processo que afeta diretamente a produtividade dos desenvolvedores e pode perder velocidade dependendo do tanto de burocracia envolvida. O objetivo é que a maioria dos processos internos seja automatizada, e um dos pontos que gera mais impacto nisso é o repositório, – se é:

• Um único para a empresa inteira 
• Um único por time 
• Um único por grupo ou subgrupo 

Quando esses repositórios estão espalhados pela companhia, em grande número e de forma desordenada, surge um grande problema: não há uma maneira fácil de visualizá-los. 

Repositório compartilhado e informação à mão

Ferramentas são construídas para facilitar a vida dos desenvolvedores, para que eles tenham tudo o que precisem para escrever, testar e botar códigos novos em produção. Elas simplificam ações e reduzem a  necessidade de processos entre pessoas, de tal forma que ninguém perca muito tempo pensando de que maneira começar isso ou aquilo.

Nos primeiros tempos do Google, por exemplo, o ferramental de engenharia era tão padronizado que só havia uma maneira única de colocar o código em produção, e essa abordagem ditava a estratégia de colaboração. Um dos elementos principais desse sistema era a existência de um repositório comum que reunia todo o código da empresa e, mais que isso, era indexado. Toda vez que alguém escrevia um código, ele passava a ser buscável por palavras-chave. As linguagens também eram padronizadas e em número pequeno.

A comunalidade no modo como o código é escrito, com padrões de código e bibliotecas comuns, torna fácil para um desenvolvedor ler o que já foi escrito por outras pessoas. Correções ou modificações do código podem ser experimentadas e submetidas pelo próprio sistema, sem que seja necessário saber quem é o “dono” do código. Esse tipo de comunicação, em empresas organizadas como o Google foi, pode ser feito por intermédio da própria ferramenta de revisão de código. 

Para que esse tipo de processo funcione, é preciso que o código esteja indexado e seja buscável no repositório. Há empresas que têm centenas de repositórios, e é impossível pesquisar um a um. A capacidade de localizar um código dentro da organização evita que o trabalho seja duplicado ou triplicado, e impede que se perca tempo testando, atualizando e mantendo códigos redundantes.

A comunalidade no modo como o código é escrito, com padrões de código e bibliotecas comuns, torna fácil para um desenvolvedor ler o que já foi escrito por outras pessoas.

São múltiplas as razões para que exista uma superabundância de repositórios, e a maior delas é o crescimento não-intencional. Uma nova área da empresa é desenvolvida, sob a liderança de alguém recém-contratado, que cria um sistema novo e independente sem levar em conta possíveis e futuras intercambialidades com outras áreas já existentes.  

Outro motivo, ligado a esse, é a necessidade de rapidez: quanto menor o repositório, mais rápido as ferramentas funcionam. Se o processo vai ficando lento, há o impulso de o programador criar um repositório novo, apartado, sem integrá-lo ao restante. A existência de vários repositórios é até aceitável, desde que exista uma ferramenta de busca que funcione como se só existisse um.

Bem dosadas e integradas, ferramentas de engenharia proporcionam liberdade e capacidade de colaboração, permitindo inclusive que o trabalho seja assíncrono e remoto.

Ferramentas terceirizadas: como escolher

As ferramentas de engenharia atuais não têm que ser 100 por cento criadas na empresa. O pensamento intencional de tecnologia significa, no entanto, que elas sejam escolhidas com bons critérios e usadas  com constância. Existem inúmeras opções para:

• Linguagens de programação
• Ambiente de desenvolvimento
• Ambiente de testes
• Sistema de revisão de código
• Sistemas para colocar código em produção 
• Fazer as validações automáticas 

Esse cardápio costuma ser oferecido em forma de pacotes pré-montados. A liderança de tecnologia tem de decidir de forma muito consciente como usar esses serviços, que precisam ser escolhidos racionalmente e padronizados entre as várias áreas da empresa. 

Há companhias que seguiram o estilo do Google na uniformização das ferramentas e no uso de um repositório único para a empresa toda, chegando ao extremo – que tem seus prós e contras – de usar apenas uma linguagem de programação.