Analyzing Dependency Distribution Changes Arising from Code Smell Interactions

Este estudo analisa 116 sistemas Java de código aberto e conclui que as interações entre más odes (code smells) estão associadas a um aumento significativo nas dependências estáticas, fornecendo insights valiosos para melhorar a detecção, priorização e estratégias de refatoração de problemas de qualidade de código.

O essencial

Imagine que um software é como uma cidade gigante. Cada prédio dessa cidade é um "módulo" de código, e as ruas que ligam esses prédios são as dependências.

Quando você precisa reformar uma janela em um prédio, se houver muitas ruas conectando esse prédio a outros, você pode causar um efeito cascata: o trânsito para, a luz apaga em prédios vizinhos e a reforma fica cara e complicada. Isso é o que os programadores chamam de "manutenção complexa".

Agora, imagine que alguns prédios têm defeitos de construção (o que os programadores chamam de "Code Smells" ou "Cheiros de Código").

• Um prédio que guarda todos os móveis da cidade (God Class).
• Um cômodo que tenta fazer tudo sozinho, ficando enorme e confuso (Brain Method).
• Um prédio que só guarda caixas de ferramentas sem saber usá-las (Data Class).

O que este estudo descobriu é fascinante: quando dois prédios com defeitos se conectam, o problema não é apenas a soma dos defeitos, mas uma explosão de novas ruas.

Aqui está a explicação simples do que os pesquisadores (Zushuai Zhang, Elliott Wen e Ewan Tempero) fizeram e descobriram:

1. O Grande Experimento (A Cidade de 116 Bairros)

Os pesquisadores pegaram 116 cidades de código (projetos de software reais e famosos) e analisaram como os prédios defeituosos se relacionavam. Eles queriam saber: "Se um prédio com defeito A se conecta a um prédio com defeito B, o número de ruas entre eles aumenta?"

2. A Descoberta Principal: O Efeito Cascata

A resposta foi um "SIM" estrondoso.
Quando dois "prédios com defeito" interagem, eles criam muito mais conexões do que quando um prédio com defeito se conecta a um prédio normal.

• Analogia: Pense em dois vizinhos que são um pouco bagunçados. Se eles forem amigos normais, talvez se ajudem de vez em quando. Mas se ambos forem bagunçados, eles começam a pedir emprestado, devolver, trocar coisas, fazer barulho e criar uma rede de obrigações tão grande que o bairro inteiro fica sobrecarregado.
• O Resultado: Em 28 de 36 casos analisados, a presença de dois "cheiros" juntos aumentou drasticamente o número de dependências. Isso torna o software muito mais difícil de consertar.

3. A Direção do Problema (Quem Puxa Quem?)

O estudo não contou apenas o número de ruas, mas também quem puxa quem. Eles descobriram padrões consistentes:

• Alguns tipos de defeitos tendem a puxar muitos dados de outros prédios (como um "Vampiro de Dados").
• Outros tendem a oferecer muitas funcionalidades (como um "Fornecedor Exausto").
• Quando esses tipos específicos se encontram, o fluxo de informações fica desequilibrado e caótico.

Exemplo Prático do Papel:
Imagine um "Data Class" (um prédio que só guarda móveis) e um "Feature Envy" (um cômodo que inveja os móveis do vizinho).

• O "invejoso" começa a puxar todas as caixas do "guardador" para dentro da sua própria casa.
• Isso cria uma rua gigante e perigosa entre eles.
• A Solução: Em vez de tentar consertar o cômodo sozinho, a melhor reforma é mover o cômodo para dentro da casa do vizinho. Assim, ele não precisa mais "puxar" as coisas de fora; as coisas já estão lá dentro. O estudo sugere que identificar esses pares ajuda a saber exatamente como reformar.

4. Por que isso importa para você?

Mesmo que você não seja programador, a lição é sobre organização e complexidade:

