Análise estática substitui a revisão de código?

A resposta curta é NÃO. Bom, isso não esclarece muita coisa, não é? Então vamos para a resposta média: devemos sempre buscar o desenvolvimento elegante de software. Por elegante queremos significar execução que cumpre os requisitos usando economicamente seus recursos e tendendo atrasos a zero. Precisão, economia e pontualidade podem ser razões difíceis de defender na frente de seus stakeholders, mas se a pressão aumentar demais, puxe um ás da manga: o custo da não qualidade.

No excelente livro "The Art of Sofware Testing" (MYERS, 1979) seu autor nos apresenta a 'Regra de 10', afirmando que quanto mais cedo se descobre e corrige um erro, menor é o se custo para o projeto. De acordo com Myers, o custo das correções cresce DEZ vezes a cada etapa do processo de desenvolvimento de software. Se um aumento exponencial dos custos não for o suficiente para convencer qualquer stakeholder sobre a importância de se aplicar revisão em pares (feita por humanos) somada à análise estática do código (feita por máquinas) desde os estágios iniciais de desenvolvimento, você está com um problema.

Mas fique tranquilo. Acompanhe este texto até final para que possamos ajudá-lo a construir uma argumentação sólida e factual em defesa da qualidade de software. Vamos à resposta longa.

Revendo os prós e contras da análise estática

Ferramentas de análise estática podem:

• Detectar uso incorreto da linguagem e inconsistências do código (geralmente quando o programador entende alguma coisa errado);
• Checar o uso de boas práticas ou padrões, complexidade desnecessária, falhas de estruturação; ou se o código é um bom candidato à refatoração;
• Encontrar estouros de buffer e corrupção de memória (em C/C++), operações ilegais ou inseguras, ponteiros nulos, loops infinitos, código redundante ou inútil.

Porém, estas ferramentas não são capazes de:

• Detectar quando o programador entendeu errado os requisitos;
• Saber quando o programador esquece ou deixa de fora algo importante;
• Encontrar erros de lógica da aplicação, como ordenação crescente onde deveria haver ordenação decrescente, ou inversão de sinais, como trocar divisão por multiplicação, ou referenciar o objeto 'comprador' ao invés do 'vendedor' dentro do código.

Ferramentas comerciais mais avançadas são capazes de encontrar falhas avançadas no vulnerabilidades de software usando análise do fluxo de controle (verificar perigos potenciais dentro de uma sequência de chamadas), fluxo de dados (análise interprocedural para detectar vulnerabilidades quando dados são passados de um método a outro), pontos vulneráveis à injeção de dados maliciosos e outros itens que são muito difíceis e demorados de se verificar manualmente.

Mas nenhuma ferramenta poderá dizer — pelo menos com a tecnologia atual — se você se esqueceu de criptografar uma parte sensível dos dados, ou se você deveria estar armazenando estes dados, nem se as permissões de acesso implementadas são adequadas ou não.

Mantenha em mente que diferentes ferramentas de análise estática terão diferentes abordagens sobre o código analisado, portanto elas podem capturar (ou saltar) diferentes questões. Uma ferramenta pode gerar um relatório sem notificações e outra pode levantar dúzias de questões. Escolher e ajustar as ferramentas adequadamente é uma tarefa à parte.

Combinando revisões automatizadas e revisões manuais

A análise estática pode encontrar erros de programação e de digitação, mas não erros de raciocínio. Uma ferramenta de análise dinâmica pode ser capaz ir um pouco além e capturar uma série de outras questões, porém consumindo consideravelmente mais recursos na simulação de execução do código.

Mas abordagens automatizadas sofrem da falta de contexto. Elas não tem como saber qual objetivo o software deve atingir. A revisão de código é feita por outro programador. Se você se lembrou da programação em pares — peer programming —, parabéns!, é bem por aí: uma pessoa programa, a outra revisa. E pode ir além, com revisões em grupo, stand-up meetings, depende da sua metodologia.

Nessa abordagem, o revisor está envolvido com o processo e conhece os objetivos que o software deve atingir — em contraste com as análises estática/dinâmica, feitas por computadores. Sendo assim, ele pode checar:

• Se o código (uso da linguagem de programação) está correto E executando a ação esperada;
• Se a semântica do software está correta;
• Se a lógica do artefato está conforme os requisitos;
• Se há violações de padrões ou falhas de projeto.

Uma situação interessante ocorre quando se inclui uma revisão ANTES dos testes automatizados. Normalmente um número menor de discrepâncias entra no processo de testes — e, é claro, menos problemas que só a interação humana pode capturar — reduzindo o empenho de tempo e recursos no processo como um todo.

O envolvimento humano vai custar um pouco mais de tempo do que a validação automatizada, mas vai valer muitas vezes o seu investimento ao longo do processo de desenvolvimento de software.

O raciocínio correto é SOMAR, e não TROCAR

Ferramentas automatizadas de análise estática são ótimas para fazer o trabalho pesado e massivo que pode beirar o inviável conforme o volume. Isso é especialmente verdade em linguagens de nível mais baixo (C/C++) e linguagens de script como Javascript e PHP; e também para times que estão começando a adotar uma nova linguagem ou framework.

Mas elas não são capazes de substituir olhos e cérebros. A revisão de código é indispensável se você quer garantir um nível alto de qualidade no desenvolvimento de software.

Ainda tem dúvidas? Deixe um comentário!

Veja também:

Revisão do código ou teste de invasão?

Construindo analisadores de códigos.