Resumo Técnico: Da Lógica Customizada às APIs: Compreendendo e Recomendando Refatorações de Substituição de API

1. Declaração do Problema

A refatoração de software é crítica para manter a qualidade do código, mas a refatoração de substituição de API — a prática de substituir lógica customizada verbosa e escrita à mão por chamadas semanticamente equivalentes a bibliotecas padrão ou de terceiros — permanece subexplorada. Desenvolvedores frequentemente implementam soluções artesanais para tarefas comuns (por exemplo, verificações manuais de nulidade, iteração explícita de coleções ou asserções verbosas) que replicam a funcionalidade de bibliotecas existentes. Isso leva ao aumento do esforço de manutenção, redução da legibilidade e dívida técnica.

Ferramentas e abordagens existentes enfrentam limitações significativas na detecção dessas oportunidades:

• Métodos baseados em templates (ex: RETIWA) dependem de padrões predefinidos e têm dificuldade com equivalências semânticas complexas de múltiplos comandos ou substituições dependentes de contexto.
• Refatorações estruturais frequentemente perdem casos onde a lógica se estende por múltiplos comandos ou classes distintas.
• Abordagens puramente baseadas em regras falham em capturar a alta variabilidade sintática e a equivalência semântica necessária para identificar quando uma lógica customizada pode ser consolidada em uma única chamada de API.

Consequentemente, há uma falta de compreensão empírica sobre a prevalência, características e viabilidade de automação das refatorações de substituição de API em projetos reais.

2. Metodologia

Os autores propõem um pipeline procedural de três fases para investigar a frequência, as características e a detectabilidade das refatorações de substituição de API.

Fase I: Mineração Empírica e Validação

• Coleta de Dados: O estudo minerou 166.299 commits de seis projetos Java de código aberto diversos e maduros (Guava, Spring Framework, Commons Lang, Struts, Elasticsearch e Ant).
• Estratégia de Seleção: Um filtro baseado em palavras-chave (ex: "refactoring", "replace", "cleanup") identificou 16.677 commits candidatos.
• Análise Manual: Uma amostra estatisticamente representativa de 1.800 commits foi inspecionada manualmente por dois autores experientes.
• Verdade de Campo (Ground Truth): Este processo gerou 366 instâncias validadas de substituição de API. A validação exigiu que a transformação removesse/simplificasse a lógica customizada, introduzisse uma API de biblioteca semanticamente equivalente e preservasse o comportamento observável (verificado via testes unitários/integração). A confiabilidade inter-avaliador foi alta (Kappa de Cohen = 0,87).

Fase II: Síntese de Características e Análise Determinística

Para responder ao que características caracterizam essas refatorações, os autores construíram um conjunto de dados balanceado de 732 trechos de código (366 positivos, 366 negativos).

• Extração de Características: Um pipeline automatizado extraiu 36 características em três dimensões:
  • Estrutural: Construtos de fluxo de controle (verificações de nulidade, retornos antecipados).
  • Semântica: Padrões de operação baseados em AST e expressões de múltiplos passos.
  • Tipo-Contexto: Tipos de dados envolvidos (ex: String, List).
• Indução de Regras: Um classificador de Árvore de Decisão foi treinado nessas características. Caminhos de alta confiança foram traduzidos em 8 heurísticas determinísticas (ex: identificar lógica guardada consolidada em APIs de segurança de nulidade).

Fase III: Estrutura de Recomendação Híbrida (AKIRA)

Para abordar as limitações de abordagens puramente baseadas em regras ou puramente baseadas em LLM, os autores propõem o AKIRA (Adaptive Knowledge Discovery and Retrieval), uma estrutura híbrida:

