A análise estática deve ser integrada à revisão de código? [fechadas]

As ferramentas que você lista não têm nada a ver com revisões de código. Elas estão lá exatamente para permitir que os revisores se concentrem em assuntos mais úteis.

As revisões de código são para coisas importantes que não podem ser automatizadas : usando um padrão de design quando outro combina melhor, documentando em excesso o código claro ou sub-documentando um pouco claro, sem usar recursos de idioma código mais curto e mais legível. Todas essas coisas são “espertas demais” para uma máquina: um programa, não importa o quão sofisticado seja, não será capaz de dizer se sua aplicação de padrão de fábrica abstrata é uma boa idéia em um determinado contexto ou não. É por isso que as revisões de código são feitas por pessoas, geralmente desenvolvedores mais experientes.

Os assuntos mencionados durante as revisões de código também costumam ser subjetivos . Um desenvolvedor dirá que esse método específico deve ser dividido em dois. Outro igualmente experiente considerará que o método é bom e faz exatamente uma coisa. Um revisor encontrará uma declaração goto terrível; seu colega pode achar que, neste caso em particular, goto é bom e não pode ser removido sem levar a código menos legível.

As ferramentas de estilo, por outro lado, são o arquétipo da automação de regras puramente objetivas, básicas, até às vezes idiotas . A linha 273 é muito longa. Você esqueceu uma letra maiúscula. E aqui, falta um espaço. E aqui encontrei duas linhas vazias em vez de uma. Boooring.

Não perca tempo para isso durante as revisões de código. Se houver um guia de estilo em seu projeto, use o verificador de estilo (como pep8 ), mas execute-o automaticamente através do gancho de pré-consolidação. Espaço faltando? Não se comprometa com você, senhor. Uma linha vazia contém espaços em branco? Por favor, remova-o se você quiser seu código no controle de versão.

Na verdade:

• Como as regras são objetivas e diretas, não há nada a ser discutido durante uma revisão de código. Há espaço em branco em uma linha vazia. Então, remova-o O que você gostaria de contar sobre isso durante uma revisão de código?

Pior, isso pode levar a discussões que são praticamente construtivas. Para alguns, as revisões de código se tornariam uma oportunidade para discutir os méritos de seu estilo preferido , porque, francamente, todos sabem que dois espaços são melhores que quatro, e agora, a revisão de código está focada em nós mudamos nosso estilo de código e reescrevemos toda a nossa base de código para usar dois espaços ao invés de quatro ”. Evite isso a todo custo.

O restante - o que é muito complicado para uma máquina - é para revisões de código, permitindo que os revisores se concentrem nas coisas que realmente importam.

Verificação automatizada, seja verificação de estilo, compilação, testes, análise estática ou prova formal, deve ser bem automatizada. Onde deveria estar no processo de integração contínua é um assunto diferente. Verificações curtas e rápidas, como verificação de estilo, podem ser colocadas diretamente em um gancho de pré-consolidação para evitar qualquer código não compatível na base de código. Verificações longas, como a análise estática, geralmente serão feitas durante a compilação.

Lembre-se, se você tiver um assunto que:

1. Não tem uma resposta direta, a resposta é baseada em experiências pessoais e palpites,
2. Resulta em não-binário "bem, pode ser A, mas B pode ser aceito aqui, enquanto C parece um pouco problemático, mas será uma excelente solução se isso fosse" respostas de estilo,
3. Não pode ser automatizado mesmo com aplicativos mais sofisticados,
4. Não pode ser facilmente transferido para outro contexto,
5. Tem como foco a qualidade, a legibilidade, a expressividade e a facilidade de manutenção do código,

podem ser um bom lugar para isso. Por outro lado, se o assunto:

1. É puramente objetivo e sem ambigüidade,
2. Resulta em uma resposta binária, geralmente baseada em uma métrica,
3. Pode ser automatizado (algumas vezes exigindo muito trabalho e pesquisa)
4. Aplica-se a todas as situações no mesmo grupo,
5. Tem como foco a qualidade, a legibilidade, a expressividade e a facilidade de manutenção do código,

Ganchos de pré-consolidação ou a compilação são locais muito melhores do que uma revisão de código.

Outras leituras:

• Como configurar algo como um servidor de integração que mede a qualidade do código e rejeita o código se a pontuação estiver abaixo um certo número?

• Linters são incríveis, mas são lentos

Esta resposta é baseada em duas suposições. Primeiro, você está usando uma ferramenta de análise estática que é mais do que um verificador de estilo ( PMD e / ou FindBugs em vez de Checkstyle , por exemplo). Segundo, a ferramenta foi configurada corretamente com relação aos erros detectados e à gravidade do erro para o processo ou produto fornecido.

Sim, as ferramentas de análise estática projetadas para localizar erros devem fazer parte do processo de revisão de código. Mais geralmente, uma ferramenta de análise estática deve ser executada e os resultados revisados como parte de uma revisão de código, antes de confirmar o código em uma ramificação usada por outros desenvolvedores.

Antes da revisão do código, o desenvolvedor deve executar e corrigir os problemas encontrados pela ferramenta de análise estática, com todas as descobertas revisadas e quaisquer descobertas importantes corrigidas. Em seguida, eles devem ser executados novamente no código para produzir erros remanescentes. Esta lista deve fazer parte da revisão de código. Isso permitirá que os revisores de código humanos se concentrem em problemas que não conseguem encontrar ou talvez preste atenção especial às áreas do código sinalizado pela ferramenta (verificando os falsos positivos).

O ideal é que você use a ferramenta desde o início do projeto. Se não, no entanto, e há um grande número de descobertas, elas precisariam ser revisadas e distribuídas, o que não seria feito como parte de uma revisão de código. Neste ponto, eu faria a execução da ferramenta parte do processo de construção ou de integração contínua e cada compilação deveria reduzir o número de erros. Os desenvolvedores devem usar essas informações para ajudar a deixar o código que tocam em um estado melhor do que o encontrado durante a refatoração ou desenvolvimento. É claro que usar a lista durante uma revisão de código também seria útil para identificar possíveis problemas que devem ser corrigidos para garantir que o código seja melhor do que era antes.