Code review metrics

Code reviews são onde a velocidade de engenharia vai morrer. Estudos mostram consistentemente que pull requests ficam esperando por review por mais tempo do que passam em qualquer outra etapa do pipeline de entrega, mas a maioria dos squads não tem nenhuma forma sistemática de enxergar isso. Code review metrics são as medições que tornam seu processo de review visível: quanto tempo os reviews levam, com que frequência bloqueiam a entrega e como a carga de review está distribuída pelo time. Esta página cobre a definição, como medir e fazer benchmark dessas métricas, um exemplo real e como usar os dados para tornar seu processo de review mais rápido sem abrir mão da qualidade.

Key takeaways

• Code review metrics são medições quantitativas do processo de review de pull requests, incluindo time-to-first-review, review turnaround time, tamanho do PR e taxa de participação nos reviews. Elas importam porque processos de review lentos ou desequilibrados são uma das causas ocultas mais comuns de sprint commitments perdidos e players frustrados.
• A fórmula mais comum é o review turnaround time, calculado como o tempo desde a abertura do PR até o primeiro comentário de review ou aprovação. Nenhum benchmark de mercado publicado cobre todas as code review metrics, mas squads de alta performance geralmente atingem um time-to-first-review mediano abaixo de quatro horas em horário de trabalho, com PRs abaixo de 200 linhas de código por review.
• O erro mais comum dos times é tratar volume de reviews ou contagem de comentários como sinal de qualidade. Um PR com zero comentários não é necessariamente código bem escrito; pode simplesmente não ter sido lido. Medir a taxa de participação junto com o turnaround time dá uma visão mais completa de se os reviews estão realmente acontecendo.
• O DevStats rastreia code review metrics automaticamente conectando ao seu provedor Git, mostrando review turnaround time, distribuição de tamanho de PR e padrões de participação nos seus squads, com benchmark comparado a mais de 1.000 times de engenharia. Comece um trial gratuito e veja seus números em menos de dois minutos.

Definição de code review metrics

Code review metrics são um conjunto de medições que descrevem como os pull requests se movem pela etapa de peer review do seu processo de entrega. Elas capturam a velocidade dos reviews, o tamanho dos PRs e a consistência com que os revisores participam. Um processo de review lento é um dos contribuidores mais diretos para um PR cycle time estendido, que por sua vez atrasa releases e acumula trabalho em progresso no squad.

As métricas principais incluem time-to-first-review (tempo desde a abertura do PR até a primeira ação do revisor), review turnaround time (tempo desde a abertura do PR até a aprovação ou merge), tamanho do PR (linhas de código alteradas) e taxa de participação no review (percentual de revisores elegíveis que contribuem). Não existe uma fórmula única que cubra todas as code review metrics, mas o ponto de partida mais acionável é: Review turnaround time = timestamp da aprovação ou merge menos timestamp da criação do PR. Quando os tempos de review são longos e os PRs são grandes, o efeito downstream aparece como deployments atrasados, menor throughput e conflitos de merge que se acumulam e travam o squad inteiro.

Por que code review metrics importam para times de engenharia

Quando squads não acompanham code review metrics, os gargalos de review ficam invisíveis. Um time pode estar entregando itens de trabalho de tamanho consistente e ainda assim perder sprint commitments porque PRs ficam na fila por 48 horas antes de alguém olhar para eles. Essa fila não aparece no seu gráfico de velocidade nem na sua daily. Ela aparece como um padrão de corridas de última hora e releases atrasados que ninguém consegue explicar com os dados que tem.

Para líderes de engenharia, reviews lentos afetam diretamente a entrega no prazo e a satisfação dos desenvolvedores. Players que submetem trabalho e esperam dias por feedback perdem contexto, perdem momentum e, eventualmente, perdem a paciência. Carga de review concentrada em um ou dois players sênior cria um gargalo que nenhuma contratação resolve. Acompanhar os padrões de colaboração no processo de review mostra se a responsabilidade pelo review é genuinamente compartilhada ou silenciosamente centralizada. O SPACE framework identifica colaboração e fluxo como duas das suas cinco dimensões, e code review metrics estão exatamente na interseção das duas.

A medição é o ponto de partida. Quando um líder de engenharia consegue ver onde os reviews estão travando e por quê, ele pode tomar decisões direcionadas sobre atribuição de revisores, normas de tamanho de PR e SLAs de review. Os dados mostram o padrão; o líder de engenharia decide o que fazer com isso.

Como medir code review metrics

Todas as code review metrics principais vêm dos dados do seu provedor Git. GitHub, GitLab e Bitbucket expõem os timestamps necessários para calcular time-to-first-review, review turnaround time e tamanho de PR. Você não precisa de uma integração CI/CD para começar, mas combinar dados do Git com seu issue tracker permite conectar atrasos de review a resultados de sprint via issue cycle time.

