# 13 indicadores para avaliar qualidade de um código > 13 indicadores para avaliar qualidade de um código incluem manutenibilidade, cobertura de testes, complexidade ciclomática, acoplamento, coesão, duplicação, legibilidade, documentação, desempenho, segurança, testabilidade, modularidade e aderência a padrões. Esses critérios permitem que equipes identifiquem pontos de refatoração e reduzam dívida técnica de forma objetiva. *PosUp · Apps e Software · 20 de julho de 2026 · Patrícia Lemos* Avaliar a qualidade de um código vai além de ele funcionar. Conheça 13 indicadores práticos, de manutenibilidade a cobertura de testes, que ajudam equipes a decidir onde refatorar e como evitar dívida técnica. ## Qualidade de código: 13 indicadores que separam o funcional do sustentável Avaliar a qualidade de um código não se resume a verificar se ele compila e executa. Um software que funciona hoje pode se tornar um pesadelo de manutenção amanhã. Os 13 indicadores a seguir ajudam a equipe a decidir onde investir esforço de refatoração e como evitar dívida técnica. Cada um responde a uma pergunta de negócio diferente, nenhum deles deve ser lido isoladamente. ### 1. Manutenibilidade Mede o esforço necessário para modificar o código. Ferramentas como o Índice de Manutenibilidade da Microsoft combinam complexidade ciclomática, linhas de código e comentários. Um índice abaixo de 20 (em escala 0-100) indica que qualquer alteração exigirá retrabalho alto. Decisão: priorizar refatoração antes de adicionar novas funcionalidades. ### 2. Complexidade ciclomática Conta o número de caminhos independentes em uma função. Valores acima de 10 por método sugerem que os testes de unidade serão insuficientes e a probabilidade de bugs cresce. Decisão: quebrar a função em partes menores, cada uma com responsabilidade única. ### 3. Cobertura de testes Percentual de linhas ou branches executados pela suíte de testes. Acima de 80% é desejável, mas cobertura alta em código mal estruturado gera falsa segurança. Decisão: olhar para a cobertura por módulo, não para a média geral. ### 4. Duplicação de código Trechos idênticos ou quase idênticos espalhados pela base. Mais de 5% de duplicação em projetos maduros eleva o custo de manutenção, corrigir um lugar exige corrigir todos. Decisão: extrair o código repetido em funções ou classes reutilizáveis. ### 5. Acoplamento Grau de dependência entre módulos ou classes. Acoplamento alto (uma classe que depende de muitas outras) torna alterações em cascata e quebra testes. Decisão: aplicar inversão de dependência e reduzir o número de imports diretos. ### 6. Coesão Mede o quanto os elementos de um módulo estão relacionados. Baixa coesão indica que a classe ou função faz coisas demais. Decisão: separar responsabilidades seguindo o Princípio da Responsabilidade Única (SRP). ### 7. Tempo de execução Quanto tempo o código leva para executar uma tarefa específica. Importante em sistemas com restrições de SLA. Decisão: se o tempo ultrapassa o limite aceitável, investigar gargalos de I/O, consultas ou algoritmos ineficientes. ### 8. Taxa de defeitos Número de bugs encontrados por unidade de tempo ou por linha de código. Uma taxa crescente sugere que a base está se deteriorando. Decisão: revisar processos de code review e aumentar cobertura de testes nas áreas mais críticas. ### 9. Dívida técnica Estimativa do esforço necessário para corrigir problemas estruturais. Ferramentas como SonarQube convertem violações em dias de trabalho. Decisão: alocar uma porcentagem fixa do sprint (ex.: 20%) para redução da dívida. ### 10. Legibilidade Subjetiva, mas mensurável por convenções de nomenclatura, comentários e estrutura consistente. Código que exige mais de 5 minutos para ser compreendido por outro desenvolvedor falha neste indicador. Decisão: adotar um guia de estilo e realizar peer reviews focados em clareza. ### 11. Aderência a padrões Conformidade com convenções da linguagem e da equipe (ex.: PEP 8 para Python, PSR para PHP). Baixa aderência aumenta o custo de onboarding. Decisão: configurar linters e formatadores automáticos no pipeline de CI. ### 12. Rastreabilidade de requisitos Capacidade de ligar cada trecho de código a um requisito de negócio. Sem rastreabilidade, mudanças viram apostas. Decisão: manter comentários ou tags que referenciem o identificador do requisito. ### 13. Frequência de refatoração Quantas vezes por mês a equipe altera código existente sem adicionar funcionalidade nova. Frequência baixa pode indicar que a dívida técnica está sendo ignorada. Decisão: estabelecer janelas regulares de refatoração, mesmo que curtas. ## Qual escolher conforme o caso? Não existe um único indicador que defina qualidade. Para uma startup em fase inicial, priorize legibilidade e cobertura de testes. Para um sistema legado crítico, complexidade ciclomática e dívida técnica são mais urgentes. O ideal é selecionar 3 a 5 indicadores que respondam às perguntas de negócio da sua equipe e monitorá-los a cada sprint. ## FAQ ### O que é o Índice de Manutenibilidade? É uma métrica composta que combina complexidade ciclomática, linhas de código, volume de Halstead e percentual de comentários. Valores entre 0 e 100 indicam o quão fácil é modificar o código. ### Complexidade ciclomática alta é sempre ruim? Nem sempre. Funções com muitos casos de teste ou validações complexas podem ter valores altos por necessidade. O problema é quando a complexidade não é justificada pelo domínio do problema. ### Como medir duplicação de código? Ferramentas como SonarQube, PMD ou ESLint detectam blocos idênticos ou semelhantes. A métrica é o percentual de linhas duplicadas em relação ao total. ### O que fazer quando a cobertura de testes é alta mas o código ainda quebra? Revisar a qualidade dos testes: testes que não cobrem branches, que não testam bordas ou que são frágeis demais dão falsa segurança. Use cobertura de branches em vez de apenas linhas. ### Dívida técnica e bugs são a mesma coisa? Não. Dívida técnica é o custo futuro de decisões estruturais subótimas. Bugs são erros de comportamento. Uma base com dívida alta tende a gerar mais bugs, mas são conceitos diferentes. ### Qual a frequência ideal para medir esses indicadores? Para projetos ativos, recomenda-se medir a cada sprint ou a cada release. Indicadores como cobertura de testes e duplicação podem ser monitorados continuamente no pipeline de CI. --- Fonte (canonical): https://posup.com.br/apps-e-software/13-indicadores-para-avaliar-qualidade-de-um-codigo/