# 13 metricas de qualidade de codigo para medir

> As 13 métricas de qualidade de código abrangem complexidade ciclomática, acoplamento, coesão, duplicação, cobertura de testes, dívida técnica, taxa de defeitos, tempo de ciclo, lead time, frequência de deploy, mudanças por commit, falhas por release e manutenibilidade. Essas métricas permitem avaliar saúde do software além da contagem de linhas. A aplicação deve ser seletiva, priorizando indicadores alinhados aos objetivos do time e ao contexto do projeto.

*Pingobox · Apps e Software · 02 de setembro de 2026 · Gustavo Sequeira*

Medir qualidade de código vai além de contar linhas. Conheça as 13 métricas essenciais, da complexidade ciclomática ao tempo de ciclo, e aplique as que fazem sentido para seu time.

Qualidade de código não se mede por opinião. Métricas objetivas ajudam a identificar pontos de melhoria, priorizar refatorações e prever riscos antes que eles virem incidente. Abaixo, as 13 métricas de qualidade de código que todo time deveria conhecer, ordenadas por relevância prática.

**Complexidade ciclomática** é a métrica mais citada quando o assunto é qualidade de código. Ela mede o número de caminhos independentes em uma função, ou seja, quantos fluxos diferentes o código pode seguir. Quanto maior o número, mais difícil é testar e manter. Um valor acima de 10 por função já é sinal de alerta. A ferramenta mais comum para calcular é a do SonarQube, que integra essa métrica ao pipeline de CI.

**Acoplamento** avalia o quanto módulos ou classes dependem uns dos outros. Alto acoplamento significa que uma mudança em um módulo pode quebrar vários outros. Em geral, busca-se baixo acoplamento, pois isso facilita testes isolados e manutenção. Um exemplo concreto: se ao alterar uma classe você precisa modificar 10 outras, o acoplamento está alto.

**Coesão** mede o quanto os elementos de um módulo pertencem logicamente uns aos outros. Alta coesão indica que cada classe ou função tem responsabilidade bem definida. Baixa coesão, por outro lado, aponta para classes que fazem coisas demais, difíceis de entender e reutilizar. O princípio da responsabilidade única é diretamente relacionado a essa métrica.

**Linhas de código (LOC)** é a métrica mais simples e, por isso, a mais mal usada. Número absoluto de linhas não diz nada sobre qualidade, mas a tendência ao longo do tempo importa. Se uma função cresce continuamente, é sinal de que está acumulando responsabilidades. Use LOC como indicador de crescimento, não como meta.

**Cobertura de testes** indica a porcentagem do código que é executada durante os testes automatizados. Cobertura alta não garante ausência de bugs, mas cobertura baixa é um risco claro. Um valor abaixo de 60% costuma ser considerado insuficiente em projetos críticos. Ferramentas como JaCoCo e Istanbul geram relatórios que integram ao CI.

**Índice de manutenibilidade** combina várias métricas, como complexidade ciclomática, volume de código e profundidade de herança, em um único número de 0 a 100. Quanto maior, mais fácil é manter. Valores abaixo de 20 indicam código crítico que precisa de refatoração. O SonarQube calcula esse índice automaticamente.

**Dívida técnica** é uma estimativa do esforço necessário para corrigir problemas de qualidade no código. Ela é expressa em tempo ou dias de trabalho. Se a dívida cresce mais rápido que a capacidade do time de pagá-la, o projeto entra em espiral negativa. Ferramentas como SonarQube e CodeClimate oferecem essa métrica com base em regras de análise estática.

**Duplicação de código** mede a porcentagem do código que aparece repetida em mais de um lugar. Duplicação aumenta o custo de manutenção, pois um bug corrigido em um lugar pode permanecer em outro. Ferramentas de análise estática identificam blocos duplicados e os reportam em relatórios. Um valor ideal é próximo de zero, mas na prática, até 5% é tolerável em projetos legados.

