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

Este estudio de seguimiento ocular con 32 novatos en Java revela que, aunque la extracción de métodos mejora el rendimiento en tareas complejas, puede perjudicar el desempeño y aumentar la carga cognitiva en tareas simples debido a la navegación excesiva, lo que sugiere precaución al modularizar código para principiantes.

Lo esencial

¡Claro que sí! Imagina que este estudio es como una investigación sobre cómo aprendemos a leer un mapa cuando estamos aprendiendo a conducir.

Aquí tienes la explicación de este estudio científico, traducida a un lenguaje sencillo y con analogías divertidas:

🕵️‍♂️ La Gran Pregunta: ¿Es mejor tener un "Libro de Recetas" o todo en la "Encimera"?

Los programadores a menudo tienen que decidir cómo escribir su código. Tienen dos opciones principales para organizar una tarea:

1. El método "Inline" (Todo en la encimera): Imagina que estás haciendo un pastel. En lugar de escribir "Batir huevos" en una tarjeta aparte, escribes todo el proceso directamente en la receta: "Toma 3 huevos, córtalos, mézclalos con harina...". Todo está en un solo bloque, uno tras otro.
2. El método "Extract" (El Libro de Recetas): Escribes "Batir huevos" en una tarjeta separada con un nombre claro. Luego, en tu receta principal, solo pones la tarjeta que dice "Batir huevos". Si alguien quiere saber cómo se baten, va a buscar esa tarjeta.

La teoría tradicional decía: "¡El Libro de Recetas es mejor! Es más ordenado, más limpio y más fácil de entender porque tienes nombres claros".

Pero los investigadores se preguntaron: ¿Es esto verdad para los novatos (principiantes)? ¿O quizás, para alguien que está aprendiendo, tener que saltar de la receta a la tarjeta y volver hace que se maree?

👁️ El Experimento: Los Ojos no Mienten

Para responder esto, los científicos no solo preguntaron a los estudiantes qué pensaban. ¡Usaron gafas de realidad virtual (o rastreadores oculares) para ver exactamente hacia dónde miraban sus ojos mientras leían el código.

• La analogía: Imagina que eres un detective. Si lees un texto y te detienes mucho en una palabra, o si tienes que volver atrás a releer una frase porque no entendiste, eso significa que tu cerebro está trabajando duro.
• Lo que midieron:
  • Tiempo: ¿Cuánto tardaron?
  • Saltos (Regressions): ¿Cuántas veces tuvieron que volver atrás con la mirada? (Como cuando lees una frase y dices: "Espera, ¿qué dijo antes?").
  • Fijaciones: ¿En qué puntos se detuvieron a mirar fijamente?

🎭 Los Resultados: ¡La Sorpresa!

El estudio involucró a 32 estudiantes novatos en Java. Y aquí es donde la historia se pone interesante, porque la respuesta depende de qué tan difícil sea la tarea.

1. Cuando la tarea es COMPLEJA (ej. Calcular un factorial o encontrar el número primo más cercano)

• Lo que pasó: El "Libro de Recetas" (Método Extraído) funcionó genial.
• Por qué: La tarea era tan larga y confusa que tener un nombre claro como "Calcular Factorial" actuó como un farolillo o una señal de tráfico. Los estudiantes podían confiar en el nombre y saltar directamente a la parte importante sin perderse en los detalles.
• Resultado: Tardaron menos, miraron menos atrás y entendieron mejor.

2. Cuando la tarea es MUY SENCILLA (ej. Calcular el área de un cuadrado o sumar dos números)

• Lo que pasó: El "Libro de Recetas" fue un desastre.
• Por qué: Imagina que tienes que calcular 5 x 5. Es algo que sabes en un segundo. Si el código te dice "Llama a la función 'CalcularÁrea'", tienes que:
  1. Leer la llamada.
  2. Saltar a otra parte de la pantalla para ver qué hace esa función.
  3. Saltar de vuelta.
• El efecto: Esto rompe el flujo. Es como si estuvieras comiendo una manzana y, en lugar de morderla, tuvieras que ir a la cocina, buscar el cuchillo, cortar la manzana y volver a la mesa. ¡Es un esfuerzo innecesario!
• Resultado: Los estudiantes tardaron hasta un 166% más y tuvieron que volver atrás con la mirada el doble de veces. Sus ojos estaban cansados saltando de un lado a otro.

🧠 La Lección Principal: "No todo lo que brilla es oro"

