Dívida técnica: 3 sinais que custam antes de se verem

A dívida técnica nunca se apresenta como tal. Ninguém escreve «isto é dívida» num commit. Vê-se primeiro no dia a dia: tarefas simples que levam três dias, deploys que metem medo, ficheiros em que ninguém ousa tocar.

1. As pequenas alterações custam cada vez mais

O sinal mais fiável: compare o que custa hoje uma alteração trivial — um texto, um campo de formulário — com há seis meses. Se a tendência sobe sem que o produto tenha mudado de escala, a estrutura do código resiste à mudança. É a definição operacional de dívida.

2. Os mesmos bugs voltam com outras formas

Um bug corrigido que reaparece noutro sítio não é azar: é lógica duplicada ou uma responsabilidade mal colocada. Cada correção local acrescenta mais uma variante para manter. A correção real quase nunca está onde o bug se manifesta.

3. O conhecimento vive em cabeças, não no sistema

Se o deploy, a configuração ou «porque é que este módulo funciona assim» dependem de uma pessoa específica, o sistema não é transferível. Não é primeiro um problema de documentação — é sinal de que o sistema é demasiado complexo para se explicar de forma simples.

Por onde começar

Não por um «grande refactoring». Meça uma coisa: o tempo real das pequenas alterações. Depois retire — uma duplicação, uma dependência, um passo manual — de cada vez que lá passar. A sobriedade não é uma obra, é uma prática.