Refactoring for Novices in Java: An Eye Tracking Study on the Extract vs. Inline Methods

Este estudo com rastreamento ocular em 32 novatos de Java revela que, embora a extração de métodos seja geralmente preferida para legibilidade, ela pode prejudicar o desempenho e aumentar o esforço cognitivo em tarefas simples, enquanto melhora significativamente a eficiência em tarefas mais complexas, sugerindo cautela na modularização prematura para iniciantes.

O essencial

Imagine que você está ensinando uma criança a cozinhar. Você tem duas opções para explicar como fazer um bolo:

1. Opção A (Método "Inline" ou "Em Linha"): Você escreve todo o passo a passo na mesma folha de papel, do início ao fim, sem parar. "Pegue a farinha, misture com o ovo, adicione o leite, bata, coloque no forno..." Tudo em um único bloco de texto.
2. Opção B (Método "Extract" ou "Extraído"): Você divide a receita. Na folha principal, você escreve apenas: "Faça a massa do bolo". E em outra folha separada, você escreve os detalhes de como fazer essa massa.

A grande pergunta que os pesquisadores deste estudo queriam responder é: Qual dessas duas formas é mais fácil para um iniciante (um "novato") entender e seguir?

A maioria dos programadores experientes diria: "Claro que a Opção B é melhor! É mais organizada, fácil de reutilizar e o nome 'Faça a massa' já diz tudo o que vai acontecer." É como ter um índice em um livro.

Mas será que isso funciona para quem está começando agora?

O Experimento: Olhos no Código

Os autores do estudo (pesquisadores do Brasil) decidiram não confiar apenas no que os novatos diziam, mas no que seus olhos faziam. Eles usaram uma tecnologia chamada rastreamento ocular (eye tracking).

Imagine que cada vez que seus olhos param em uma palavra para ler, é como se você pisasse em um ponto no chão. Se você precisa voltar e reler algo, é como dar um passo para trás.

• Poucos passos para trás: Você entendeu de primeira, o fluxo é linear.
• Muitos passos para trás: Você está confuso, precisando checar o que estava escrito antes, ou pulando de um lugar para o outro para conectar as ideias.

Eles pediram para 32 estudantes iniciantes de Java resolverem 8 problemas simples de programação. Metade dos problemas estava na "Opção A" (tudo junto) e a outra metade na "Opção B" (dividido em funções com nomes bonitos).

O Que Eles Descobriram? (A Surpresa)

O resultado foi uma mistura de "sim" e "não", dependendo da dificuldade da tarefa.

1. Para tarefas complexas (Ex: Calcular Fatorial)

Imagine tentar decorar uma lista de compras longa e complicada.

• O que aconteceu: Quando o código estava dividido (Opção B), os alunos foram mais rápidos e fizeram menos "passos para trás" (menos confusão).
• Por que: O nome da função (ex: "Calcular Fatorial") funcionou como um farol. O aluno podia olhar para o nome, entender a ideia geral, e só depois se preocupar com os detalhes. A divisão ajudou a organizar o caos na cabeça deles.

2. Para tarefas muito simples (Ex: Calcular a área de um quadrado)

Imagine uma tarefa tão simples quanto "multiplicar 10 por 10".

• O que aconteceu: Quando o código estava dividido (Opção B), os alunos ficaram mais lentos e fizeram muitos mais "passos para trás".
• Por que: Aqui, a divisão atrapalhou! O aluno tinha que ler "Calcular Área", pular para outra parte do código para ver como é feito, e voltar. Para uma tarefa que caberia em uma linha, criar um "passo extra" (ir até a outra folha) foi como ter que andar até a cozinha só para pegar o sal, quando você já estava com ele na mão. A "organização" virou um obstáculo.

A Lição Principal: O "Nome Bonito" não é Mágica

Um dos pontos mais importantes do estudo é sobre os nomes das funções.
Na programação, damos nomes descritivos para ajudar a entender o código (chamados de "balizas" ou beacons). A teoria dizia que, se o nome for bom, o novato entende rápido.

O estudo mostrou que isso não é verdade para iniciantes em tarefas simples. Mesmo com um nome perfeito como "Calcular Área", o novato ainda precisava ir até a definição da função para ter certeza do que estava acontecendo. Eles não confiam apenas no nome; eles precisam ver a "mágica" acontecendo.

Isso cria um efeito de "vai e volta" constante nos olhos deles, cansando a mente e gastando mais tempo.

Analogia Final: O Mapa vs. A Estrada

• Código "Inline" (Tudo junto): É como andar em uma estrada reta e curta. Você vê o destino e chega lá sem desvios. Para distâncias curtas, é o caminho mais rápido.
• Código "Extraído" (Dividido): É como ter um mapa com um índice. Para uma viagem longa e cheia de curvas (código complexo), o mapa é essencial para não se perder. Mas, se você só quer ir da sala para a cozinha (código simples), parar para consultar o mapa só vai te atrasar.

Conclusão para Professores e Alunos

O estudo sugere que, ao ensinar programação para iniciantes:

1. Não divida tudo de imediato. Para tarefas muito simples, manter o código junto pode ser mais fácil de entender.
2. A divisão só ajuda quando a complexidade aumenta. Quando o código fica grande e confuso, aí sim, separar em funções com bons nomes ajuda a organizar a mente.
3. O que parece "bonito" e "organizado" para um expert pode ser confuso para um iniciante. Às vezes, a simplicidade de ver tudo em um só lugar vale mais do que a organização teórica.

Em resumo: A melhor forma de escrever código depende do tamanho do problema. Para iniciantes, nem sempre "mais organizado" significa "mais fácil de entender".

Resumo técnico