El estudio descubrió algo muy importante sobre cómo aprenden los novatos:

• Los nombres claros no siempre ayudan: Aunque el código extraído tenga nombres bonitos y descriptivos (como "CalcularÁrea"), los novatos a menudo no confían en ellos. En lugar de confiar en el nombre, vuelven a leer el código para asegurarse de que la función hace lo que dice. Esto crea un "cansancio visual".
• El contexto lo es todo:
  • Para problemas difíciles, separar el código (Extraer Método) es como tener un mapa bien organizado.
  • Para problemas fáciles, separar el código es como tener un mapa que te obliga a caminar 100 metros solo para cruzar la calle.

💡 ¿Qué significa esto para los profesores y estudiantes?

1. Para los profesores: ¡Cuidado con la "modularización prematura"! No obligues a los estudiantes a crear funciones separadas para cada cosa pequeña al principio. A veces, tener todo junto (Inline) es más fácil de seguir para un principiante.
2. Para los estudiantes: No te obsesiones con hacer el código "perfecto" o "bonito" al principio. Si la tarea es simple, mantenerlo todo junto puede ayudarte a entenderlo más rápido.
3. Para la ciencia: Medir el tiempo de ejecución no es suficiente. A veces, un programa parece rápido, pero si el cerebro del programador tiene que hacer "saltos de rana" visuales para entenderlo, está gastando mucha energía mental.

En resumen:
El estudio nos dice que la simplicidad a veces es mejor que la organización. Para un novato, ver todo el proceso en un solo lugar puede ser como leer una historia lineal, mientras que tener que saltar entre funciones puede sentirse como leer un libro donde las páginas están desordenadas. ¡Hay que saber cuándo usar cada uno!

Resumen técnico

Aquí presento un resumen técnico detallado del artículo "Refactoring for Novices in Java: An Eye Tracking Study on the Extract vs. Inline Methods", estructurado según los puntos solicitados.

1. Planteamiento del Problema

La refactorización de código, específicamente las técnicas de Extraer Método (Extract Method) e Insertar Método (Inline Method), son prácticas comunes para mejorar la estructura interna del software sin alterar su comportamiento externo.

• El conflicto: La literatura previa ha utilizado principalmente métricas estáticas (como olores de código o complejidad ciclomática) para evaluar estos cambios, pero no ha capturado adecuadamente el factor humano en la comprensión del código.
• La hipótesis no probada: Se asume generalmente que extraer métodos con nombres descriptivos actúa como "balizas" (beacons) semánticas que facilitan la comprensión top-down. Sin embargo, no está claro si esto es cierto para desarrolladores novatos en Java, especialmente en tareas simples donde la indirection (indirección) podría aumentar la carga cognitiva y el esfuerzo visual en lugar de reducirlo.
• La brecha: Existe una falta de estudios que utilicen un enfoque dinámico (seguimiento ocular) para medir cómo los cambios estructurales pequeños afectan el esfuerzo visual, los patrones de lectura y la navegación mental de los novatos.

2. Metodología

El estudio empleó un enfoque mixto (cuantitativo y cualitativo) con un diseño experimental controlado.

• Participantes:
  • Experimento Controlado: 32 estudiantes universitarios novatos en Java (promedio de 12 meses de experiencia en Java).
  • Encuesta: 58 novatos adicionales en Java para validar preferencias y motivaciones.
• Tareas: Se seleccionaron 8 programas simples (adaptados de cursos introductorios) que cubren operaciones matemáticas y lógicas (ej. calcular factorial, área de un cuadrado, verificar si un número es par).
• Tratamientos: Para cada tarea, se crearon dos versiones funcionalmente equivalentes:
  1. Inline Method: La lógica está contenida directamente en el método main.
  2. Extract Method: La lógica se extrae a un método separado con un nombre descriptivo (ej. calculaFatorial).
• Instrumentación:
  • Eye Tracking: Se utilizó un Tobii Eye Tracker 4C (90 Hz) para registrar movimientos oculares.
  • Métricas Visuales: Se definieron Áreas de Interés (AOI) en el código. Las métricas clave fueron:
    • Duración de fijación: Tiempo de atención en un punto (esfuerzo cognitivo).
    • Conteo de fijaciones: Número de paradas visuales.
    • Regresiones: Movimientos de ojos hacia atrás (relectura), indicador de confusión o falta de linealidad.
  • Métricas de Rendimiento: Tiempo de completado y número de intentos para obtener la salida correcta.
