Integrating Structural and Semantic Analysis for Code Smell Refactoring Prediction

O software nunca está verdadeiramente terminado. Como uma cidade que cresce organicamente ao longo de décadas, um programa de computador acumula camadas de adições, patches e correções rápidas. Com o tempo, esse crescimento orgânico pode levar a fraquezas estruturais, muito parecido com um edifício onde um corredor foi alargado sem o reforço das paredes. No mundo da engenharia de software, essas falhas localizadas são conhecidas como "code smells" (cheiros de código). Eles não são erros que fazem um programa travar, mas sim sinais de um design pobre que torna o código difícil de entender, mudar ou manter. Quando os desenvolvedores detectam esses cheiros, eles frequentemente realizam o "refactoring" (refatoração), um processo cuidadoso de reorganização do código para melhorar sua estrutura sem alterar o que o software realmente faz. O desafio é que os desenvolvedores nem sempre corrigem cada cheiro que encontram, e prever quais serão corrigidos é difícil porque a decisão depende frequentemente da intenção humana e do contexto, não apenas do código em si.

Uma equipe de pesquisadores da Universidade de Milano-Bicocca decidiu investigar se as máquinas poderiam aprender a prever essas decisões humanas. Eles queriam saber se um computador poderia olhar para um trecho de código, identificar uma falha e adivinhar com precisão se um desenvolvedor eventualmente a limparia. Para fazer isso, construíram um sistema que combina duas formas diferentes de observar o código. A primeira é tradicional: contar propriedades como o comprimento de um método ou quantos variáveis ele utiliza. A segunda é mais moderna e complexa: transformar o código em um mapa de sua lógica e comportamento, e então traduzir esse mapa em uma representação matemática que um computador possa analisar em busca de padrões ocultos. Ao alimentar esses modelos com essa informação combinada, os pesquisadores testaram se os computadores poderiam aprender as regras sutis que guiam os desenvolvedores quando escolhem refatorar.

Os pesquisadores reuniram dados de 79 projetos Java de código aberto, uma coleção de software que foi desenvolvida e mantida por muitas pessoas ao longo do tempo. Eles utilizaram ferramentas automatizadas para escanear o histórico desses projetos, identificando milhares de instâncias onde "code smells" estavam presentes e rastreando quais deles foram posteriormente corrigidos através de ações específicas de refatoração, como renomear uma variável, extrair um método para uma peça menor ou alterar um parâmetro. Em seguida, criaram um conjunto de dados híbrido para cada trecho de código. Este conjunto de dados incluía medições padrão, como o número de linhas em um método, juntamente com dois tipos diferentes de "embeddings". Um tipo de embedding mapeava o fluxo de controle, mostrando a ordem em que as instruções são executadas. O outro, mais avançado, mapeava as relações semânticas mais profundas, capturando como os dados se movem pelo programa e como diferentes partes do código dependem umas das outras, criando efetivamente um retrato rico e multidimensional do comportamento do código.

Os resultados mostraram que os modelos de aprendizado de máquina são, de fato, capazes de prever a refatoração com um alto grau de confiabilidade. Quando os modelos foram testados em dez tipos diferentes de operações de refatoração, eles frequentemente alcançaram pontuações AUC bem acima de 0,70 e, para algumas tarefas, ultrapassaram 0,80. Isso sugere que existem, de fato, padrões detectáveis no código que sinalizam a intenção de um desenvolvedor de limpá-lo. No entanto, o estudo revelou uma nuance crucial: nem todos os "code smells" são criados da mesma forma. Os modelos foram excepcionalmente bons em prever mudanças estruturais, como adicionar um parâmetro a um método ou alterar o tipo de uma variável. Essas ações são frequentemente impulsionadas por fatores claros e mensuráveis, como o comprimento de uma instrução ou a complexidade de um cálculo. Em contrapartida, os modelos tiveram dificuldade em prever mudanças conceituais, como renomear um método. Renomear é uma decisão muitas vezes subjetiva, baseada em como um desenvolvedor pensa sobre o propósito do código, um fator que é difícil de capturar apenas com números ou mapas estruturais.

Talvez a descoberta mais significativa tenha sido relativa ao tipo de representação de dados utilizado. Os pesquisadores esperavam inicialmente que simplesmente adicionar mapas mais complexos do fluxo de execução do código melhoraria as previsões. Em vez disso, descobriram que um tipo específico de mapa de fluxo, que rastreava a ordem das instruções, na verdade introduzia ruído que confundia os modelos. Quando esse mapa de fluxo era combinado com as medições tradicionais, ele frequentemente piorava as previsões, pois o computador tinha dificuldade em ignorar os detalhes irrelevantes. No entanto, quando os pesquisadores mudaram para a representação mais avançada, que combinava dependências estruturais com o texto e a lógica reais do código, os resultados mudaram drasticamente. Essa representação mais rica forneceu um sinal complementar que os modelos puderam usar de forma eficaz. De fato, para algumas tarefas, os modelos treinados apenas com essa representação avançada tiveram um desempenho quase tão bom quanto aqueles treinados com o conjunto de dados completo, provando que a compreensão profunda da estrutura e da semântica do código era um preditor poderoso por si só.

O estudo também destacou os limites do que pode ser previsto apenas a partir do código. Embora os modelos pudessem prever de forma confiável correções técnicas impulsionadas pela complexidade, eles não consegravam prever facilmente as decisões humanas por trás da renomeação ou reorganização do código para fins de clareza. Isso sugere que, embora as máquinas possam ser excelentes em identificar quando um software está tecnicamente necessitado de manutenção, a decisão final de refatorar depende frequentemente da visão e do contexto de um desenvolvedor que existem fora do próprio código. A pesquisa conclui que o futuro da manutenção automatizada de software não reside em substituir o julgamento humano, mas em usar essas ferramentas preditivas para destacar as dívidas estruturais que são mais urgentes, permitindo que os desenvolvedores foquem seu tempo limitado nas mudanças que mais importam. Ao compreender quais sinais são fortes e quais são ruídos, podemos construir melhores ferramentas para manter nossa infraestrutura digital saudável e sustentável.