Todo código é dívida técnica
Enquadrar “todo código como dívida técnica” provoca debate sobre se o termo foi esticado além de sua utilidade ou se ele destaca de forma útil que cada funcionalidade e linha de código adicionadas carregam um custo contínuo. Comentadores revisitam a metáfora original de dívida de Ward Cunningham, a contrastam com a interpretação moderna de “atalho” e defendem que o código é melhor visto como um passivo, estoque ou ativo depreciável cujo valor precisa justificar sua manutenção e complexidade. Muitos enfatizam que a verdadeira alavancagem vem de menos funcionalidades, bem escolhidas, da remoção agressiva de código não utilizado e do envolvimento das partes interessadas do negócio em trocas explícitas entre velocidade, qualidade e flexibilidade de longo prazo.
Escopo de “Dívida Técnica”
- Muitos argumentam que o artigo dilui “dívida técnica” ao chamar todo código de dívida; eles veem dívida técnica como atalhos específicos ou projetos desalinhados que geram “juros” em trabalho futuro.
- Outros ampliam o termo: qualquer descompasso entre o código atual e o entendimento/requisitos atuais, ou, de forma mais geral, qualquer impedimento entre o que você quer fazer com o sistema e como ele realmente é.
- Há debate sobre o significado original (defasagem de design impulsionada por aprendizado) vs. o uso moderno “sabíamos que estávamos cortando caminho”; alguns lamentam que termos precisos como “dívida técnica” e “refatoração” tenham ficado nebulosos.
Código como Passivo, Ativo ou Estoque
- Um tema forte: código é um passivo/custo de manutenção. Mais código → mais para entender, manter e adaptar; código deletado é celebrado.
- Contraponto: software executável e funcionalidades úteis são ativos; o código é pelo menos em parte um ativo porque possibilita mudança e criação de valor.
- Alguns preferem analogias como “estoque” ou “ativo depreciável” em vez de “dívida” ou “passivo puro”.
Complexidade, Funcionalidades e Pressupostos
- Mais funcionalidades e pressupostos aumentam a complexidade e o atrito futuro, mesmo que “funcionem” hoje.
- Vários observam que a maioria dos projetos não remove código ou funcionalidades suficientes; código obsoleto ou não usado persiste, acumulando custos ocultos.
- Uma ideia recorrente: boa engenharia é minimizar pressupostos e conceitos, e trabalhar dentro dos existentes sempre que possível.
Qualidade, Entropia e Manutenção
- Muitos veem a dívida técnica como uma forma de entropia: decisões bem-intencionadas se acumulam em complexidade à medida que requisitos, plataformas e pessoas mudam.
- Fez-se uma distinção entre “má programação” e bom código que simplesmente reflete entendimento ou requisitos desatualizados.
- Testes e abstrações também têm custo; abstração excessiva (por exemplo, DRY levado longe demais) pode ser pior do que duplicação.
Questões Organizacionais e de Comunicação
- Partes interessadas do negócio frequentemente tratam “dívida técnica” como um incômodo puramente técnico; comentaristas enfatizam enquadrá-la em termos de tempo de lançamento, confiabilidade e custo de oportunidade.
- Os incentivos da gestão favorecem adicionar funcionalidades e adiar a limpeza; propor refatorações ou reescritas é arriscado e atrai muita culpa.
Recepção do Artigo
- Alguns acharam o título e a premissa caça-cliques ou redutivos; outros apreciaram que ele provoca reflexão sobre exagero de projeto, inflação de funcionalidades e o valor de escrever menos código.