Débito Técnico? Dívida Técnica?

Dívida Técnica é uma metáfora* criada por Ward Cunningham, ele conta que em um projeto de desenvolvimento de um software financeiro ele utilizou esta metáfora para explicar o contexto. Ele disse para o chefe dele da época: “Se nós fracassarmos em fazer com que o nosso software esteja alinhado com o que nós entendemos como a maneira adequada de pensar a respeito dos nossos objetos financeiros, então nós vamos esbarrar em desentendimento e isto irá reduzir a nossa velocidade como se estivéssemos pagando juros de um empréstimo”.

[link com a fonte original e um video em inglês]

Metáforas é um conceito muito importante dentro de eXtreme Programming (XP) que muitas vezes é esquecido ou tratado como coadjuvante.

Características da Dívida Técnica

Dado as minhas experiências, eu escrevi algumas observações sobre Dívida Técnica:

• É inevitável, ela sempre vai existir
• Não é passível de comparação entre produtos, projetos, repositórios..
• Se não for pago, o débito tende a aumentar com o tempo
• É “subjetivo”
• Não é um número
• Não é uma medida

Eu vejo como sendo um indicativo de quão fácil ou quão difícil é desenvolver novas funcionalidades e/ou dar manutenção/sustentar a uma determinada aplicação.

Não ter Dívida Técnica é ruim. Isto se chama Gold plating.

Causas da Dívida Técnica

Algumas causas de se acumular Dívida Técnica:

• Upfront design (BDUF – geralmente é associado ao modelo Waterfall/Cascata)
• Gambiarras
• Deliberadamente sacrificar a qualidade para entregar na data
• Implementar funcionalidade que não havia sido prevista
• Falta de conhecimento técnico
• Complexidade
• Escolha de tecnologia/ferramenta/plataforma inadequada
• Passar do tempo: código envelhece e apodrece

[exemplo: dependências, frameworks e bibliotecas exigem atualizações, softwares descontinuados e outros]

Quadrantes da Dívida Técnica

Basicamente, podemos classificar a Dívida Técnica em 4 tipos distintos:

• Imprudente e Intencional: “Sabemos do problema, não vamos resolver”
• Imprudente e Não Intencional: “Trabalhar com uma nova linguagem de programação”
• Consciente e Intencional: “Dado nosso deadline, vamos entregar com o problema e depois corrigir o problema”
• Consciente e Não Intencional: “Agora que entregamos o projeto, deveríamos ter trabalhado utilizando Métodos Ágeis”

O que deveríamos almejar é sempre ter Dívida Técnica nos quadrantes verdes abaixo. Estes, são os quadrantes onde temos consciência sobre assumir um risco que pode gerar um impacto no futuro. Embora os quadrantes azuis não sejam inevitáveis, eles representam e abordam fatores que nem sempre são facilmente compreendidos. Por exemplo: trabalhar com uma nova tecnologia ou um novo framework que o time não possui conhecimento vai fazer com que o resultado provavelmente não seja tão aderente e benéfico quanto deveria ser.

 

[fonte original quadrantes da Dívida Técnica do Martin Fowler]

Aspectos Mensuráveis do Dívida Técnica

Alguns exemplos, de aspectos que podem ser mensurados ao longo do desenvolvimento de um software:

• Complexidade ciclomática
• Duplicação de código
• Cobertura de código (testes unitários)
• LoC (linhas de código)
• Coesão de código
• Checkstyle
• Tamanho dos métodos
• Fragilidade de builds
• Fragilidade dos testes automatizados
• Linhas de código comentadas na aplicação
• Regras do SonarQube (ex Sonar) – Exigem “intervenção” humana

Embora existam muitos outros aspectos, mesmo que todos os exemplos acima e os não citados sejam mensurados nada disso garante que a Dívida Técnica será baixa. Ferramentas automatizadas são passíveis de retornar “Falsos Positivos” (exemplo: uma ferramenta automatizada identificando um padrão ou problema que na realidade não é um problema).

 

Publicidade