Artigos Canal Mais Monitoramento da Dívida Técnica através da visualização de God Class
Por que eu devo ler este artigo:O controle da dívida técnica é essencial na melhoria da qualidade do software, porém a identificação desta dívida é complexa. Para facilitar este levantamento, abordagens automatizadas têm sido criadas. Um dos propósitos destas ferramentas é a detecção de code smells, que são anomalias presentes no código fonte do software. Este artigo apresenta GodVis, uma ferramenta para visualização da God Class, que é um tipo relevante de code smell na detecção de problemas de design. Os resultados da utilização da GodVis na análise do projeto Struts 2 serão apresentados.
Autores: Victor Wanderley Shyba, Nicolli Souza Rios Alves e Rodrigo Oliveira Spínola

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).

Conheça os cursos de Engenharia de Software que a DevMedia possui para assinantes MVP.

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 ...

Quer ler esse conteúdo completo? Tenha acesso completo