• Análisis: Se aplicó la teoría fundamentada (grounded theory) en entrevistas post-tarea y se utilizaron pruebas estadísticas (t-test, Mann-Whitney U, corrección FDR) para validar las hipótesis.

3. Contribuciones Clave

1. Evidencia Empírica con Novatos: Es uno de los primeros estudios que utiliza seguimiento ocular para comparar Extract vs. Inline Method específicamente en desarrolladores novatos en Java.
2. Desafío a la Convención de las "Balizas": Demuestra que los nombres de métodos significativos (balizas) no siempre mejoran la comprensión para los novatos; en tareas simples, pueden interrumpir el razonamiento lineal y aumentar el esfuerzo de navegación.
3. Modelo Integrativo: Propone una teoría que relaciona las características de la tarea, la representación del código y los mecanismos cognitivos, sugiriendo que el beneficio de la modularización depende de la complejidad intrínseca de la tarea.
4. Descubrimiento de la Discrepancia Percepción-Realidad: Revela que los novatos prefieren la versión extraída por su apariencia de "limpieza", pero a menudo tienen un rendimiento peor (más tiempo y más regresiones) en comparación con la versión inline en tareas simples.
5. Recurso Abierto: Disponibilidad de un paquete de replicación con material experimental y scripts de análisis.

4. Resultados Principales

Los resultados mostraron que el impacto de la refactorización es dependiente del contexto y la complejidad de la tarea:

• Tareas Complejas (ej. Factorial, Encontrar el Máximo):

  • La extracción de métodos mejoró significativamente la comprensión.
  • Reducciones observadas: Tiempo de ejecución hasta un 78.8% menor, regresiones hasta un 84.6% menores y menor duración de fijación.
  • Los novatos aprovecharon el nombre del método para entender la intención sin inspeccionar los detalles internos inmediatamente.

• Tareas Simples (ej. Área de un cuadrado, Verificar par):

  • La extracción de métodos empeoró el rendimiento.
  • Aumentos observados: Tiempo de ejecución hasta un 166.9% mayor y regresiones hasta un 200% mayores en comparación con la versión inline.
  • Causa: La necesidad de navegar constantemente entre la llamada al método y su definición (cambio de contexto) interrumpió el flujo de lectura lineal. Los novatos no usaron el nombre del método como una baliza efectiva; en su lugar, volvieron a verificar la lógica interna, aumentando la carga cognitiva.

• Preferencias vs. Rendimiento:

  • En la encuesta, la mayoría prefirió la versión extraída por "legibilidad" y "reutilización".
  • Sin embargo, en tareas triviales, muchos prefirieron la versión inline por "simplicidad" y "lectura continua".
  • Existe una brecha entre lo que los novatos creen que es más legible y lo que realmente les permite resolver problemas más rápido.

5. Significado e Implicaciones

• Para la Educación: Los educadores deben tener cautela al aplicar la modularización prematura (extraer métodos) en tareas introductorias muy simples. Esto puede distraer a los novatos y aumentar la carga cognitiva innecesaria. Se recomienda introducir la extracción de métodos solo cuando la complejidad de la lógica justifique la abstracción.
• Para la Investigación: El estudio valida el uso del seguimiento ocular como una métrica superior a las estáticas para evaluar el impacto humano de las refactorizaciones. Las métricas tradicionales (tiempo) a veces ocultan los patrones de confusión que las regresiones y fijaciones revelan.
• Para la Práctica de Ingeniería de Software: No existe una regla universal para refactorizar. La decisión de extraer o insertar un método debe basarse en la complejidad de la lógica subyacente y el nivel de experiencia del desarrollador. En código trivial, la inlineación puede ser más eficiente para la comprensión inmediata.
• Teoría Cognitiva: Los hallazgos sugieren que los novatos tienden a realizar un procesamiento "bottom-up" (de abajo hacia arriba) y no utilizan eficazmente las balizas semánticas (nombres de métodos) para un procesamiento "top-down" hasta que adquieren más experiencia, lo que contradice algunas teorías previas basadas en fMRI que sugerían lo contrario para desarrolladores en general.

En conclusión, el artículo demuestra que la modularización no es intrínsecamente beneficiosa para la comprensión de código por parte de novatos; su utilidad está estrictamente ligada a la complejidad de la tarea, y una aplicación indiscriminada puede obstaculizar el aprendizaje y la eficiencia.