1. Não olhe apenas para o problema isolado: Se você tem um problema em um projeto, não olhe apenas para ele. Olhe para quem ele está conectado. Se o vizinho também tem problemas, a solução é mais urgente.
2. Agrupamento de defeitos é perigoso: Dois pequenos erros que se conectam podem criar um caos maior do que um erro gigante isolado.
3. Reformas inteligentes: Saber como os defeitos se conectam ajuda a planejar a reforma. Em vez de apenas "consertar o telhado", você pode "mudar a planta da casa" para que as conexões perigosas desapareçam.

Resumo em uma frase

Este estudo provou que dois erros de design que se conectam criam uma rede de dependências muito mais densa e perigosa do que a soma de dois erros separados, e entender essa conexão é a chave para consertar o software de forma mais rápida e eficiente.

Os pesquisadores criaram um "mapa de tráfego" desses defeitos para ajudar os programadores a priorizar quais problemas resolver primeiro e como fazer a melhor reforma possível.

Resumo técnico

Resumo Técnico: Análise de Mudanças na Distribuição de Dependências Decorrentes de Interações de Code Smells

1. Problema e Motivação

A manutenibilidade do software é frequentemente comprometida por dependências excessivas entre módulos, que podem desencadear efeitos de "ripple" (ondas) quando alterações são feitas, tornando a manutenção complexa e custosa. Embora os code smells (maus cheiros de código) sejam amplamente reconhecidos como sintomas de problemas de design que degradam a qualidade, a maioria dos estudos foca em smells isolados.

O problema central abordado neste trabalho é que, na prática, múltiplos code smells raramente ocorrem isoladamente; eles frequentemente co-ocorrem e interagem através de dependências estáticas. A literatura existente sugere que essas interações podem ter um impacto mais severo na manutenibilidade do que os smells individuais, mas há uma lacuna empírica sobre como essas interações alteram a distribuição e o volume de dependências estáticas no código. O estudo busca preencher essa lacuna, investigando se e como a presença de interações entre code smells modifica a estrutura de dependências.

2. Metodologia

Os autores realizaram uma análise empírica em larga escala seguindo os seguintes passos:

• Conjunto de Dados: Foram selecionados 116 projetos Java de código aberto do GitHub (top-starred), variando em tamanho e domínio.
• Code Smells Analisados: O estudo focou em cinco smells comuns e bem definidos:
  • Feature Envy (FE)
  • Brain Method (BM)
  • God Class (GC)
  • Brain Class (BC)
  • Data Class (DC)
• Definição de Interação: Uma interação é definida quando dois artefatos (classes, métodos, campos) exibindo smells diferentes possuem uma dependência estática direta entre eles.
• Detecção e Extração:
  • Utilizou-se a ferramenta CodeQL para análise estática.
  • Os smells foram detectados usando a abordagem baseada em métricas proposta por Lanza e Marinescu.
  • Foram extraídos todos os tipos de dependências estáticas (chamadas, criação, uso de campos, etc.) e categorizados por direção (fonte $\to$ alvo) e tipo de artefato.
• Análise Estatística:
  • Comparou-se o número de dependências em pares de artefatos onde a interação de smell existe (CS1-CS2) versus casos onde não existe (CS1-nonCS2 ou nonCS1-CS2).
  • Foram aplicados testes não paramétricos (Teste U de Mann-Whitney) para avaliar a significância estatística e o Cliff's Delta ($\delta$) para medir o tamanho do efeito (magnitude da mudança).
  • A análise foi feita em dois níveis: no conjunto unificado de dados (Union dataset) e individualmente por sistema (Per-system).

3. Principais Contribuições

