Como determinar a eficácia de um processo de revisão de código?

Introduzimos um processo de revisão de código em nossa organização e parece estar funcionando bem. No entanto, eu gostaria de poder medir a eficácia do processo ao longo do tempo, ou seja, não estamos encontrando bugs porque o código é limpo ou as pessoas simplesmente não estão percebendo bugs?

Atualmente, não temos um processo de teste totalmente automatizado eficaz. Empregamos principalmente testes manuais, portanto não podemos confiar nos defeitos encontrados neste estágio para garantir que o processo de revisão de código esteja funcionando.

Alguém já se deparou com esse problema antes ou pensa sobre o que funciona bem na medição de revisões de código?

Há várias métricas que podem ser coletadas a partir de análises de código, algumas até estendendo-se ao longo do ciclo de vida do projeto.

A primeira métrica que eu recomendaria reunir é a eficácia da remoção de defeitos (DRE) . Para cada defeito, você identifica em que fase o defeito foi introduzido e em que fase foi removido. As várias técnicas de detecção de defeitos usadas são todas avaliadas simultaneamente, de modo que se aplica igualmente a análises de requisitos, análises de projeto, análises de código, testes de unidade , e assim por diante. Você estaria particularmente interessado no número de defeitos detectados na fase do código, pois isso provavelmente abrangeria seus testes de unidade e análises de código. Se muitos defeitos da fase de código estiverem chegando à fase de teste de integração ou mesmo ao campo, você saberá que as práticas de pós-codificação devem ser avaliadas.

Várias métricas de reunião também seriam relevantes. Isso inclui o tempo de preparação, o tempo de reunião, as linhas de leitura de código, os defeitos encontrados na revisão e assim por diante. Algumas observações podem ser feitas a partir desses dados. Como exemplo, seria se seus revisores estivessem gastando muito tempo lendo o código em preparação para a revisão, mas encontrando muito poucos problemas. Juntamente com os dados do DRE, você pode concluir que se os defeitos estiverem sendo testados nos testes de integração ou no campo, sua equipe precisará se concentrar nas técnicas de revisão para encontrar problemas. Outra observação interessante seria as linhas de código (ou alguma outra medida de tamanho) lidas em uma reunião em comparação com o horário da reunião. A pesquisa descobriu que a velocidade de uma revisão de código típica é de 150 linhas de código por hora.

Com qualquer uma dessas métricas, é importante entender seu impacto no processo. A análise de causa raiz, usando técnicas como o porquê, porque , os diagramas de Cinco Porquês ou Ishikawa podem ser usados ​​para identificar os motivos pelos quais as revisões de código (ou qualquer outra técnica de melhoria de qualidade) são (in) efetivas.

Você também pode estar interessado neste artigo sobre inspeções do The Ganssle Group e em um artigo de Capers Jones no Crosstalk sobre Potenciais de Defeitos e DRE .

Embora em grande parte seja verdade que a revisão de código identificaria problemas bastante latentes que os testes podem ou não detectar. No entanto, na minha opinião, você pode ter um código realmente estável (praticamente livre de bugs), mas ainda assim escrito de tal maneira que é extremamente ilegível ou pouco sustentável. Portanto, pode ser que a revisão do código NÃO encontre erros se realmente não houver problemas reais no código.

Dito isto, eu realmente perguntaria, por que alguém iria querer fazer uma revisão de código? A simples razão pela qual é importante é que o código deve ser aprimorado para se tornar mais legível, sustentável e evolutível. Muitas pessoas devem ser capazes de ler códigos mais limpos e fazer sentido com isso. Nesse sentido, o objetivo mais simples do processo de revisão de código é produzir código limpo. Portanto, a medida de eficácia é o quão mais limpo o código é agora.

Como você queria ter uma eficácia mensurável - eis o que eu sugeriria:

1. Métrica relacionada à quantidade de retrabalho - O número de vezes que o retrabalho é aplicado em um mesmo módulo / objeto / item de trabalho é uma medida de quão pobre é esse código em termos de manutenção. Quando uma revisão de código eficaz é aplicada, com que frequência podemos reduzir a solicitação de retrabalho no mesmo módulo?

2. Métrica relacionada à quantidade de mudança em que cada solicitação de mudança incorre. Quando toda vez que uma solicitação de mudança ocorre - um código mal fatorado sempre terá um número maior de módulos afetados. Uma medida provavelmente indica que após uma revisão de código - houve alguma redução dessa propagação de mudança para uma solicitação de mudança semelhante no passado?

3. Métrica relacionada à velocidade média com a qual uma solicitação de mudança pode ser respondida. Quando o código é mais limpo - mais rápido e melhor, é para responder às alterações necessárias. Depois que o código foi limpo no processo de revisão, encontramos uma velocidade maior na resposta à solicitação de tamanho semelhante.

Não estou colocando unidades exatas de medidas - você provavelmente pode criar medidas mais precisas sobre isso a partir dessa abordagem. Pode haver mais formalismo de extensão nas abordagens acima sobre isso.

Basicamente, meu argumento é que, em vez de analisar o número de bugs que o processo de revisão de código identifica; devemos medir a eficácia em termos de se a revisão de código foi capaz de trazer o código para um estado mais limpo, mais enxuto e fácil de manter; portanto, podemos avaliar essa eficácia se percebermos que solicitações de mudança semelhantes no futuro se tornam mais eficientes para serem respondidas.