Dívida técnica: o que é e como pagá-la

Dívida técnica é o custo futuro que você aceita quando entrega um código mais rápido de escrever agora, mas mais difícil de mudar depois. Assim como a dívida financeira, ela não é automaticamente ruim. Vira um problema quando os juros crescem mais rápido que o produto. Aqui, juros significam o tempo extra que cada mudança exige.

Sou um engenheiro sênior brasileiro que já herdou bases de código e liderou uma migração com o sistema no ar. Este guia foca no que importa para fundadores e CTOs: qual dívida ignorar, qual pagar primeiro e quando remendar deixa de fazer sentido.

Principais pontos

• Dívida é um custo sobre mudanças futuras, não uma medida de código feio. Código que ninguém toca quase não custa nada.
• A dívida perigosa fica nos caminhos do dinheiro (cadastro, checkout, cobrança) e no processo de build e deploy.
• Dá para medir dívida sem ferramentas especiais: o tempo para entregar uma mudança pequena, o histórico de incidentes e as áreas que ninguém tem coragem de mexer.
• Priorize pelos juros pagos, não pelo quanto o código te incomoda. Pague a dívida onde você já vai trabalhar de qualquer forma.
• Modernize em vez de remendar quando a dívida está na fundação e toda funcionalidade precisa brigar com ela.

O que é dívida técnica?

A metáfora costuma ser atribuída a Ward Cunningham, que a usou no início dos anos 1990. Ele a usou para explicar por que entregar uma primeira versão imperfeita do código pode ser uma escolha razoável, desde que você volte e corrija o que aprendeu.

Na prática, a dívida técnica aparece em algumas coisas concretas:

• Atalhos tomados para cumprir um prazo e nunca revisitados.
• Frameworks, bibliotecas ou runtimes desatualizados que não recebem mais atualizações de segurança.
• Falta de testes, então ninguém tem certeza de que uma mudança é segura.
• Falta de documentação, então o conhecimento vive na cabeça de uma pessoa só.
• Decisões de design que faziam sentido para dez usuários e doem com dez mil.

Repare no que não está na lista: código de que você simplesmente não gosta. Preferência de estilo não é dívida. Dívida sempre tem um preço que você consegue descrever em tempo, risco ou dinheiro.

O que causa dívida técnica num produto em crescimento?

A maior parte da dívida não é culpa de engenheiros ruins. Ela vem de decisões razoáveis tomadas sob pressão e do produto mudando por baixo do código.

Atalhos deliberados

Uma equipe pula testes ou deixa uma regra fixa no código para cumprir uma data de lançamento. Esse é o tipo saudável de dívida, se alguém registrar e planejar voltar. Ela fica tóxica quando é esquecida.

Requisitos que mudam

O produto pivota, mas o modelo de dados e os nomes ainda descrevem o negócio antigo. Toda nova funcionalidade precisa traduzir entre a ideia antiga e a nova.

Rotatividade e passagens de bastão

Quando uma agência ou um desenvolvedor sai, os motivos por trás das decisões saem junto. A próxima pessoa remenda em volta do que não entende, o que acrescenta mais uma camada de dívida.

Atualizações negligenciadas

Dependências envelhecem. Pular atualizações menores por dois anos transforma uma tarefa pequena num projeto arriscado, e os juros se acumulam em silêncio.

Velocidade sem proteções

Prototipar rápido, inclusive com código gerado por IA, é ótimo para aprender. A dívida se acumula quando o protótipo vira o produto sem testes, controle de acesso ou etapa de revisão.

Como diferenciar a dívida inofensiva da dívida que trava o negócio?

Faça uma pergunta: o que acontece se deixarmos isso quieto por mais seis meses? Se a resposta for nada, é inofensiva. Se a resposta for um roadmap mais lento, uma queda do sistema ou uma exposição de segurança, ela está travando o negócio.

O padrão é que a dívida fica perigosa quando se cruza com mudança, dinheiro ou segurança. Dívida num canto tranquilo é ruído de fundo. Dívida num corredor movimentado é um risco.

Como medir a dívida técnica numa base de código herdada?

Raramente você consegue um número limpo, e eu desconfiaria de qualquer ferramenta que diga entregar um. O que dá para conseguir é um conjunto de sinais que, juntos, mostram o quanto é caro conviver com aquele código. Quando assumo uma base de código, trabalho nesta ordem: primeiro os acessos, depois o build, depois os caminhos do dinheiro, depois os riscos. Medir a dívida se encaixa na mesma sequência.

Sinais que valem a pena coletar

