Você corrigiu uma cópia da lógica. Existem outras duas que você não sabia que existiam. Os testes da função "oficial" passam. O caminho que o usuário X executou foi corrigido. O caminho de Y e Z, não. Bem-vindo ao perigo silencioso da duplicação.
Você corrige o bug. Em produção, ele continua aparecendo. Os logs mostram que a correção subiu. Os testes passam. Mas o cliente relata o mesmo problema na semana seguinte. Code Duplication é a métrica que explica por quê.
Code Duplication é a replicação do mesmo comportamento em múltiplos pontos do sistema. Diferentemente das outras métricas, o problema é espalhado — não fica concentrado em um único arquivo. O perigo maior é a falsa sensação de segurança: você corrige uma cópia, e o bug continua nas outras. Com IA generativa, o problema acelerou.
Você recebe o ticket de produção: o cliente está vendo o desconto errado. Investiga. Encontra a função calculateDiscount. Identifica o bug — uma comparação trocada. Corrige. Escreve o teste. Sobe pra staging, valida. Sobe pra produção.
Uma semana depois, o ticket volta. Mesmo cliente. Mesmo sintoma.
Você reabre. Vai no log. O método calculateDiscount que você corrigiu está sendo chamado, sim — mas existe outro lugar no sistema que não chama essa função. Em vez disso, tem uma cópia da lógica embutida diretamente no controller. Outro autor, três anos atrás, copiou e colou. Esse caminho do código nunca foi corrigido.
Esse é o cenário típico de Code Duplication. E o detalhe perverso: você não tem como saber, na hora da correção, que existem outras cópias. Os testes da função que você corrigiu passaram. O comportamento daquele caminho está correto. O problema é que outro caminho usa lógica paralela, independentemente de quantos testes você adicionar à função "oficial".
A definição operacional é direta: mesmo comportamento lógico em mais de um lugar, sem reuso. Não precisa ser cópia literal — análise estática moderna detecta:
A análise via Clone Detection roda em milhões de linhas em segundos. Ferramentas referenciais: PMD/CPD (Copy-Paste Detector), jscpd (multi-linguagem), Simian (Java/C#/Python), e a categoria de Clone Detection em ferramentas modernas de análise estática — incluindo a plataforma SQA da Codurance, que integra Code Duplication com as outras quatro métricas da série em um diagnóstico unificado.
As métricas anteriores da série — Ciclomática, Cognitiva, Smells, Bugs — medem problemas agrupados. A complexidade fica em uma função densa; o smell fica em uma classe específica; o bug lógico fica em uma linha. Você consegue apontar o lugar.
Duplicação é o oposto: o problema está espalhado. Não tem epicentro. A mesma lógica vive em N lugares, e cada um deles parece, isoladamente, normal. Você só vê o problema quando olha para o sistema como um todo.
Isso muda completamente a estratégia de remediação. Quanto à complexidade, você refatora a função problemática. Para duplicação, você precisa identificar o conjunto, escolher a "cópia autoritativa" (ou criar uma nova função que substitua todas as existentes) e migrar cada uso. É refatoração coordenada.
A duplicação é como ter um braço a mais — você não precisa, mas tem que cuidar dele todo dia. Não gera valor, consome manutenção e ainda pode infeccionar (virar bug). A meta é manter a métrica próxima de zero.
A periculosidade da duplicação não está no espaço em disco que ela ocupa. Está na falsa sensação de segurança.
Cenário concreto: três cópias da mesma lógica, em três lugares diferentes. Bug é descoberto na cópia A. O dev corrige a cópia A. Roda os testes que conhece. Tudo verde. Sobe pra produção.
Em produção, o caminho do usuário X passa por A. Comportamento corrigido — bug resolvido. Os caminhos dos usuários Y e Z passam por B e C. Comportamento ainda errado — bug continua, intermitente, "reaparecendo".
O dev olha o log e fica confuso. A correção foi aplicada, validada e está em produção. Como o bug ainda existe? A resposta é que a correção foi parcial — e ele não tinha como saber. Os outros dois pontos de execução não estão mapeados em lugar algum.
O terceiro é o mais grave em sistemas com regras de negócio: a empresa promete uma coisa; o software entrega outra dependendo do caminho. Confiança quebrada.
“Antes do Copilot, duplicação era escolha consciente. Com IA generativa, virou silenciosa — cada prompt potencialmente vira uma nova cópia.
Antes do Copilot/Cursor/Claude, a duplicação era feita por meio de copy-paste consciente. O dev sabia que estava replicando. Era uma escolha (geralmente ruim, mas uma escolha).
Com IA generativa via "prompt após prompt", a duplicação virou silenciosa. O fluxo típico:
Se a base de código tem modularização clara e tipagem forte, o LLM consegue (às vezes) identificar que uma função similar já existe e reutilizá-la. Mas se a base é bagunçada — nomes inconsistentes, ausência de tipos, sem indicação clara de onde a regra de negócio vive — o LLM gera nova implementação.
O resultado: duplicação acelerada. Cada prompt pode virar uma nova cópia. E, como a IA é rápida, o time produz mais código e mais cópias por dia.
A boa notícia: a solução é a mesma de sempre. Modularização e tipagem rigorosa. A diferença é que agora o ROI é maior — código bem estruturado faz a IA trabalhar com você; código bagunçado faz a IA acelerar a degradação.
A engenharia clássica formaliza isso com DRY (Don't Repeat Yourself): cada pedaço de conhecimento tem uma representação única e autoritativa no sistema. Toda mudança na regra de negócio ocorre em um único lugar.
O oposto é o WET (Write Everything Twice) — cada uso reimplementa a lógica.
DRY tem uma nuance: aplicar de forma fanática (todo trecho de duas linhas vira uma função) gera abstração precoce, que é outro tipo de complexidade. A regra prática que funciona: três cópias = refatorar. Dois pode ser coincidência; três é padrão.
git log --since para identificar).Você leu cinco posts sobre métricas individuais. Cada uma com seu mecanismo, seu sintoma, sua remediação. O último post da série fecha a virada: por que olhar todas juntas importa mais do que olhar uma por vez — e como o método SQA estrutura essa visão integrada para diagnóstico cirúrgico.
Qualidade de código - Método SQA→A Codurance acompanha times de engenharia que querem instrumentar a saúde do código sem virar gestores. Ajudamos Tech Leads e Staff Engineers a integrar Clone Detection em pipelines, definir estratégias de refatoração coordenada para conjuntos de cópias e estabelecer arquiteturas que mantêm a base limpa mesmo sob aceleração de IA generativa.
Se você quer aplicar essas práticas no seu time, entre em contato hoje.