BT

A sua opinião é importante! Por favor preencha a pesquisa do InfoQ!

Analisando a Dívida Técnica

| por Vikas Hazrati Seguir 0 Seguidores , traduzido por Rodrigo Branas Seguir 0 Seguidores em 26 out 2009. Tempo estimado de leitura: 3 minutos |

A note to our readers: As per your request we have developed a set of features that allow you to reduce the noise, while not losing sight of anything that is important. Get email and web notifications by choosing the topics you are interested in.

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.

Avalie esse artigo

Relevância
Estilo/Redação

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

Dê sua opinião

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

Termo correto em português by Daniel Cukier

Em português, a tradução correta de "technical debt" seria "dívida técnica" e não "débito técnico".

debt = dívida (algo que não foi pago e precisará ser pago no futuro)
debit = débito (um valor que foi retirado de uma conta). Sugiro, se possível, acertar a tradução do artigo para usar o termo correto.

Re: Termo correto em português by Rafael Fuchs

Fazendo a tradução correta, o termo dívida deixa mais claro o problema e o que significa isso. Débito dá mais a ideia de que está faltando algo, que foi retirado algo. Dívida dá mais a ideia de algo que o time está devendo algo tecnicamente.

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

2 Dê sua opinião

Faça seu login para melhorar sua experiência com o InfoQ e ter acesso a funcionalidades exclusivas


Esqueci minha senha

Follow

Siga seus tópicos e editores favoritos

Acompanhe e seja notificados sobre as mais importantes novidades do mundo do desenvolvimento de software.

Like

Mais interação, mais personalização

Crie seu próprio feed de novidades escolhendo os tópicos e pessoas que você gostaria de acompanhar.

Notifications

Fique por dentro das novidades!

Configure as notificações e acompanhe as novidades relacionada a tópicos, conteúdos e pessoas de seu interesse

BT