• Tempo para entregar uma mudança pequena. Geralmente é a primeira coisa que eu cronometro. Escolha uma tarefa trivial, como mudar um texto ou adicionar um campo, e meça o tempo do ticket até a produção. Tempos longos apontam para dívida de build, testes ou deploy.
• Dá para buildar e rodar do zero? Se uma máquina nova não consegue rodar o projeto seguindo o README, existe conhecimento escondido.
• Histórico de incidentes e bugs. Quais arquivos ou funcionalidades aparecem de novo e de novo? Os reincidentes são onde os juros são mais altos.
• Pontos quentes de mudança. O histórico do controle de versão mostra quais arquivos mudam mais. Arquivos que mudam com frequência e quebram com frequência são seus principais candidatos.
• Mapa do medo. Pergunte à equipe quais partes ela evita mexer. É subjetivo, mas surpreendentemente preciso.
• Situação das dependências e do runtime. Liste o que está sem suporte ou tem vulnerabilidades conhecidas.
• Cobertura de testes onde importa. O percentual geral é menos útil do que saber se os caminhos do dinheiro têm algum teste.

Escreva o que encontrou num documento curto, com um custo aproximado para cada item, como “atrasa toda release”, “arrisca uma queda” ou “bloqueia uma funcionalidade”. Estimativas são aceitáveis, desde que estejam identificadas como tal. Uma análise mais profunda é uma auditoria de código à parte. Eu trataria isso como próximo passo se esses sinais estiverem ruins.

Como priorizar qual dívida pagar primeiro?

Pense em juros e principal. Juros são o que a dívida te custa a cada semana. Principal é o esforço para eliminá-la. Comece pelos juros altos com principal baixo a moderado.

1. Riscos de segurança e de perda de dados. Segredos expostos, falta de controle de acesso, ausência de backups. Esses vêm primeiro, independentemente do esforço.
2. Caminhos do dinheiro. Tudo que envolve pagamentos, cadastro ou o fluxo que gera receita. Um bug aqui tem preço direto. Como trabalhei no time de carrinho e checkout da Total Wine & More, sempre olho código de checkout com cuidado redobrado.
3. Pipeline de entrega. Se os deploys são manuais e assustadores, qualquer outra correção fica mais lenta e mais arriscada. Corrigir isso cedo reduz o custo de tudo que vem depois. Liberar por meio de um deploy canário, primeiro para poucos usuários, deixa os deploys muito menos assustadores.
4. Pontos quentes. Arquivos que mudam com frequência e quebram com frequência.
5. O resto. Deixe para quando tiver um motivo para mexer.

Uma regra prática que eu uso, e é uma heurística minha, não um padrão: pague a dívida na área onde você está prestes a construir uma funcionalidade. Você colhe o benefício na hora, o escopo continua pequeno e o negócio enxerga a ligação entre limpeza e entrega. Reservar uma fatia fixa de cada sprint costuma funcionar melhor do que uma única limpeza heroica. A grande limpeza normalmente é cancelada assim que aparece um prazo.

Na Inovaula, construí a v2 de uma plataforma web e depois liderei a equipe, e chegamos ao fluxo de entrega mais estável que aquela equipe já tinha tido. Minha conclusão pessoal daquele período, não um resultado medido, é que a limpeza funciona melhor como parte normal do trabalho. Ela não precisa ser um projeto separado que exige autorização.

Quando a dívida técnica é motivo para modernizar em vez de remendar?

Remendar funciona quando a dívida é localizada: um módulo bagunçado, uma biblioteca antiga, uma suíte de testes que não existe. Vale considerar a modernização quando a dívida está na fundação e toda funcionalidade precisa brigar com ela.

Sinais de que você cruzou essa linha:

• O framework ou o runtime está sem suporte e não pode ser atualizado aos poucos.
• Contratar é difícil porque poucos engenheiros conhecem a stack.
• Cada correção cria um bug novo em outro lugar porque as partes estão muito emaranhadas.
• A arquitetura não suporta algo de que o negócio precisa, como múltiplos clientes, funcionalidades em tempo real ou escala.
• O custo de remendar, somado ao longo de um ano, passa do custo de migrar.

Mesmo assim, prefiro uma migração incremental a uma reescrita big-bang. Uma reescrita costuma custar mais e levar mais tempo, porque o sistema antigo precisa continuar rodando em paralelo enquanto o novo o alcança. Na avanzzada, liderei a migração completa de uma plataforma que se candidata automaticamente a vagas de emprego pelos seus usuários. Nós migramos toda a arquitetura de uma stack legada para uma nova enquanto as pessoas continuavam usando a plataforma todos os dias. A regra que sigo nesse tipo de migração é colocar um interruptor na frente de tudo antes de escrever código novo. Depois, você move uma peça de cada vez.

Remende as coisas pequenas, modernize a fundação e não confunda uma coisa com a outra.

Quer uma segunda opinião sobre a sua base de código?

Se você herdou uma base de código e não sabe qual dívida importa, mande um e-mail para me@filipeeduardo.dev. Inclua uma descrição curta da stack e do que está doendo, e eu digo o que verificaria primeiro.