Os sistemas de software tendem a acumular falhas internas do lixo que dificultam a modificação e expansão do sistema em comparação com o código ideal. Dívida técnica é uma metáfora inventada por Ward Cunningham. Ela explica como perceber esse lixo, por analogia com um empréstimo financeiro. Esforços adicionais necessários para adicionar novos recursos são juros sobre o empréstimo.



Imagine que na minha base de código há um módulo de uma estrutura confusa. Precisa adicionar um novo recurso. Se a estrutura fosse clara, o trabalho levaria quatro dias, mas com esse lixo leva seis dias. A diferença em dois dias - esse é o interesse da dívida.

O que mais me atrai na metáfora da dívida é uma clara compreensão dos custos de manutenção ou eliminação. Posso passar cinco dias limpando a estrutura modular, removendo o lixo, pagando metaforicamente o “credor”. Se eu fizer isso para esta função, perderei porque passarei nove dias em vez de seis. Porém, se houver mais duas funções desse tipo, é mais lucrativo remover o lixo.

Com essa formulação, a tarefa se torna puramente matemática. Qualquer gerente com um tablet eletrônico o resolverá. Infelizmente, não podemos medir o desempenho , portanto, nenhum custo é objetivamente mensurável. Podemos estimar aproximadamente quanto tempo leva para desenvolver a função, quanto tempo levará para trabalhar após a remoção do lixo - e assumir o custo de removê-lo. Mas a precisão de tais estimativas é bastante baixa.

Portanto, geralmente a melhor opção é fazer o que costumamos fazer com dívidas financeiras: pagar gradualmente o principal. Na primeira função, passarei alguns dias extras para remover um pouco do lixo. Isso pode ser suficiente para reduzir os juros da dívida, para que no futuro ela possa ser paga em um dia. Ainda é tempo extra, mas com a remoção do lixo, as mudanças futuras ficam mais baratas. A grande vantagem da melhoria incremental é que, naturalmente, passamos mais tempo removendo o lixo em áreas que mudam frequentemente. Essas são precisamente as áreas da base de código que mais precisam de descarte de lixo.

A comparação dos pagamentos de juros com o pagamento da dívida principal ajuda a determinar com que tipo de lixo lidar. Se eu tiver uma área particularmente terrível da base de código, o problema desaparecerá se resultar que não é rentável excluir o lixo. Os juros são pagos somente quando você precisa trabalhar com essa parte do software (a metáfora é um pouco esfarrapada nesse local, porque você sempre precisa pagar com um empréstimo bancário). Assim, áreas de código pesadelos, mas estáveis, podem ser deixadas em paz.

Diferentemente das partes estáveis ​​do código, as áreas de alta atividade exigem tolerância zero para lixo, porque os pagamentos de juros são extremamente altos lá. Isso é especialmente importante, pois o lixo se acumula onde os desenvolvedores fazem alterações sem prestar atenção à qualidade: quanto mais alterações, maior o risco de lixo.

Às vezes, uma metáfora da dívida é usada para justificar um código de baixa qualidade. O argumento é que o código de qualidade requer mais tempo e esforço. Se você precisar urgentemente de novos recursos, é melhor assumir a dívida e lidar com ela mais tarde

O perigo aqui é que muitas vezes essa análise é errônea. O lixo começa a prejudicar muito rapidamente, retardando a introdução de novos recursos. Como resultado, os desenvolvedores excedem os limites de crédito e lançam o produto mais tarde do que se passassem imediatamente o tempo oferecendo qualidade superior. Aqui, a metáfora geralmente engana as pessoas, porque a dinâmica da dívida técnica não corresponde realmente à dinâmica dos empréstimos financeiros. Assumir que a dívida para acelerar o lançamento do produto só funcionará se você permanecer abaixo da linha de retorno do projeto na hipótese de sustentabilidade da arquitetura , e os desenvolvedores a ultrapassarem em poucas semanas, não meses.



São realizados debates regularmente sobre se vários tipos de lixo devem ser considerados dívidas. Parece-me que é útil levar em consideração aqui que um dever é tomado consciente e razoavelmente - ou de forma imprudente. Então, um quadrado de dívida técnica apareceu .

Leitura adicional

Pelo que sei, Ward introduziu esse conceito pela primeira vez no relatório OOPSLA de 1992 . Também foi discutido no wiki .

Há uma gravação de vídeo em que Ward Cunningham discute sua metáfora.

Dave Nicolette amplia a visão de Ward sobre dívida técnica, fornecendo um bom exemplo do que eu chamo de dívida intencional razoável .

Vários leitores sugeriram outras metáforas válidas. David Panarity chamou o desenvolvimento de baixa qualidade de escassez de programação . Aparentemente, ele começou a usar o termo há vários anos, quando era consistente com a política do governo; Acho que agora é relevante novamente.

Scott Wood sugeriu tratar “ a inflação técnica como perda de solo, quando o nível atual de tecnologia excede o nível do seu produto e cai gradualmente no meio ambiente. Os programas ficam para trás nas versões do idioma a tal ponto que o código não é mais compatível com os principais compiladores ".

Steve McConnell destacou vários bons pontos na metáfora. Em particular, como uma redução na dívida não intencional deixa mais espaço para aceitar intencionalmente a dívida quando é útil. Também gosto da sua formulação de pagamentos mínimos (altos demais para corrigir problemas em sistemas embarcados, mas não em sites).

Aaron Erickson falou sobre o financiamento da Enron .

Henrik Kniberg argumenta que a antiga dívida técnica está causando o maior problema e que é aconselhável estabelecer um teto de dívida de alta qualidade para facilitar o gerenciamento.

Eric Dietrich discute a perda humana devido a dívida técnica : batalhas de equipe, degradação de habilidades e esgotamento.

Edições

Este post foi publicado originalmente em 1 de outubro de 2003. Eu o reescrevi completamente em abril de 2019.