Code churn

Code churn elevado é um dos sinais mais claros de que algo está errado no seu processo de entrega, mas a maioria dos líderes de engenharia só percebe isso depois que um sprint já desandou. Code churn mede quanto código o seu squad escreve e depois reescreve ou deleta logo em seguida, antes de chegar à produção. Sem monitoramento, ele drena silenciosamente a velocidade, infla os cycle times e corrói a confiança nas estimativas do time. Esta página cobre a definição, como medir, quais benchmarks usar, como reduzir e como o DevStats extrai esses dados do seu Git.

Principais pontos

• Code churn mede a proporção de código recém-escrito que é modificado ou deletado antes de se estabilizar. É um sinal direto de retrabalho no seu pipeline de entrega. Squads com churn persistentemente alto entregam mais devagar, acumulam dívida técnica oculta e desperdiçam capacidade de engenharia em trabalho que nunca chega aos usuários.
• A fórmula padrão é: Code Churn = (linhas adicionadas + linhas deletadas de commits recentes) / total de linhas alteradas, expressa como percentual em uma janela contínua, geralmente de 21 dias. Não existe um benchmark universal único, mas a maioria dos squads saudáveis tem taxas de churn abaixo de 25%. Taxas acima de 40% de forma sustentada merecem investigação.
• O erro mais comum dos times é tratar todo churn como ruim. Algum churn é saudável: design iterativo, refactoring e desenvolvimento orientado a testes geram reescritas esperadas. O problema é o churn sem distinção, causado por requisitos vagos ou mudanças de escopo de última hora, que fica invisível sem medição.
• O DevStats rastreia code churn automaticamente ao se conectar ao seu provedor Git, com benchmarks extraídos de 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 code churn

Code churn é o percentual de código recém-escrito que é reescrito ou deletado dentro de uma janela de tempo definida, geralmente 21 dias. Ele mede quanto do output do seu squad é retrabalho em vez de progresso líquido em direção à entrega de funcionalidades.

Tecnicamente, o cálculo é: Code Churn = (linhas reescritas ou deletadas dentro da janela) / (total de linhas adicionadas) × 100. A fonte de dados é o histórico de commits do seu Git. Nenhuma ferramenta adicional é necessária além do acesso ao seu repositório. Churn alto tem uma consequência direta para o negócio: tempo de engenharia gasto reescrevendo código é tempo que não foi usado em funcionalidades, melhorias de confiabilidade ou pagamento de dívida técnica deliberada. Você pode ver como o churn interage com outros sinais de output na feature de throughput do DevStats.

Por que code churn importa para times de engenharia

Quando squads não rastreiam code churn, o retrabalho fica invisível. Um sprint parece produtivo na superfície porque commits estão fluindo, PRs estão sendo abertos e os players estão ocupados. O quadro real só aparece quando você percebe que os PR cycle times estão se alongando, funcionalidades estão escapando das estimativas e as mesmas áreas do codebase continuam sendo tocadas. Quando o padrão fica visível nos resultados de entrega, semanas de capacidade já foram consumidas.

Para líderes de engenharia, code churn se conecta diretamente à precisão do planejamento e à confiança dos stakeholders. Quando o churn está alto, suas estimativas são construídas sobre areia: o trabalho que o squad achava que estava pronto continua voltando. Isso torna os compromissos de sprint pouco confiáveis e corrói a confiança dos stakeholders de produto e negócio. Rastrear churn dá um sinal mais cedo do que prazos perdidos. Você pode usar a feature de benchmarks do DevStats para comparar a taxa de churn do seu squad com times de tamanho e cadência de release semelhantes, tendo contexto antes de tirar conclusões.

Dentro do SPACE framework, code churn está na interseção de eficiência e atividade: ele diz se a atividade que o seu squad gera está se convertendo em output estável e pronto para ship. Medição é o primeiro passo. O que você faz com esses dados depende do contexto do time, da maturidade do codebase e das decisões que você toma como líder de engenharia.

Como medir code churn

Para calcular code churn, você precisa de acesso ao histórico de commits do seu Git. A maioria dos provedores Git expõe isso por meio de APIs ou analytics nativos. O cálculo extrai linhas adicionadas e linhas modificadas ou deletadas dentro de uma janela contínua, geralmente de 21 dias, e expressa o retrabalho como percentual do output total. Você pode segmentar por squad, por repositório ou por branch de feature individual para isolar onde o churn está concentrado.

