Il debito tecnico è il divario tra come il codice è e come dovrebbe essere, assunto (deliberatamente o meno) per muoversi più velocemente. Un po' di debito va bene; il compito è gestirlo, non eliminarlo. La chiave è dare la priorità al debito che effettivamente danneggia.
Perché è importante
text
For each piece of debt, ask:
- How often does it slow us down or cause bugs? (frequency)
- How bad is it when it bites? (severity)
- How risky/expensive is it to fix? (cost)
High frequency + high severity + low cost → fix now
Low frequency + low severity → leave it, document it
Un esempio concreto
Un modulo fragile che si rompe ad ogni rilascio e blocca il team settimanalmente merita di essere corretto. Un'utility brutta-ma-stabile che nessuno tocca lo è, anche se ti offende. Refactorizzarla è vanità, non valore.