Qualidade percebida como custo é o erro econômico mais caro da engenharia. Cada ponto de Complexidade Cognitiva extra cobra juros em cada feature futura. O time que não mede qualidade só a sofre. O acúmulo silencioso é invisível no primeiro ano e causa congelamento de evolução no terceiro. A dívida técnica não declarada não desaparece. Ela compõe, e a composição é exponencial.
Subcapability 05 de 05 · Software Engineering & Architecture
Code Quality & Craft
Technical Debt Ratio mensurável e Quality Gates reais que mantêm velocidade de entrega sustentável e impedem que dívida técnica silenciosa vire congelamento de evolução.
O que está em jogo
O time entrega feature na velocidade certa nos primeiros meses. Depois o ritmo cai. Feature nova que levava uma semana passa a levar duas. Depois três. A investigação revela o mesmo padrão: dívida técnica acumulada em silêncio, sem métrica, sem plano. O código que funcionava como motor virou âncora, e ninguém consegue apontar quando a virada aconteceu.
O que é, na prática
Como atuamos
Quality Gates com critério econômico
Configuramos Quality Gates no pipeline com limites defensáveis: Complexidade Cognitiva máxima por função, Technical Debt Ratio máximo por módulo e zero issues de severidade crítica antes de qualquer merge. O gate falha quando o limiar é ultrapassado, não apenas sinaliza.
Refactoring contínuo integrado ao fluxo
Estabelecemos a prática de refactoring contínuo como parte do desenvolvimento normal, não como projeto separado. Cada mudança de código deixa a base ligeiramente melhor do que encontrou. A regra do escoteiro como prática de engenharia: o camping fica mais limpo do que estava.
Code review como transferência de conhecimento
Estruturamos o processo de code review com foco em compartilhar raciocínio e construir padrão compartilhado, não apenas detectar defeito. Reviewer explica por que uma abordagem é preferível. Autor aprende o padrão. O conhecimento para de ser individual.
Medição de dívida técnica com SQALE
Calculamos o Technical Debt Ratio usando a metodologia SQALE para tornar o passivo legível em horas de remediação estimada e percentual do investimento total. A conversa de board sobre dívida técnica passa a ter número defensável.
Indicadores antecedentes de qualidade
Monitoramos Complexidade Cognitiva por função e Technical Debt Ratio como indicadores antecedentes que sinalizam onde a velocidade vai cair antes de ela cair. Intervenção antes do congelamento custa uma fração da intervenção emergencial depois.
Ganhos mensuráveis
O que muda no resultado quando essa subcapacidade amadurece.
Velocidade de entrega sustentada ao longo do tempo
Quality Gates e refactoring contínuo impedem o acúmulo silencioso que faz a décima feature levar três vezes mais do que a primeira. A velocidade do time no trimestre quatro é comparável à do trimestre um.
Change Failure Rate (taxa de mudanças que causam incidente)
Código com Complexidade Cognitiva controlada e cobertura de teste adequada tem menor taxa de defeito em produção. Cada ponto percentual de redução no Change Failure Rate é mensurável em tempo de engenharia liberado de remediação emergencial.
Tempo médio de entendimento de módulo por engenheiro novo
Complexidade Cognitiva baixa e padrões consistentes reduzem o tempo que o engenheiro novo gasta interpretando o código antes de poder contribuir. Onboarding mais rápido é capacidade produtiva adiantada.
Technical Debt Ratio visível e com plano de amortização
SQALE aplicado transforma a dívida técnica de sensação difusa em número defensável. O plano de amortização trimestral torna o passivo gerenciável e a conversa de priorização com o negócio possível com critério econômico.
Perguntas frequentes
Dívida técnica é o mesmo que código ruim?
Dívida técnica é o custo futuro de decisões que foram corretas no contexto original e tornaram-se inadequadas com a evolução do sistema. Inclui código que funcionava quando foi escrito mas que hoje não reflete o modelo de negócio atual, testes que não cobrem os caminhos que passaram a ser críticos e arquiteturas que não escalam para o volume que o sistema atingiu. Código ruim é subconjunto. Dívida técnica é mais ampla.
Como calcular o Technical Debt Ratio?
O Technical Debt Ratio do SQALE é a razão entre o tempo estimado de remediação de todos os issues de qualidade e o tempo estimado de desenvolvimento total do sistema. Ferramentas como SonarQube calculam automaticamente com base nos issues detectados e nos tempos de remediação parametrizados por tipo de issue. Um Technical Debt Ratio acima de 5% é considerado elevado e começa a impactar velocidade mensurável de entrega.
O que é Complexidade Cognitiva e por que é melhor do que Complexidade Ciclomática?
Complexidade Ciclomática conta caminhos de execução no código. Complexidade Cognitiva, métrica introduzida pelo SonarSource, mede o esforço mental para entender o código. Uma função com múltiplos levels de aninhamento e estruturas de controle encadeadas pode ter Complexidade Ciclomática moderada e Complexidade Cognitiva alta. O que importa para velocidade de desenvolvimento é o esforço de entendimento, não o número de caminhos.
Code review gera gargalo quando o time cresce?
Code review gera gargalo quando é visto como gate de qualidade que toda mudança precisa cruzar antes de avançar. Code review como transferência de conhecimento tem escala diferente: nem toda mudança precisa do mesmo nível de revisão, padrões estabelecidos reduzem o tempo de revisão de código que os segue e pair programming resolve casos complexos antes que o código seja escrito. O processo calibrado por risco e complexidade não escala linealmente com o time.
Como iniciar um programa de redução de dívida técnica sem parar o desenvolvimento?
Com a abordagem de refactoring oportunístico: cada mudança de código deixa o módulo tocado em estado melhor do que estava. Nenhum projeto de limpeza separado, nenhum sprint dedicado. A melhoria acontece como subproduto do desenvolvimento normal. Para dívida concentrada em módulos específicos com impacto alto em velocidade de entrega, sprints de consolidação periódicos, um por trimestre, tratam os pontos de maior custo sem parar o fluxo de entrega.
Outras subcapabilities desta capability
Arquitetura Evolutiva
ADRs e fitness functions que registram decisões caras de reverter e validam conformidade automaticamente, mantendo o custo de cada mudança dentro de limites que o negócio consegue absorver.
Domain-Driven Design
Linguagem ubíqua e bounded contexts do Domain-Driven Design que alinham modelo de software ao modelo de negócio e eliminam a camada de tradução onde retrabalho e custo se acumulam.
Clean Architecture & Patterns
Clean Architecture com Dependency Rule que isola regras de negócio de frameworks, banco e UI, reduzindo custo de troca de tecnologia de projeto de seis meses para sprint.
Testing Strategy
Estratégia de testes calibrada por risco, custo e velocidade que substitui pirâmide invertida por distribuição que dá confiança real para mudar e elimina a cerimônia do medo.
Quer clareza sobre onde investir primeiro?
Diagnóstico completo de capacidades de tecnologia com roadmap de evolução conectado ao resultado financeiro.