Código Não é Dívida Técnica
Tratar software puramente como “dívida técnica” é questionado por quem argumenta que o código é fundamentalmente um ativo que entrega valor de negócio, ainda que com custos de manutenção contínuos e passivos potenciais. Os comentaristas debatem se é mais útil modelar o código como ativo, passivo ou capital depreciável, como metáforas como dívida influenciam decisões sobre refatoração e adiamento de trabalho, e quando reescritas completas são justificadas. Muitos concluem que a funcionalidade é o verdadeiro ativo, enquanto a qualidade do código, a cobertura de testes, os requisitos em mudança e a carga cognitiva determinam se o valor líquido desse ativo supera seus custos de longo prazo.
Código: Ativo, Passivo ou Ambos
- Muitos argumentam que o código é fundamentalmente um ativo: ele incorpora funcionalidade que gera valor de negócio.
- Outros insistem que o código é mais útilmente modelado como um passivo: cada linha adiciona manutenção futura e carga cognitiva.
- Vários conciliam isso dizendo que a funcionalidade é o ativo; o código que a realiza é um custo ou passivo que pode superar seu valor.
O que “Dívida Técnica” Realmente Significa
- Uso incorreto comum: “dívida técnica” == “código ruim.” Vários comentaristas não gostam dessa confusão.
- Enquadramento alternativo: dívida técnica é a lacuna entre a implementação atual e como você a construiria hoje com conhecimento completo e sem pressão de tempo.
- Outra visão: dívida técnica é trabalho adiado ou feito por atalho, melhor descrito como “trabalho diferido” para evitar excesso de confiança nas estimativas de custo.
- Alguns argumentam que a metáfora de “dívida” é falha: código malfeito é mais parecido com destruir valor presente do que assumir uma obrigação.
Métricas, Linhas de Código e Complexidade
- Forte reação contrária a medir custo ou valor por linhas de código.
- Mais código frequentemente se correlaciona com mais bugs e complexidade, mas menos linhas também podem ser piores se forem obscuras ou excessivamente espertas.
- Ênfase na carga cognitiva, clareza e qualidade da abstração em vez do tamanho bruto.
Quando Reescrever ou Refatorar
- Reescritas completas são retratadas como de alto risco e raramente justificadas; refatoração incremental mais testes fortes é preferida.
- Alguns veem “grandes reescritas” recorrentes em bases de código mal testadas, enquanto sistemas bem testados parecem ativos e evoluem com mais segurança.
Contexto: Tipo de Software e Escala da Equipe
- Faz-se uma distinção entre ferramentas de sistema relativamente estáveis e software de negócio em rápida mudança, com requisitos mutáveis e equipes rotativas.
- O que parece “sem dívida técnica” em domínios individuais e de baixa mudança muitas vezes não se generaliza para produtos grandes e em evolução.
Analogias de Contabilidade e Imóveis
- Múltiplas comparações com casas, fábricas e imóveis: ativos com manutenção contínua e depreciação.
- Comentadores com mentalidade contábil enfatizam: código é um ativo; a manutenção associada e os atalhos são passivos, não necessariamente “dívida”.
Outras Perspectivas e Meta
- As metáforas incluem jardins, eletrodomésticos de cozinha, aviões (peso), dentes e andaimes para raciocinar sobre valor versus manutenção.
- Alguns acham que “dívida técnica”, como termo, ficou tão sobrecarregado que obscurece mais do que esclarece.