Aqui está um resumo técnico detalhado do artigo "Refactoring for Novices in Java: An Eye Tracking Study on the Extract vs. Inline Methods", apresentado em português:

1. Problema e Motivação

O estudo investiga o impacto das práticas de refatoração Extract Method (Extrair Método) e Inline Method (Método em Linha) na compreensão de código por programadores novatos em Java.

• Contexto: Embora a extração de métodos seja uma prática comum para melhorar a legibilidade e reutilização, e o inline seja usado para eliminar abstrações desnecessárias, estudos anteriores baseados em métricas estáticas não encontraram diferenças claras entre eles.
• Lacuna: A "fator humano" e o esforço cognitivo/visual durante a navegação no código permanecem pouco explorados. Métricas tradicionais (como tempo de execução) podem não capturar o custo dinâmico da navegação visual (ex: voltar e reler trechos de código).
• Hipótese Central: A presença de nomes significativos (faróis ou beacons) em métodos extraídos nem sempre melhora a compreensão para novatos, podendo, em alguns casos, interromper o raciocínio linear e aumentar o esforço visual.

2. Metodologia

Os autores conduziram um experimento controlado combinado com uma pesquisa qualitativa e quantitativa.

• Participantes:
  • Experimento Controlado: 32 estudantes universitários (novatos em Java, com média de 12 meses de experiência na linguagem).
  • Pesquisa Online: 58 novatos adicionais para validar preferências e motivações.
• Tarefas: 8 tarefas de programação simples (ex: calcular fatorial, área de quadrado, verificar paridade, encontrar maior nota). Para cada tarefa, foram criadas duas versões funcionalmente equivalentes: uma com o método em linha (código contido no main) e outra com o método extraído (código encapsulado em uma função separada com nome descritivo).
• Tecnologia de Rastreamento: Uso de um Eye Tracker (Tobii Eye Tracker 4C) a 90 Hz para monitorar o movimento ocular dos participantes enquanto liam o código.
• Métricas Coletadas:
  • Desempenho: Tempo total de tarefa, número de tentativas até a resposta correta.
  • Esforço Visual (Eye Tracking): Duração das fixações, contagem de fixações, contagem de regressões (movimentos oculares de volta para trechos já lidos, indicando confusão ou re-leitura).
  • Áreas de Interesse (AOI): Regiões específicas do código onde a lógica foi alterada (chamada do método vs. corpo do método).
• Análise Qualitativa: Entrevistas pós-tarefa com os 32 participantes e análise de dados da pesquisa online usando a Teoria Fundamentada (Grounded Theory) para identificar padrões de dificuldade e preferências.

3. Principais Contribuições

1. Abordagem Dinâmica: É um dos primeiros estudos a utilizar rastreamento ocular para avaliar especificamente o impacto das refatorações Extract vs. Inline em novatos.
2. Descoberta de Discrepância: Revela uma lacuna entre a percepção dos novatos (que geralmente preferem métodos extraídos por parecerem mais organizados) e o seu desempenho real (que varia drasticamente dependendo da complexidade da tarefa).
3. Validação de Métricas Visuais: Demonstra que métricas de rastreamento ocular (especialmente regressões) capturam custos cognitivos que métricas estáticas ou apenas o tempo total de tarefa não revelam.
4. Modelo Integrativo: Propõe uma teoria sobre como características da tarefa, representação do código e mecanismos cognitivos interagem para determinar a compreensão.

4. Resultados Chave

Os resultados mostraram que o impacto da refatoração é dependente do contexto da tarefa:

• Tarefas Complexas (ex: Fatorial, Maior Nota):

  • A versão com Método Extraído foi superior.
  • Reduções significativas: O tempo de tarefa caiu até 78,8%, e as regressões visuais caíram até 84,6%.
  • Motivo: O nome do método atuou como um "farol" (beacon), permitindo que os novatos compreendessem a intenção de alto nível sem precisar rastrear cada linha da lógica complexa, reduzindo a carga cognitiva.

• Tarefas Simples (ex: Área de Quadrado, Verificar Par):

  • A versão com Método em Linha (Inline) foi superior.
  • Aumento negativo: O tempo de tarefa aumentou até 166,9% e as regressões até 200% na versão extraída.
  • Motivo: Para lógicas triviais (uma única linha), a extração forçou os novatos a fazerem transições visuais desnecessárias entre a chamada e o corpo do método, interrompendo o fluxo de leitura linear. Os novatos não conseguiram usar o nome do método como atalho eficiente e acabaram verificando o corpo do método repetidamente.

• Preferência vs. Desempenho:

  • Na pesquisa, a maioria dos novatos preferiu a versão extraída por "legibilidade" e "reutilização".
  • No entanto, em tarefas simples, essa preferência não se traduziu em melhor desempenho; na verdade, a modularização prematura aumentou o esforço visual.

5. Significado e Implicações

• Para Educadores: O estudo alerta contra a aplicação cega de boas práticas de modularização (como extrair métodos) em tarefas introdutórias muito simples. Isso pode sobrecarregar cognitivamente os novatos. A escolha entre inline e extract deve considerar a complexidade intrínseca da lógica.
• Para Pesquisadores: Destaca a importância de usar métricas dinâmicas (como rastreamento ocular) para avaliar refatorações, pois métricas estáticas podem mascarar o custo real de navegação e compreensão.
• Para a Indústria: Sugere que ferramentas de refatoração automatizada devem ser contextuais, evitando extrair métodos para lógicas triviais que podem prejudicar a clareza para desenvolvedores menos experientes.

Em resumo, o artigo conclui que nomes significativos de métodos não são uma solução universal para melhorar a compreensão de código por novatos. O benefício da extração depende criticamente da complexidade da tarefa: é benéfico para lógica complexa, mas prejudicial para lógica trivial devido ao custo de navegação visual.