O que é débito técnico e como saber quando ele está saindo caro

Débito técnico não é sinônimo de código ruim. Às vezes é a decisão mais inteligente que o time pode tomar. Ward Cunningham, que criou a expressão em 1992, usou a metáfora da dívida justamente porque dívida, bem usada, acelera: você entrega antes, aprende com o usuário e paga depois. O problema começa quando ninguém anota o empréstimo e os juros se acumulam sem ninguém perceber.

Em termos práticos, débito técnico é o custo extra de trabalho futuro causado por uma solução mais rápida escolhida hoje, em vez de uma solução melhor que levaria mais tempo. Os “juros” são o tempo adicional que cada nova mudança passa a exigir por causa daquele atalho.

• O principal é o esforço para corrigir o atalho.
• Os juros são a lentidão e os bugs que ele causa enquanto não é corrigido.
• Está saindo caro quando os juros que você paga a cada sprint passam a ser maiores que o custo de quitar.

De onde vem a dívida: os quatro tipos de Fowler

Martin Fowler propôs um quadrante do débito técnico que ajuda a separar o débito saudável do problemático. Ele cruza dois eixos: se a dívida foi deliberada ou acidental, e se foi prudente ou imprudente.

O quadrante prudente e deliberado é o que Cunningham tinha em mente: uma escolha consciente, registrada, com plano de pagamento. O prudente e acidental é inevitável, porque você só entende o problema de verdade depois de resolvê-lo uma vez. Os dois imprudentes são os que mais custam.

Antes de medir: os sinais que o time já sente

Muita dívida aparece primeiro no humor da equipe, antes de aparecer em qualquer ferramenta. Use esta lista como checagem rápida:

• uma mudança simples, como trocar o texto de um botão, exige mexer em cinco arquivos;
• existe um módulo que todos evitam tocar (“não mexe no faturamento”);
• só uma pessoa entende determinada parte, e as férias dela viram risco;
• cada correção de bug cria outro bug em lugar inesperado;
• o tempo para um dev novo fazer o primeiro deploy passa de semanas;
• as dependências estão várias versões principais atrás e ninguém se arrisca a atualizar.

Se três ou mais itens soam familiares, os juros já estão altos.

Um teste simples para confirmar: peça a duas pessoas do time que estimem, separadamente, uma tarefa pequena num módulo limpo e outra do mesmo tamanho no módulo que todos evitam. Se a segunda estimativa vier duas ou três vezes maior, a diferença é exatamente o juro que aquele trecho cobra. E é um número que você consegue mostrar numa reunião, sem precisar convencer ninguém de que o código “está feio”.

Medindo o débito com números que o negócio entende

Gerente e diretor não reagem a “complexidade ciclomática”. Reagem a prazo, dinheiro e risco. As métricas que melhor fazem essa ponte:

1. Tempo de entrega (lead time): quanto tempo uma mudança leva do commit à produção. Se dobrou em um ano sem o time diminuir, algo está pesando.
2. Taxa de falha em mudanças: que porcentagem dos deploys causa incidente ou rollback.
3. Tempo gasto em retrabalho: peça para o time marcar, por duas ou três sprints, as tarefas que existiram só por causa de código problemático. Vira uma porcentagem concreta.
4. Pontos quentes (hotspots): arquivos que mudam com muita frequência e também concentram bugs. O histórico do Git mostra os primeiros; o rastreador de issues, os segundos.

O quarto item é o insight que mais economiza esforço: código feio que ninguém mexe não cobra juros. Um módulo antigo e estável pode ficar como está por anos. A dívida cara é a que fica no caminho das mudanças frequentes. Priorize por aí, não pela feiura.

Ferramentas de análise estática estimam a dívida em horas, e ajudam como termômetro. Só não trate o número como verdade absoluta: elas contam padrões, não sabem quais partes do sistema o negócio mais usa.

Como negociar o pagamento com quem decide prioridades

Pedir “uma sprint para refatorar” raramente funciona. O que costuma funcionar é amarrar a dívida a um objetivo do negócio:

• Traduza em custo: “cada mudança no checkout leva três dias a mais do que deveria; nas últimas dez, foram trinta dias de trabalho”.
• Ligue a uma meta: “o Pix parcelado que vocês querem para o trimestre passa por esse módulo”.
• Proponha parcelas: reservar uma fatia fixa de cada sprint (muitos times usam algo entre 10% e 20%) é mais fácil de aprovar do que uma pausa geral.
• Pague junto com a feature: refatore o pedaço que a funcionalidade nova vai tocar, como parte da mesma tarefa.

O próprio texto de Fowler sobre a metáfora argumenta que, quando os juros são altos, vale pagar logo; quando o código raramente é tocado, pode ser mais econômico conviver com a dívida.

Um caso de débito que saiu caro, em números

Pense num sistema de agendamento de uma rede de clínicas. No lançamento, para cumprir o prazo, o time gravou os horários de funcionamento direto no código, com um if para cada unidade. Era a dívida prudente e deliberada do quadrante: funcionava para três clínicas e economizou duas semanas.

Dois anos depois, a rede tem 40 unidades. Cada mudança de horário vira um deploy. Feriado municipal em uma cidade exige alterar código, revisar, testar e publicar. O time estima que gasta cerca de um dia por semana só nisso, somando pedidos de alteração e bugs de horário errado.

• Principal: criar uma tabela de horários e uma tela de administração, algo como três semanas de trabalho.
• Juros: um dia por semana, ou seja, cerca de quatro semanas de trabalho a cada mês.
• Resultado da conta: em menos de um mês, pagar a dívida custa menos do que continuar convivendo com ela.

Esse é o argumento que convence o gestor, porque é feito com o mesmo raciocínio de qualquer financiamento: quanto falta para quitar e quanto se paga por mês enquanto não quita.

Registrar a dívida no dia em que ela nasce

O hábito que mais separa dívida prudente de bagunça é anotar. Ao escolher um atalho, abra uma issue com o rótulo de débito técnico contendo: o que foi simplificado, por quê, qual o risco e o que dispararia o pagamento (“quando passarmos de mil pedidos por dia”). Um comentário // TODO solto no código não basta; ninguém revisa TODOs.

No buildbase, o texto sobre proteção de dependências npm mostra um tipo de dívida que costuma ser esquecida: bibliotecas desatualizadas, que viram risco de segurança e não só de manutenção.

Para o júnior: como não criar dívida imprudente sem perceber

Você não controla o prazo do projeto, mas controla o que entrega dentro dele. Nomes claros, funções curtas, um teste para o caso principal e um aviso explícito no pull request (“fiz assim por causa do prazo; o ideal seria X”) já transformam uma dívida acidental em deliberada e prudente. O revisor agradece, e o você de daqui a seis meses também.

A recomendação direta: na próxima vez que alguém disser “depois a gente arruma”, peça para virar uma issue com dono e gatilho. Se outros termos do assunto, como refatoração ou code review, ainda soam vagos, o glossário de programação para iniciantes do buildbase explica cada um.