• Nível 1 (Heurísticas Determinísticas): Aplica as 8 regras induzidas para detectar padrões frequentes e estruturalmente bem definidos (ex: APIs de asserção ou de segurança de nulidade) com alta precisão.
• Nível 2 (Adaptive Knowledge Discovery and Retrieval - AKDR-L): Lida com casos complexos e dependentes de contexto usando uma arquitetura de quatro camadas:
  1. Camada Empírica: Rollback temporal e amostragem adaptativa de commits de biblioteca para construir uma base de conhecimento.
  2. Camada Agêntica: Utiliza Tree-Sitter e LLMs (GPT-4o) para sintetizar tuplas de conhecimento estruturado (propósito funcional, padrões, tipo de código, contexto da biblioteca).
  3. Camada Relacional: Constrói um Grafo de Conhecimento multi-biblioteca onde os nós são conectados com base em estratégias de substituição de API compartilhadas, em vez de similaridade textual.
  4. Camada de Inferência: Realiza expansão de consulta consciente da biblioteca e limiarização adaptativa (ajustando a sensibilidade com base no tipo de código, ex: teste vs. produção) para recuperar e classificar recomendações.

3. Principais Contribuições

1. Primeiro Estudo Empírico: Uma análise sistemática de refatorações de substituição de API em projetos Java do mundo real, quantificando sua frequência (8,4% dos commits de refatoração amostrados) e caracterizando seu escopo.
2. Caracterização de Características: Identificação de sinais chave, incluindo:
   • Domínios Funcionais: Dominância de APIs de asserção (42,62%) e APIs específicas de framework (39,34%).
   • Granularidade: Primariamente ao nível de instrução (62,6%) ou blocos de múltiplas instruções (36,1%), impulsionados pela consolidação semântica em vez de simplificação sintática.
   • Motivações: Melhorar a clareza, adotar estilos declarativos e padronização.
3. Estrutura AKIRA: Um sistema de recomendação híbrido que integra heurísticas determinísticas com uma camada de recuperação adaptativa baseada em conhecimento. Ele combina de forma única o pareamento de padrões estáticos com o raciocínio semântico para detectar substituições complexas sem templates predefinidos.
4. Benchmarking: Uma avaliação rigorosa contra baselines (Heurísticas Determinísticas, ChatGPT-4o, RETIWA) tanto em conjuntos de dados internos retidos quanto no conjunto de dados externo RETIWA.

4. Resultados

A avaliação demonstra que o AKIRA supera significativamente as abordagens existentes:

• No Conjunto de Dados Curado Manualmente (Interno):

  • AKIRA: 90% de Recall, 88% de Precisão.
  • Heurísticas Determinísticas: 24% de Recall, 67% de Precisão (alta precisão, mas perde casos complexos).
  • AKDR-L (Apenas Nível 2): 86% de Recall, 67% de Precisão.
  • ChatGPT-4o (Vanilla): 31% de Recall, 58% de Precisão.
  • RETIWA: 3% de Recall (falha em dados de nível de trecho sem histórico).

• No Conjunto de Dados Externo RETIWA:

  • AKIRA: 81% de Recall, 78% de Precisão.
  • Melhoria sobre o Estado da Arte: Aumenta o recall de 21% (RETIWA) para 81% e a precisão de 40% para 78%.

• Estudo de Ablação: Remover o componente de Classificação Adaptativa fez com que a especificidade colapsasse para 4% (100% de recall, mas com massa de falsos positivos), destacando seu papel crítico em equilibrar precisão e recall.

5. Significância e Alegações

O artigo afirma que a substituição de API é uma prática substancial, porém pouco automatizada, na evolução de software. Os autores afirmam que:

• A Hibridização é Essencial: Abordagens puramente baseadas em regras não conseguem capturar a diversidade semântica de substituições de frameworks ou de múltiplas instruções, enquanto LLMs isolados carecem da precisão e consciência de contexto necessárias para uma refatoração confiável.
• O Contexto Importa: O sucesso do AKIRA depende de mecanismos adaptativos (ex: ajustando limiares para código de teste vs. lógica de produção) e grafos de conhecimento conscientes da biblioteca.
• Viabilidade Prática: A estrutura identifica com sucesso oportunidades que melhoram a manutenibilidade do código e se alinham com as práticas modernas de desenvolvimento, alcançando alta precisão na detecção de lógica customizada que pode ser substituída por APIs testadas.

Os autores mantêm uma postura modesta, reconhecendo que suas descobertas são baseadas em projetos Java de código aberto e podem não se generalizar totalmente para bases de código proprietárias. Eles observam que o raciocínio interprocedural e as substituições compostas que abrangem acessores específicos do projeto permanecem como fronteiras desafiadoras para trabalhos futuros.