O que temos que fazer para desenvolver um bom software são boas práticas técnicas – essa é a parte de engenharia da engenharia de software. Design. Codificação. Testes e Revisões.

Se você pudesse fazer apenas uma coisa para tornar um software melhor, o que seria? Onde é que você obtém o máximo de retorno para seus investimentos?

Integração Contínua – Fazendo o código rodar

A integração contínua é um lugar óbvio para começar. Você precisa construir o software e fazê-lo funcionar antes de poder fazer qualquer coisa útil com ele.

Faça com que os desenvolvedores se monitorem e se sincronizem com mais frequência. Construa o sistema com mais frequência – pelo menos uma vez por dia para começar, e então em cada verificação. O que significa simplificar e automatizar os passos para a construção do sistema. Certifique-se de que o sistema cria com êxito cada vez – sem erros ou avisos. O que significa que as pessoas podem executá-lo e experimentá-lo quando quiserem. Certifique-se de que ele será executado corretamente. O que significa a adição de testes e verificações, como parte das etapas de compilação e implementação. Construa radiadores de informação para que todos saibam o status da construção e quando a compilação é quebrada.

Você não pode ser Ágil sem Integração Contínua, e precisa de integração contínua no lugar antes que possa seguir para o caminho DevOps para Entrega Contínua ou implantação contínua.

E a Integração Contínua trabalha na entrega sequencial em cascata também. Os desenvolvedores nesses ambientes podem verificar mais códigos com menos frequência, mas ainda há um valor real em saber que você pode construir, executar o sistema e vê-lo trabalhar mais cedo do que tarde, especialmente em grandes sistemas empresariais e grandes programas, nos quais receber dependências funcionou e todas as peças que trabalham em conjunto são um desafio enorme.

Desenvolvedores testando o seu próprio trabalho – fazendo trabalho de código

Tornar os desenvolvedores responsáveis por testar o seu próprio trabalho, automatizando isso tanto quanto possível na Integração Contínua, é a única maneira de entregar software mais rápido e manter os custos baixos – depender demais de testes manuais e transferências para a equipe de teste te atrasar muito.

Quase todas as organizações com que conversei ao longo dos últimos anos estão colocando mais responsabilidades de testes nos desenvolvedores, e levando mais testadores para as equipes de desenvolvimento, seguindo o exemplo do Google e agora da Microsoft, para se tornarem “mais Agile”.

Isso significa que estão confiando mais nos desenvolvedores para escrever bons testes automatizados (testes unitários, regressão UI básica usando Selenium ou Watir) e fazer verificação de análise estática na Integração Contínua ou IDE do desenvolvedor para encontrar erros de codificação comuns e vulnerabilidades de segurança.

Mas existem limites para o que os desenvolvedores podem pegar em seus testes, mesmo os bons devs. Depois que você conseguir que os desenvolvedores escrevam testes (antes ou depois de se escrever o código, isso não importa, agora que TDD está morto), você vai acabar com testes de unitários, em sua maioria simples, ou testes de regressão UI que não se afastam muito do “caminho feliz“, provando que o código faz o que o desenvolvedor acha que deve fazer – porque é isso que eles precisam fazer: seu trabalho. Seus pressupostos e pontos cegos serão refletidos nos testes, bem como o código. Pouco ou nenhum teste negativo. Ou testes de usabilidade. Ou testes de segurança. Ou testes de estresse. Ou teste de integração em nível de sistema. Tudo isso ainda tem que ser feito por alguém – a menos que você espere que seus clientes encontrem seus erros para você.

Revisões de código ou emparelhamento – fazendo um bom código

Outra maneira de obter um código melhor é fazer com que os desenvolvedores façam revisões de código.

As revisões de código devem ser sobre, em primeiro lugar, encontrar problemas no código – verificar correções, proteção de codificação defensiva (tratamento de erros, contratos de API, segurança de thread e validação de dados), segurança (uso correto de bibliotecas de segurança para controle de acesso e codificação de saída, proteção de dados confidenciais, registro e auditoria…). E sobre como tornar o código melhor – mais compreensível, mais seguro e mais fácil de mudar.

As revisões de código são dispendiosas, então faça-as direito: à base de risco, leve, usando análise estática primeiro para capturar erros de baixo nível e práticas de codificação ruins para que os revisores possam dedicar o seu tempo à procura de problemas mais importantes.