**Taxa de defeitos** calcula o número de bugs encontrados em produção por unidade de tempo (semana, mês) ou por tamanho do código. Essa métrica é reativa, mas essencial para validar se as outras métricas estão funcionando. Se a complexidade aumenta e a taxa de defeitos não cai, algo está errado no processo de revisão ou nos testes.

**Tempo de ciclo** mede o tempo que uma mudança leva desde o início do desenvolvimento até o deploy em produção. Tempo de ciclo curto indica um pipeline eficiente e feedback rápido. Um tempo longo sugere gargalos em revisão, testes ou integração. Ferramentas de CI/CD, como GitHub Actions ou GitLab CI, registram esses tempos automaticamente.

**Lead time** é o tempo total entre a solicitação de uma funcionalidade e sua entrega ao usuário. Diferente do tempo de ciclo, inclui espera e priorização. Lead time longo não é necessariamente ruim em projetos complexos, mas se cresce sem explicação, indica problemas de planejamento ou escopo.

**Taxa de revisão** mede a proporção de mudanças que passam por revisão de código antes do merge. Revisão por pares é uma das práticas mais eficazes para reduzir defeitos, mas a taxa varia de time para time. Um valor abaixo de 70% pode indicar que o time está pulando etapas para acelerar, o que tende a cobrar caro depois.

**Churn** mede a porcentagem de código que é alterado ou removido logo após ser escrito. Churn alto indica que o time está reescrevendo código recém-criado, o que pode ser sintoma de requisitos mal definidos ou falta de testes. Em geral, churn acima de 20% em uma semana é sinal de alerta.

Nenhuma métrica é suficiente sozinha. A combinação certa depende do estágio do projeto e do objetivo do time. Para um projeto maduro, priorize complexidade ciclomática, cobertura de testes e dívida técnica. Para um time em formação, comece com cobertura e taxa de revisão. O importante é monitorar tendências, não números absolutos.

## FAQ

### Qual é a métrica de qualidade de código mais importante?

Não existe uma única métrica mais importante. A complexidade ciclomática é a mais citada, pois afeta diretamente a testabilidade e a manutenção. Mas a cobertura de testes é igualmente crítica para garantir que mudanças não quebrem funcionalidades. O ideal é combinar várias métricas conforme o contexto do projeto.

### Como medir a qualidade do código?

Use ferramentas de análise estática como SonarQube, ESLint ou CodeClimate. Elas calculam métricas como complexidade ciclomática, duplicação e índice de manutenibilidade automaticamente. Para cobertura de testes, use JaCoCo ou Istanbul. Integre essas ferramentas ao pipeline de CI para monitorar continuamente.

### O que é complexidade ciclomática?

É uma métrica que conta o número de caminhos independentes em uma função. Cada if, else, while ou case adiciona um caminho. Quanto mais caminhos, mais difícil é testar e mais provável é ter bugs. Valores acima de 10 por função indicam que a função pode ser simplificada.

### Qual é um bom valor para cobertura de testes?

Não há um número universal, mas 60% é o mínimo recomendado para projetos críticos. Acima de 80% é considerado bom, mas cobertura muito alta pode dar falsa sensação de segurança. O mais importante é cobrir os fluxos críticos de negócio, não apenas linhas de código.

### Como reduzir a dívida técnica?

Priorize refatorações de módulos com alta complexidade e baixa cobertura de testes. Defina um orçamento de dívida técnica por sprint, dedicando um percentual do tempo para pagar a dívida. Monitore a tendência do índice de manutenibilidade ao longo do tempo para verificar avanço.

### Qual ferramenta usar para medir qualidade de código?

SonarQube é a mais completa, com suporte a mais de 30 linguagens e métricas como complexidade, duplicação e dívida técnica. Para projetos JavaScript, ESLint é essencial. CodeClimate é uma opção SaaS que integra com GitHub. Escolha a que se adapta ao seu stack e orçamento.

---

Fonte (canonical): https://www.pingobox.com.br/apps-e-software/13-metricas-de-qualidade-de-codigo-para-medir/