Monitoramento da Dívida Técnica através da visualização de God Class

Dívida técnica (DT) inclui aquelas tarefas internas que você escolhe não fazer agora, mas que corre um risco de causar problemas futuros se não forem efetuadas. Dessa forma, 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 possibilidade de impacto negativo no longo prazo.

Uma dívida pode ser qualquer aspecto do software que sabemos que está inadequado, mas não temos tempo para ajustá-lo no momento como, por exemplo: documentação desatualizada/inexistente, testes planejados mas não executados, defeitos conhecidos mas não corrigidos. O resultado desses artefatos imaturos é observado em atrasos inesperados na realização de modificações necessárias e na dificuldade em atingir os critérios de qualidade acordados para o projeto.

A DT normalmente é inserida em projetos de software quando se precisa optar entre manter o sistema nos padrões de qualidade ou colocá-lo para funcionar com o menor tempo possível utilizando o mínimo de recursos. Esses itens da DT provavelmente terão de ser pagos com juros mais tarde no desenvolvimento do projeto. O valor da dívida se refere ao trabalho que deixou de ser feito. Já o juro é o valor correspondente à quantidade de esforço extra necessário para eliminar a dívida (concluir a tarefa) devido à não conclusão dessas tarefas no momento em que surgiram. Por exemplo, ao codificar uma classe do projeto de forma inadequada, além de ajustar aquela classe (valor da dívida), pode ser necessário ajustar outras classes que se relacionam com ela e que sofreriam efeitos colaterais de uma alteração nela (juros da dívida).

Existem algumas iniciativas com objetivo de organizar diferentes tipos de DT. Por exemplo, Martin Fowler classificou as dívidas considerando as características: imprudente/ponderado e intencional/não intencional. Estas características compõem o que ele chamou de Technical Debt Quadrant e permitem classificar a dívida quanto ao fato dela ter sido inserida de forma intencional ou não e, para ambos os casos, se ela pode ser considerada o resultado de uma falta de cuidado ou foi inserida com cautela.

A metáfora da dívida técnica facilita o entendimento dos custos com refatoração de código provocada por decisões tomadas durante o ciclo de vida do software. Para este fim, utiliza termos financeiros no intuito de explicar que a “dívida” surge através de um “empréstimo”. Este “empréstimo” é obtido nas decisões envolvendo trocas nas quais é favorecido, por exemplo, o tempo de entrega do produto em detrimento da qualidade do código e das boas práticas em programação.

Os efeitos da Dívida Técnica se manifestam em problemas tanto durante a evolução do software, como ao longo de futuras manutenções. Eles dificultam a adição de novas funcionalidades, facilitam o surgimento de defeitos, impactam na qualidade externa e afetam também a arquitetura e código fonte. Assim, abrangem a possibilidade do surgimento de diversos tipos de problemas durante todo o ciclo de vida. Estes efeitos tanto podem ser percebidos externamente, como o surgimento de defeitos, como podem ser invisíveis, afetando apenas a arquitetura ou código do software. Estes efeitos invisíveis se manifestam na forma de problemas arquiteturais, estruturais, cobertura dos testes, alta complexidade de código, baixa qualidade interna, surgimento de code smells, dívida de documentação e a não conformidade com as boas práticas de programação. Por conta disto, acabam por afetar a manutenibilidade e evolutibilidade do software, podendo até inviabilizar a sua continuidade.

Existe atualmente um esforço para levantar possíveis abordagens com o objetivo de visualizar e gerenciar esta dívida. Tais abordagens tanto podem ser realizadas manualmente como automaticamente, através de ferramentas. Contudo, é recomendado contar com ambas as formas, pois revelam tipos distintos de dívida técnica.

Entre as abordagens automatizada ...