PR size

Pull requests grandes são um dos preditores mais confiáveis de ciclos lentos de code review. PR size mede o volume de mudanças de código em um único pull request, geralmente expresso como linhas adicionadas mais linhas deletadas. Quando os PRs do seu squad chegam rotineiramente a centenas ou milhares de linhas, a qualidade do review cai, o tempo de merge aumenta e bugs passam despercebidos. Esta página cobre a definição de PR size, como medi-lo, o que é considerado bom e como reduzi-lo.

• PR size mede o total de linhas de código adicionadas e deletadas em um único pull request. Ele importa porque PRs grandes demais tornam o code review mais lento, aumentam a carga cognitiva dos revisores e elevam a chance de defeitos chegarem à produção sem serem detectados.
• PR size é calculado como linhas adicionadas mais linhas deletadas em um pull request. Não existe um benchmark universal publicado para todos os times, mas a maioria das pesquisas de engenharia e o consenso de profissionais aponta PRs com menos de 200 linhas alteradas como um alvo saudável para a maioria dos squads que trabalham em codebases de produção.
• O erro mais comum dos times é confundir PR size com produtividade do desenvolvedor. Um player que submete dez PRs pequenos em uma semana não é menos produtivo do que um que submete um PR grande. PRs menores são uma disciplina de processo, não uma penalidade de produtividade. Tratar tamanho como proxy de esforço lê o sinal de forma completamente errada.
• O DevStats rastreia PR size automaticamente conectando ao seu provedor Git, com benchmarks comparando mais de 1.000 times de engenharia para você ver onde seu squad está. Comece um teste gratuito e veja seus números em menos de dois minutos.

Definição de PR size

PR size é o número total de linhas de código alteradas em um único pull request, contando adições e deleções. É uma métrica de processo que reflete como o trabalho é dividido antes de entrar no code review.

Tecnicamente: PR size = linhas adicionadas + linhas deletadas por pull request. Alguns times também rastreiam contagem de arquivos ou de commits como sinais complementares, mas linhas alteradas é a medida mais usada. Quando o PR size cresce sem controle, ele infla diretamente o PR cycle time, o tempo do PR aberto até o merge, porque os revisores gastam mais tempo por PR e frequentemente adiam reviews grandes para encontrar um bloco maior de foco.

Times que gerenciam bem o PR size entregam lotes menores de mudança com mais frequência, o que reduz o risco de deployment e sustenta ciclos de feedback mais rápidos no pipeline de entrega.

Por que PR size importa para times de engenharia

Quando os squads não rastreiam PR size, PRs grandes se acumulam de forma invisível na fila de review. Os revisores ficam diante de uma escolha: fazer uma passagem superficial ou bloquear horas da agenda. Os dois resultados são ruins. Reviews superficiais deixam defeitos passarem, e longas esperas de review criam custos de troca de contexto que corroem a produtividade do time.

PR size se conecta diretamente aos KPIs que líderes de engenharia acompanham. Ciclos de review lentos atrasam os compromissos do sprint. Defeitos vindos de PRs grandes sem review adequado aumentam as taxas de incidente e consomem capacidade de engenharia para trabalho novo. Deployment frequency, uma das DORA metrics centrais, fica mais difícil de sustentar quando as mudanças individuais são grandes e arriscadas de entregar. Times que mantêm PR size pequeno tendem a fazer deploy com mais frequência e mais confiança.

Dentro do SPACE framework, PR size toca a dimensão de Eficiência e Fluxo. PRs grandes interrompem o fluxo tanto do autor esperando o review quanto do revisor preso em uma sessão longa. Medir PR size dá o sinal diagnóstico. O que você faz com ele é decisão sua como líder de engenharia.

Como medir PR size

PR size é obtido diretamente do seu provedor Git. GitHub, GitLab e Bitbucket expõem linhas adicionadas e deletadas por pull request via APIs. Você não precisa de um issue tracker ou dados de pipeline CI/CD para calculá-lo, mas combinar PR size com PR cycle time dá uma visão muito mais rica de onde seu processo de review está saudável ou sobrecarregado.

Nenhum benchmark publicado pelo DORA cobre PR size diretamente. A tabela abaixo reflete o consenso de profissionais e padrões observados em times de engenharia. Os benchmarks variam conforme a maturidade do codebase, o tamanho do time e se o trabalho envolve mudanças de infraestrutura, refatorações ou features novas. Use esses valores como sinais direcionais, não como limites absolutos. Você pode comparar a distribuição do seu squad com times semelhantes usando os benchmarks do DevStats.

PR size na prática: um exemplo real

Uma VP de Engenharia em uma empresa SaaS de 45 pessoas percebeu que o PR cycle time médio do squad havia subido para quatro dias ao longo de um trimestre. Ela analisou a distribuição de PR size e descobriu que 30% dos PRs mergeados ultrapassavam 500 linhas. Esses PRs grandes respondiam por mais de 60% do tempo total de review registrado pelos seus players seniores. O gargalo não era a disponibilidade dos revisores. Era o tamanho do que estava sendo submetido.

Ela introduziu uma norma no squad: qualquer PR acima de 300 linhas exigia que o autor o dividisse em uma sequência de PRs menores antes de solicitar review. Ela acompanhou o PR size médio e o cycle time semanalmente durante as seis semanas seguintes. O PR size médio caiu de 380 linhas para 160 linhas. O cycle time caiu de quatro dias para menos de 36 horas. Ela também percebeu que o volume de comentários de code review por PR aumentou, um sinal de que os revisores estavam se engajando mais profundamente com mudanças menores e focadas.

Como melhorar PR size

1. Defina uma norma do time com um limite específico de linhas. Escolha um número, por exemplo 200 linhas, e torne isso uma expectativa visível durante o planejamento do sprint. Normas funcionam melhor do que regras quando o squad entende o raciocínio por trás delas. Explique que PRs menores são revisados mais rápido, não que PRs grandes são penalizados.

2. Adote PR stacking para features grandes. Quando uma feature realmente exige muito código, ensine os players a dividi-la em uma sequência de PRs menores que se constroem uns sobre os outros. O primeiro PR pode estabelecer o modelo de dados; o segundo adiciona a camada de API; o terceiro adiciona a UI. Cada um é revisável de forma independente.

3. Separe refatoração do trabalho de feature. PRs com propósito misto, refatoração mais feature nova, são difíceis de revisar e inflam o tamanho artificialmente. Uma regra permanente de manter refatorações em seus próprios PRs reduz o tamanho e deixa a intenção mais clara para os revisores.

4. Acompanhe o PR cycle time como sinal antecipado. Se o cycle time começa a subir, verifique primeiro o PR size. As duas métricas se movem juntas. O DevStats mostra as duas na mesma visão para você correlacioná-las sem precisar construir um relatório manual. Você pode acompanhar isso diretamente na feature de PR cycle time.

5. Revise a distribuição de tamanho por squad nas retrospectivas do sprint. Os dados agregados mostram a média. A distribuição mostra se um ou dois players são responsáveis pela maioria dos PRs grandes, o que é uma conversa de coaching, não uma questão de performance.

PR size vs. PR count

PR size e PR count são relacionados, mas medem coisas diferentes. Um squad pode ter PR count alto e PR size alto ao mesmo tempo, o que significa que está entregando com frequência, mas em lotes grandes e arriscados. Rastrear os dois juntos dá uma visão completa de como o trabalho flui pelo seu pipeline de entrega.

Use PR size quando quiser entender a qualidade do review e o risco por mudança. Use throughput e PR count quando quiser entender o volume de entrega ao longo do tempo.