Dívida técnica não é sobre código feio — é sobre decisões que ninguém revisita
O mito do código feio
Quando alguém abre um arquivo antigo e torce o nariz, é comum ouvir "isso aqui é dívida técnica". Quase sempre não é. Código feio que funciona, que ninguém precisa mexer e que não trava nada é só código feio — inofensivo, ainda que incômodo aos olhos.
Dívida técnica de verdade é outra coisa: é uma decisão tomada conscientemente (ou não) sob uma restrição de tempo, conhecimento ou escopo, que acumula juros enquanto o sistema cresce em cima dela. A analogia com dívida financeira é literal — você pegou um atalho para entregar mais rápido, e esse atalho cobra parcelas até ser quitado.
De onde vem a dívida de verdade
Na prática, a dívida técnica nasce de três lugares:
- Deliberada e informada. O time sabia que existia um jeito melhor, mediu o prazo e escolheu o atalho conscientemente — geralmente para validar algo antes de investir na versão certa.
- Acidental. Ninguém percebeu o problema na hora. Só ficou visível quando o sistema cresceu e a decisão original deixou de fazer sentido.
- Herdada. O time atual nem estava lá quando a decisão foi tomada. Recebeu o juro sem ter assinado o contrato.
O erro comum é tratar as três do mesmo jeito. Dívida deliberada tem dono e prazo — ela deveria estar documentada, com uma data para ser revisitada. Dívida acidental e herdada exigem investigação antes de qualquer correção, porque ninguém sabe ao certo por que aquilo está do jeito que está.
Como pagar sem parar o produto
Ninguém convence a diretoria a parar seis semanas para "refatorar tudo" — e nem deveria, porque isso raramente é o problema real. O que funciona é tratar dívida como qualquer outro item de prioridade, com um critério simples:
- Ela está no caminho de alguma entrega futura? Se sim, pagar agora é mais barato do que pagar depois de construir mais coisa em cima.
- Ela está causando incidente recorrente? Bug que volta é sinal de que a dívida já está cobrando juro composto.
- Alguém entende por que aquilo existe? Se a resposta é não, o primeiro passo não é reescrever — é investigar antes de destruir contexto que pode ser importante.
Dívida que não atende a nenhum desses três critérios pode esperar. E está tudo bem — nem toda dívida precisa ser quitada, algumas nunca vão cobrar juro suficiente para justificar o esforço.
O hábito que evita a bola de neve
O que separa times que vivem apagando incêndio de times que evoluem com previsibilidade não é talento, é um hábito simples: registrar a dívida no momento em que ela é criada, com uma frase de por quê. Um comentário, um item no board, uma linha num documento — não importa o formato, importa que a decisão fique visível para quem vier depois.
Dívida técnica não é vergonha de engenharia. É parte do trabalho de construir algo rápido o suficiente para existir no mundo real. O problema nunca foi contraí-la — foi esquecer que ela existe.
Posts relacionados
Esconder o menu não é controlar acesso: como fiz módulos que cada cliente liga e desliga
Oficina pequena não quer ver comissão, nota fiscal e portal do cliente no primeiro dia. De...
Webhook não é fonte de verdade: o que aprendi integrando nota fiscal eletrônica
Nota fiscal é processada em segundo plano: você emite, recebe 'processando' e a autorizaçã...
Meu segundo SaaS começou com o código do primeiro: o que deu para reaproveitar e o que precisei reescrever
O Oficina Simples nasceu de um fork do Estoque Simples. Login, planos, cobrança, LGPD e mu...