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
Multi-tenancy em Laravel: Single DB vs Schema Separado vs Banco Separado
Uma análise prática das três abordagens de multi-tenancy no Laravel, com os trade-offs de...
Clean Architecture em PHP: Vale a Pena em Projetos Laravel?
Uma análise honesta sobre quando Clean Architecture agrega valor e quando é over-engineeri...