Analisando a Dívida Técnica

O termo "dívida técnica" foi definido por Ward Cunningham. e descreve a dívida que a equipe de desenvolvimento assume quando escolhe um design ou abordagem fácil de implementar no curto prazo mas com grande impacto negativo no longo prazo. Alguns agilistas opinaram sobre o que deve ser considerada dívida técnica e como poderia ser classificada.

Martin Fowler sugeriu a seguinte definição para dívida técnica,

A dívida técnica é similar à dívida financeira. Assim como a dívida financeira, a dívida técnica exige o pagamento de juros. Estes vem na forma de esforço extra, que devem ser pagos em desenvolvimentos futuros por conta da escolha de um design mais rápido e de baixa qualidade. Nós podemos optar por continuar pagando estes juros ou quitar de uma vez a dívida fazendo uma refatoração, transformando um design de baixa qualidade em um design melhor. Apesar dos custos para saldar a dívida, ganhamos reduzindo os juros no futuro.

Steve McConnell classificou a dívida técnica em dois tipos,

• Sem querer – Desenvolvedores junior escrevem código de baixa qualidade por conta de sua inexperiência técnica.
• Intencional - A equipe faz uma decisão consciente para otimizar para o momento atual e não para o futuro, fazendo algumas escolhas de design que podem ser uma maneira rápida e de baixa qualidade para resolver a situação.

Uncle Bob, adiciona que muitas vezes um código bagunçado é considerada divida técnica. Mas isso está errado. Segundo ele,

Bagunça não é dívida técnica. Bagunça é só bagunça. Decisões que geram dívidas técnicas se baseiam em restrições do projeto. Elas são arriscadas, mas podem trazer beneficios. A decisão de fazer uma bagunça no código nunca é racional; é sempre baseada na preguiça e na falta de profissionalismo e não têm chances de ser pagas no futuro. A bagunça é sempre uma perda.

Uncle Bob sugere que a dívida técnica cria a necessidade de limpeza no código, assim como a necessidade de ser mais disciplinado quando assumir uma grande dívida. Ele adiciona que uma vez que a equipe decida assumir um dívida técnica, torna-se ainda mais importante manter o código completamente limpo. Caso contrário, a situação poderá se agravar e pagar a dívida pode se tornar um grande desafio.

Martin Fowler aponta que bagunça também é um dívida técnica embora de natureza diferente. Ele a descreve como dívida irresponsável, a qual resulta em desafios ainda maiores se comparados com uma dívida prudente baseada em uma situação pensada. Além disso, ele classifica a dívida técnica como proposital e sem querer para completar a lista.

Martin cita os seguintes exemplos de classificação de dívidas técnicas:

1. Irresponsável e proposital – O time não tem tempo para o design e utiliza uma solução rápida e com pouca preocupação com a qualidade.
2. Prudente e proposital – O time precisa entregar o produto agora com todas as limitações conhecidas e assume de maneira pró-ativa as consequências.
3. Irresponsável e sem querer – O time não tem consciência dos principios básico de design e então nem sequer imagina a bagunça que estão adicionando.
4. Prudente e sem querer – Isso é verdade para times com excelentes arquitetos. Eles fornecem uma solução que agrega valor ao negócio, mas depois de completar a solução, eles entendem que a abordagem de design poderia ter sido melhor.

Desta forma, ter uma dívida técnica em um projeto é normalmente inevitável e deve ser considerado como sendo uma expectativa. A chave está em ter certeza de que o time não está introduzindo dívidas irresponsáveis que contribuem para bagunçar o código e são muito difíceis, senão impossíveis de lidar.