Como medir a dívida técnica
Na vida, costuma haver mais de uma maneira de alcançar um objetivo. O caminho escolhido por uma pessoa pode ser completamente diferente do percurso ou método usado por outra para chegar ao mesmo ponto.
Esse conceito também se aplica ao desenvolvimento de software.
No entanto, ao criar software, você pode seguir diferentes caminhos para chegar ao mesmo lugar, e ainda assim um pode ser melhor do que o outro. Então, como encontrar a verdadeira «melhor maneira» de construir um sistema de software eficaz? É um grande dilema.
Quando um desenvolvedor ou uma equipe adota uma abordagem errada de engenharia de software, incorre em dívida técnica, percebendo isso ou não.
Neste artigo, explicamos o conceito de dívida técnica e como um responsável pelo produto pode medi-la, gerenciá-la e reduzi-la.
O que é dívida técnica?
Imagine que suas equipes escolham constantemente um método de desenvolvimento mais simples e intuitivo em vez de opções avançadas, porém mais trabalhosas. Elas concluem as tarefas com facilidade, mas o processo introduz lentamente falhas no código e na arquitetura. A cada decisão baseada nessa fundação defeituosa, a equipe acumula, pouco a pouco, uma dívida de software, ou seja, dívida técnica.
É natural pensar que qualquer pessoa gostaria de construir um sistema de software da maneira correta. Mas a maneira correta costuma ser a mais difícil. Ao comparar a complexidade do código de algoritmos de força bruta, normalmente simples e intuitivos, com versões avançadas menos intuitivas, é muito mais fácil escolher o caminho que exige um raciocínio mais simples.
Além disso, considere todas as pressões externas para entregar algo atraente rapidamente. Não surpreende que uma equipe de engenharia escolha o caminho mais rápido do ponto A ao B sem considerar o custo desses atalhos.
O problema é que, para ser um responsável pelo produto bem-sucedido, você precisa fazer as coisas corretamente desde o início. Caso contrário, há uma grande chance de ter que voltar atrás em algum momento e compensar a falta de esforço ou de atenção aos detalhes.
A origem do problema
A dívida técnica pode ser deliberada ou involuntária. A maioria das equipes de engenharia de software tem alguma consciência de que ela se acumula ao longo do trabalho.
Assim como a dívida financeira, a dívida técnica gera juros. Quanto mais tempo você passa sem corrigi-la, pior o problema fica. Por quê? Pela forma como a programação funciona, muitas vezes é necessário criar mais código defeituoso para corrigir o original. Com o tempo, você precisará de ainda mais código mal escrito para tentar gerenciar a bagunça crescente.
A dívida técnica acidental pode surgir de problemas latentes anteriores à equipe atual. Um exemplo é o software desatualizado. À medida que os padrões aumentam e os custos de manutenção crescem, é fácil ficar para trás sem perceber.
Os custos da dívida técnica
Quando você começa a descuidar do código, é difícil parar. Ao adicionar funcionalidades mais adiante, os desenvolvedores incorporam mais código defeituoso. Com o tempo, os compromissos iniciais de criar algo limpo e eficaz são abandonados e os padrões diminuem. A realidade é que manter código defeituoso se torna mais complicado, então você só piora as coisas para si e para sua equipe.
O caminho do «atalho» até a chegada tem suas próprias consequências. Os diferentes tipos de dívida técnica podem causar problemas de produtividade, complexidade do código, cobertura de testes e quantidade de linhas. Além disso, você precisa considerar os custos de suas equipes perderem tempo contornando problemas no sistema ou reformularem tudo quando a dívida técnica se tornar difícil demais de gerenciar.
Medir a dívida técnica: o índice de dívida técnica
A melhor maneira de evitar esses problemas e custos no desenvolvimento de software é medir a dívida técnica e depois encontrar soluções para gerenciá-la.
Primeiro, há muitas variáveis a considerar no cálculo: complexidade ciclomática, linhas de código, profundidade de herança, profundidade de aninhamento, acoplamentos aferentes e eferentes e muitas outras.
Como regra geral, a solução mais simples é expressar o problema como uma proporção. O índice de dívida técnica mede a diferença entre o custo de corrigir o software e o custo de desenvolvê-lo.
Índice de dívida técnica = (custo de correção dividido pelo custo de desenvolvimento) x 100
O ideal é ter um índice de dívida técnica de 5% ou menos. Se for maior, ele reflete software de baixa qualidade.
Vamos aplicar essa análise a um caso de negócio. Imagine que você queira transformar o custo de correção (RC) em uma função da métrica de qualidade que sua equipe considere mais relevante com base nas regras para resolver problemas de código. Você pode expressá-lo como uma função da complexidade ciclomática, que descreveria quanto tempo leva para corrigir problemas de uma função de código. O RC passa a ser diretamente proporcional à complexidade dessa função. Depois de determinar isso, você pode calcular quanto tempo levará para corrigir todo o problema.
Você pode aplicar esse mesmo conceito a outras métricas de qualidade do código e medir e gerenciar a dívida técnica de outras maneiras.
Reduzir e gerenciar a dívida técnica
A melhor maneira de reduzir a dívida técnica é gerenciá-la regularmente e não deixá-la de lado. É fácil ignorá-la até chegar ao final, mas, quanto mais você a evita, mais ela empurra a verdadeira linha de chegada para longe.
Enquanto desenvolve seu software, considere obter uma cobertura regular de testes com automação para reduzir o acúmulo de dívida técnica. Revisitar essa fórmula expressa como índice durante o desenvolvimento economizará horas de trabalho e muito dinheiro no futuro em troca de um esforço muito menor agora. Na engenharia de software, sempre vale a pena fazer as coisas corretamente.