Não existe um benchmark DORA publicado especificamente para code churn até o relatório State of DevOps de 2023. A tabela abaixo reflete limites qualitativos usados por plataformas de inteligência de engenharia e profissionais da área. Os benchmarks variam significativamente por tamanho do time, idade do codebase e se o squad está em desenvolvimento ativo de features ou em modo de manutenção.

Esses limites são direcionais, não prescritivos. Um squad fazendo refactoring pesado em código legado vai mostrar churn elevado por razões legítimas. O contexto dos seus dados de sprint e dos sinais de planning accuracy ajuda você a interpretar o que o número de churn realmente significa para o seu time.

Code churn na prática: um exemplo real

Uma VP de Engenharia em uma empresa SaaS de 40 pessoas percebeu que um squad estava consistentemente perdendo as metas de sprint apesar de um alto volume de commits. Quando ela extraiu os dados de churn do histórico Git deles, viu que cerca de 50% do código escrito no módulo principal de pagamentos estava sendo reescrito dentro de duas semanas. Os commits eram reais, a atividade era real, mas metade do output estava voltando para si mesmo. Ela rastreou o padrão até um problema recorrente: os critérios de aceite estavam sendo finalizados no meio do sprint, forçando os players a refazer implementações que já tinham passado pelo code review.

A intervenção dela foi no nível de processo, não de pessoas. Ela introduziu um checklist de definition-of-ready para qualquer história que tocasse no módulo de pagamentos, exigindo aprovação dos critérios de aceite antes do sprint planning. Ela também encurtou o loop de feedback agendando um check-in no meio do sprint com o product owner daquele squad. Nas seis semanas seguintes, o churn naquele módulo caiu para abaixo de 30% e a taxa de conclusão de sprint do squad melhorou de forma mensurável. Ela usou o activity heatmap do DevStats para confirmar que as mesmas áreas problemáticas estavam se estabilizando em vez de continuar ciclando.

Como reduzir code churn

1. Afine os critérios de aceite antes do início do sprint. A maior parte do churn causado por retrabalho tem origem em requisitos que mudam depois que a implementação começa. Exija que qualquer história que entre em um sprint tenha critérios de aceite explícitos e acordados. Acompanhe sua planning accuracy como indicador antecedente: se histórias estão regularmente expandindo no meio do sprint, o processo de definição upstream precisa ser ajustado.
2. Antecipe o code review no ciclo. Review tardio identifica problemas depois de um investimento significativo de implementação, o que força reescritas. Introduzir draft PRs ou design reviews antes da implementação completa reduz o custo das correções de rota. A feature de code review do DevStats mostra onde o review está acontecendo tarde no ciclo para você ver quais squads estão mais expostos.
3. Isole o churn por módulo, não só por squad. Churn raramente é uniforme em todo o codebase. Identifique quais arquivos ou módulos estão churning com mais frequência. Hotspots persistentes geralmente indicam instabilidade arquitetural ou ambiguidade de ownership, ambos exigindo intervenções diferentes de simples correções de processo.
4. Separe o trabalho de refactoring do trabalho de feature no seu rastreamento. Refactoring deliberado gera churn esperado. Se você mistura isso com entrega de features na sua medição, perde o sinal. Marque tickets de refactoring de forma distinta no seu issue tracker para poder excluí-los ao avaliar o churn relacionado à entrega.
5. Revise os padrões de alocação quando o churn dispara. Picos sustentados de churn às vezes se correlacionam com players fazendo context-switching em muitos workstreams simultaneamente. Verifique seus dados de alocação para ver se os membros do squad estão sobrecarregados, o que pode reduzir a profundidade de foco necessária para escrever código estável na primeira vez.

Code churn vs. dívida técnica

Code churn e dívida técnica são relacionados, mas medem coisas diferentes: churn é um sinal em tempo real sobre retrabalho no seu ciclo de entrega atual, enquanto dívida técnica é uma medida acumulada de atalhos e trabalho de qualidade adiado que vai desacelerar entregas futuras.

Use code churn para identificar problemas de processo no ciclo de sprint atual; use métricas de dívida técnica para embasar o caso de investimento arquitetural no próximo trimestre.