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:
- Não tem uma resposta direta, a resposta é baseada em experiências pessoais e palpites,
- 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,
- Não pode ser automatizado mesmo com aplicativos mais sofisticados,
- Não pode ser facilmente transferido para outro contexto,
- 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:
- É puramente objetivo e sem ambigüidade,
- Resulta em uma resposta binária, geralmente baseada em uma métrica,
- Pode ser automatizado (algumas vezes exigindo muito trabalho e pesquisa)
- Aplica-se a todas as situações no mesmo grupo,
- 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: