Todo mundo que escreve código convive com débito técnico — aquele atalho que resolveu o problema de ontem e cobra juros hoje. O erro mais comum não é criar débito; é tratar todo débito como pecado e querer refatorar tudo, sempre, agora. Este guia é para quem sente o código "apodrecendo" mas precisa continuar entregando: a ideia é trocar culpa por critério.
O que é débito técnico (e o que não é)
Débito técnico é a distância entre a solução que você entregou e a solução que você adiaria para "fazer direito". Ele nasce de escolhas conscientes ("vamos hardcodar agora e generalizar depois") e também de decisões que nem sabíamos que estávamos tomando — falta de contexto, prazo curto, aprendizado que só chegou depois.
O que não é débito técnico: código feio que funciona e ninguém precisa tocar, ou uma arquitetura simplesmente diferente da sua preferida. Débito é aquilo que aumenta o custo de mudar o sistema no futuro. Se ninguém vai encostar naquele trecho tão cedo, o juro é baixo — e talvez você nem precise pagar.
Nem todo débito é ruim: a analogia dos juros
Pense como quem pega um empréstimo. Dívida pode ser burrice ou alavancagem, dependendo do que você faz com ela e do tamanho dos juros. Um atalho que te faz validar uma ideia semanas antes pode valer muito mais do que a refatoração que ele adia. O problema quase nunca é o atalho consciente; é a dívida esquecida, acumulando juros silenciosos até o dia em que qualquer mudança pequena vira um pesadelo.
A pergunta certa nunca é "isso está perfeito?". É "quanto custa conviver com isso — e esse custo está subindo?".
O quadrante: quatro tipos de débito
Uma forma simples de enxergar débito é cruzar duas perguntas: a decisão foi intencional ou acidental? E foi prudente ou imprudente?
- Intencional e prudente: "sabemos que não é ideal, mas precisamos lançar; anotamos o porquê." É o bom débito.
- Intencional e imprudente: "não temos tempo de fazer certo" — repetido para sempre, sem plano. Aqui mora o perigo.
- Acidental e prudente: "agora que entendemos o domínio, sabemos como deveríamos ter feito." Aprendizado puro, saudável e esperado.
- Acidental e imprudente: o time não sabia o que não sabia. Combate-se com estudo, revisão e mentoria — não com culpa.
O rótulo importa porque muda a conversa: débito prudente se gerencia; débito imprudente se previne.
Critérios para decidir: pagar, agendar ou conviver
Antes de abrir a IDE para "arrumar", passe o trecho por três filtros:
- Frequência de mudança. Você mexe nesse código toda semana ou ele está congelado há meses? Débito em código quente cobra juros altos; débito em código morto é quase de graça.
- Raio de impacto. Um atalho isolado atrás de uma interface é fácil de trocar depois. Um atalho que vazou para dez lugares já está te custando caro.
- Risco. Se o pior caso é um detalhe estético, conviva. Se o pior caso envolve dados, dinheiro ou segurança, suba a prioridade — mesmo que o código pareça "ok".
Com esses filtros, a decisão quase se resolve sozinha:
- Pagar agora quando o código é quente, o raio é grande e o risco é real — de preferência refatorando junto com a próxima feature que encostar ali.
- Agendar quando o custo é médio e previsível: registre, dê visibilidade e trate como trabalho de verdade, não como "quando sobrar tempo" (nunca sobra).
- Conviver quando o código é frio e isolado: aceite de forma consciente e siga em frente.
O pitfall clássico é o oposto disso: a refatoração heroica de fim de semana, gigante e desconectada de qualquer entrega. Ela costuma introduzir mais risco do que resolve.
Como registrar e negociar com o time e o negócio
Débito que mora só na sua cabeça não existe para o resto do time — e some quando você troca de projeto. Deixe rastro onde o time já olha: um comentário curto explicando a decisão e o gatilho para revisitá-la, um item no backlog com o custo em linguagem clara, ou uma nota na própria tarefa que criou o atalho.
E aqui vai a parte que quase ninguém ensina: você não vende refatoração falando de código. Fora da engenharia, ninguém se importa com "acoplamento". Traduza para risco e custo de mudança. "Esse atalho faz cada alteração nessa tela levar o triplo do tempo e quebrar em produção" é uma frase que produto e liderança entendem — e priorizam.
Fechando a conta
Débito técnico não é o vilão da história; é uma ferramenta de negócio como qualquer outra. Times maduros não têm zero débito — eles sabem exatamente qual débito carregam, por que aceitaram e quando pretendem revisitar. Da próxima vez que bater a culpa por um atalho, troque a pergunta: em vez de "isso está certo?", pergunte "esse custo está subindo — e vale a pena pagar agora?". Só essa troca já separa quem apaga incêndio de quem toma decisão.