Em vez de revisões de código, você pode tentar o emparelhamento como uma maneira de obter alguns pares de olhos sobre o código.

O emparelhamento não é a mesma coisa que as revisões – as metas e as prioridades são diferentes. Um bom revisor vai encontrar problemas, mesmo em um código desenvolvido por meio de programação em par, pois os revisores procuram coisas diferentes. Mas uma pesquisa mostra que a programação em pares disciplinada lhe dará uma estruturação melhor e um código mais limpo, com menos bugs. E o emparelhamento é uma maneira muito melhor para ensinar programadores sobre o que são os sistemas de revisões de código.

As desvantagens da programação em par? O custo de ter duas pessoas fazendo o trabalho de uma – uma boa dupla vai trabalhar mais rápido do que uma pessoa por conta própria, mas o membro da equipe menos experiente ou menos qualificado vai desacelerar o desempenho da dupla. O emparelhamento pode ser desgastante, o que significa que as pessoas não podem fazê-lo por muito tempo, antes que o seu trabalho se torne superficial ou tenso. E há os problemas sociais – as pessoas que gostam dele gostam muito, mas as pessoas que não gostam não vão fazê-lo de forma alguma.

Refatorando – escrevendo código – melhorando o design – continuando

E o design? Oficinas colaborativas de design? Revisões de design? Modelagem de ameaças no design para cuidar de riscos de segurança e operacionais?

Fazemos todas essas coisas. Mas à medida que continuamos a iterar no design e que nossa base de código cresce, a refatoração – manter e, às vezes, restaurar o design, e manter o código passível de manutenção – se torna cada vez mais importante.

É fácil aprender as ferramentas de refatoração do seu IDE e as ideias básicas por trás do conceito. Mas não é fácil aprender como fazer a refatoração certa (embora você possa aprender muito em um curto período de tempo com o vídeo de Woody Zuill e Llewellyn Falco – “2 Minutes to Code Better“). Entenda por que algumas abordagens de refatoração são melhores que outras. Como poupar tempo refatorando. Como fazer isso com segurança.

Mariusz Sieraczkiewicz faz um bom trabalho explicando como e quando fazer “refatoração cotidiana” utilizando uma matriz construída sobre o trabalho de Michael Feathers em refatoração brutal e biologia do código:

1. Comece lendo e anotando o código, talvez fazendo alguma refatoração do zero (rápida, descartável) para compreendê-lo melhor.
2. Encontre nomes significativos para variáveis e condicionais.
3. Extraia métodos para quebrar grandes pedaços de código e expressar o algoritmo.
4. Livre-se da duplicação óbvia.
5. Mova os métodos e extraia as classes para isolar as responsabilidades.

Concordo com Sieraczkiewicz que esses simples passos “curariam a maioria das bases de código neste planeta”. Ele, então, continua a descrevendo a “refatoração estratégica” maior e mais fundamental (aka “root canal“): refatoração para padrões, introdução de novas construções arquitetônicas. Trabalho que traz riscos e custos muito mais elevados. Esse é o lugar onde termina a refatoração, e o re-design e a re-arquitetura são iniciados.

O que você faria para tornar o código melhor?

A integração contínua recompensa rapidamente: a mudança na transparência e no foco da equipe é quase imediata.

Os testes do desenvolvedor são uma jornada, não um objetivo. Vai levar muito tempo para a maioria dos desenvolvedores ficar bom nisso e muito tempo para construir um bom conjunto de testes no qual você pode confiar. Quanto mais cedo você começar, melhor.

As revisões de código também podem levar muito tempo para recompensar. Os desenvolvedores – e gerentes – precisam arrumar tempo para que as revisões sejam feitas e construir a disciplina, e os desenvolvedores precisam de tempo para aprender a revisar o código corretamente, e como dar e aceitar críticas. Mas as revisões de código – ou o emparelhamento – vão te dar um código melhor.

A refatoração é mais um investimento de capitalização – você paga um pouco hoje para economizar muito no futuro.

Se existir só uma coisa que você pudesse fazer para tornar o software melhor, o que seria? Por onde você começaria?

***

Jim Bird faz parte do time de colunistas internacionais do iMasters. A tradução do artigo é feita pela redação iMasters, com autorização do autor, e você pode acompanhar o artigo em inglês no link: http://swreflections.blogspot.com.br/2014/12/if-you-could-only-do-one-thing-to-make.html