Não existe um benchmark único e autoritativo para todas as code review metrics da forma como os DORA benchmarks existem para frequência de deployment. A tabela abaixo reflete padrões observados em organizações de engenharia de alta performance e é consistente com os dados publicados no relatório DORA State of DevOps 2023 para métricas de fluxo relacionadas. Os benchmarks variam por tamanho de time, maturidade da base de código e modelo de release. Use-os como sinais direcionais, não como metas rígidas. O DevStats oferece benchmarks específicos por time baseados nos seus próprios dados históricos e comparações com pares.

Para tamanho de PR, um sinal amplamente citado em pesquisas da SmartBear e outros é que PRs com mais de 400 linhas de código recebem reviews significativamente menos detalhados. Squads que mantêm PRs abaixo de 200 linhas tendem a ver turnaround mais rápido e menos defeitos pós-merge. Acompanhe o tamanho do PR junto com o turnaround time para entender se PRs grandes estão causando seus atrasos de review. Você pode ver esses padrões na funcionalidade de code review do DevStats, que detalha o tempo de review por squad, revisor e faixa de tamanho de PR.

Code review metrics na prática: um exemplo real

Uma VP de Engenharia em uma empresa SaaS de 40 pessoas percebeu que seu squad estava entregando features consistentemente dois a três dias depois do planejado. A velocidade do sprint parecia boa no papel, mas as datas de release continuavam escorregando. Ela puxou os dados de review e descobriu que o time-to-first-review mediano era de 31 horas, e 60% de todos os PRs estavam sendo revisados pelos mesmos dois players sênior. O squad não era lento para escrever código. Era lento para revisá-lo, e a carga de review estava silenciosamente concentrada.

Ela introduziu duas mudanças: uma norma de squad de que PRs devem receber um primeiro review em até quatro horas de trabalho, e um sistema de rotação que distribuiu as atribuições de review de forma mais equilibrada. Ela também definiu um limite suave de 250 linhas para tamanho de PR e pediu aos players que quebrassem mudanças maiores em PRs empilhados. Nos dois sprints seguintes, ela acompanhou o review turnaround time e a velocidade de entrega lado a lado. O time-to-first-review mediano caiu para menos de cinco horas, e os dois players sênior relataram passar menos tempo em review e mais tempo em trabalho de alta prioridade. Os dados mostraram onde olhar; ela decidiu o que mudar.

Como melhorar suas code review metrics

1. Defina um SLA de review explícito e deixe-o visível. Combine uma meta de time-to-first-review como norma do squad, como quatro horas de trabalho. Publique na documentação do time e referencie nas retrospectivas de sprint. Sem uma expectativa compartilhada, o timing de review vira "quando alguém tiver tempo".
2. Limite o tamanho do PR a 200 ou 250 linhas de código alterado. PRs grandes demoram mais para revisar e recebem feedback menos detalhado. Peça aos players que quebrem features em partes menores e revisáveis de forma independente. Essa mudança de processo compensa tanto na velocidade de review quanto nas taxas de defeitos pós-merge. Acompanhe o tamanho do PR nos seus dados de code review para ver se a norma está sendo seguida.
3. Distribua as atribuições de review de forma intencional. Se dois ou três players estão absorvendo a maior parte da carga de review, rotação ou ferramentas de atribuição vão reduzir o gargalo. Use seu activity heatmap para ver onde a atividade de review está concentrada e identificar players com capacidade para assumir mais.
4. Combine code review metrics com PR cycle time. O review turnaround time é um indicador antecedente para o PR cycle time geral. Se o cycle time está subindo, verifique o atraso de review primeiro antes de assumir que o desenvolvimento é o gargalo. Essa sequência evita que líderes de engenharia resolvam o problema errado.
5. Revise os dados nas retrospectivas de sprint. O DevStats mostra padrões de code review no nível do squad. Trazer os dados para a retro dá ao time uma visão compartilhada de onde o processo está funcionando e onde não está, sem expor indivíduos.

Code review metrics vs. PR cycle time

Code review metrics e PR cycle time são relacionados, mas medem escopos diferentes do processo de pull request. O PR cycle time cobre todo o ciclo de vida de um pull request, do aberto ao merge, enquanto as code review metrics focam especificamente na etapa de review dentro dessa janela.

Use code review metrics quando quiser entender o que está acontecendo dentro da etapa de review. Use o PR cycle time quando quiser ver como a etapa de review se compara a outras etapas, como tempo de codificação ou tempo aguardando CI.