1. Primeira Evidência Empírica em Larga Escala: O estudo fornece a primeira evidência quantitativa robusta de que interações entre code smells estão associadas a um aumento significativo no número total de dependências estáticas.
2. Tipologia de Interação: Propõe uma tipologia multidimensional baseada no tipo de dependência (chamada de método funcional vs. acesso a dados) e no papel do artefato (provedor vs. consumidor), classificando os smells como "fortes" ou "fracos" nessas interações.
3. Direção Consistente de Mudança: Demonstra que, para pares específicos de smells, a direção da mudança nas dependências (aumento ou diminuição) é consistente, independentemente do sistema analisado.
4. Repositório de Replicação: Todo o código-fonte, dados brutos, scripts de análise e instruções de replicação foram disponibilizados publicamente.

4. Resultados Chave

• Frequência de Interação (RQ1):

  • A maioria dos pares de code smells interage com frequência. Cerca de 50% dos pares analisados apresentam uma taxa de interação superior a 40%.
  • A interação mais alta ocorre entre Brain Class (BC) e Brain Method (BM) (99,7%), devido à definição hierárquica de que uma BC contém BMs.
  • Interações entre smells de nível de método (BM e FE) são menos frequentes (cerca de 7-8%), pois ambos consomem dados sem fornecê-los, dificultando a interação via chamadas.

• Impacto na Distribuição de Dependências (RQ2):

  • Aumento Global: Em 28 de 36 casos analisados, a presença de interações de smells está associada a um aumento estatisticamente significativo no número total de dependências.
  • Tipos Específicos: As mudanças mais pronunciadas ocorrem em dependências de acesso a dados (uso de campos e chamadas de acessores) e chamadas de métodos funcionais (FM calls).
  • Consistência: Para um par de smells e uma direção de fluxo específica (ex: GC $\to$ DC), a maioria dos projetos exibe a mesma direção de mudança (aumento ou diminuição).
  • Exemplo de Padrão: O Data Class (DC) tende a aumentar as dependências de acesso a dados quando interage com Feature Envy (FE), pois o FE consome os dados do DC.

• Análise por Sistema: Embora a magnitude da mudança varie entre projetos, a direção da tendência (aumento ou diminuição) geralmente se alinha com os resultados do conjunto unificado.

5. Significado e Implicações Práticas

Os resultados oferecem insights acionáveis para desenvolvedores e pesquisadores:

• Priorização de Refatoração: Smells que interagem devem ser priorizados em relação aos que ocorrem isoladamente, pois geram estruturas de dependência mais densas e complexas, aumentando o risco de defeitos e o custo de manutenção.
• Estratégias de Refatoração Guiadas por Interação:
  • O estudo sugere estratégias específicas baseadas na tipologia. Por exemplo, se um Feature Envy (FE) interage fortemente com um Data Class (DC) através de muitas chamadas de dados, a estratégia recomendada é mover o método FE para dentro da classe DC, transformando o DC em uma classe mais rica em comportamento.
  • Para interações entre classes complexas (GC e BC), a extração de uma classe compartilhada que encapsule as responsabilidades entrelaçadas pode ser mais eficaz do que refatorar as classes separadamente.
• Melhoria na Detecção de Smells: A tipologia desenvolvida pode ser usada para inferir a presença de um smell não detectado com base nas interações observadas. Se um artefato confirmado (ex: GC) interage com um artefato desconhecido de forma que a direção da dependência sugere um "consumidor fraco" de funcionalidade, isso pode ser um indicador de que o artefato desconhecido é um Feature Envy.
• Design de Ferramentas: Desenvolvedores de ferramentas de análise estática podem usar esses padrões para melhorar a precisão da detecção e a priorização de alertas, focando em interações que geram maior acoplamento estrutural.

Conclusão

O estudo conclui que as interações entre code smells não são apenas uma co-ocorrência aleatória, mas um fenômeno estrutural que altera significativamente a topologia de dependências do software. Ignorar essas interações pode levar a estratégias de refatoração ineficazes. A compreensão de como esses smells se conectam e influenciam o crescimento de dependências é crucial para melhorar a modularidade e a manutenibilidade de sistemas de software modernos.