Integrating Structural and Semantic Analysis for Code Smell Refactoring Prediction

El software nunca se termina realmente. Como una ciudad que crece orgánicamente a lo largo de décadas, un programa informático acumula capas de adiciones, parches y arreglos rápidos. Con el tiempo, este crecimiento orgánico puede derivar en debilidades estructurales, de forma muy similar a un edificio donde un pasillo ha sido ensanchado sin reforzar las paredes. En el mundo de la ingeniería de software, estas fallas localizadas se conocen como "code smells" (olores de código). No son errores que causen que un programa se bloquee, sino más bien señales de un mal diseño que hacen que el código sea difícil de entender, cambiar o mantener. Cuando los desarrolladores detectan estos olores, a menudo realizan una "refactorización", un proceso cuidadoso de reorganización del código para mejorar su estructura sin cambiar lo que el software realmente hace. El desafío es que los desarrolladores no siempre corrigen cada olor que encuentran, y predecir cuáles se corregirán es difícil porque la decisión suele depender de la intención humana y el contexto, no solo del código en sí.

Un equipo de investigadores de la Universidad de Milano-Bicocca se propuso ver si las máquinas podían aprender a predecir estas decisiones humanas. Querían saber si una computadora podía observar una pieza de código, identificar una falla y adivinar con precisión si un desarrollador terminaría limpiándola. Para lograrlo, construyeron un sistema que combina dos formas distintas de observar el código. La primera es tradicional: contar propiedades como qué tan largo es un método o cuántas variables utiliza. La segunda es más moderna y compleja: convertir el código en un mapa de su lógica y comportamiento, y luego traducir ese mapa en una representación matemática que una computadora pueda analizar en busca de patrones ocultos. Al alimentar esta información combinada en modelos de aprendizaje automático, los investigadores probaron si las computadoras podían aprender las reglas sutiles que guían a los desarrolladores cuando deciden refactorizar.

Los investigadores recopilaron datos de 79 proyectos de código abierto en Java, una colección de software que había sido desarrollada y mantenida por muchas personas diferentes a lo largo del tiempo. Utilizaron herramientas automatizadas para escanear el historial de estos proyectos, identificando miles de instancias donde estaban presentes los "code smells" y rastreando cuáles fueron corregidos posteriormente mediante acciones de refactorización específicas, tales como renombrar una variable, extraer un método para convertirlo en una pieza más pequeña o cambiar un parámetro. Luego, crearon un conjunto de datos híbrido para cada pieza de código. Este conjunto de datos incluía mediciones estándar, como el número de líneas en un método, junto con dos tipos diferentes de "embeddings". Un tipo de embedding mapeaba el flujo de control, mostrando el orden en que se ejecutan las instrucciones. El otro, más avanzado, mapeaba las relaciones semánticas más profundas, capturando cómo se mueven los datos a través del programa y cómo dependen entre sí las diferentes partes del código, creando efectivamente un retrato rico y multidimensional del comportamiento del código.

Los resultados mostraron que los modelos de aprendizaje automático son, de hecho, capaces de predecir la refactorización con un alto grado de fiabilidad. Cuando los modelos fueron probados en diez tipos diferentes de operaciones de refactorización, frecuentemente alcanzaron puntuaciones AUC superiores a 0.70, y para algunas tareas, superaron el 0.80. Esto sugiere que existen, de hecho, patrones detectables en el código que señalan la intención de un desarrollador de realizar una limpieza. Sin embargo, el estudio reveló un matiz crucial: no todos los "code smells" son iguales. Los modelos fueron excepcionalmente buenos prediciendo cambios estructurales, como añadir un parámetro a un método o cambiar el tipo de una variable. Estas acciones suelen estar impulsadas por factores claros y medibles, como la longitud de una sentencia o la complejidad de un cálculo. Por el contrario, los modelos tuvieron dificultades para predecir cambios más conceptuales, como renombrar un método. El renombrado es a menudo una decisión subjetiva basada en cómo un desarrollador piensa sobre el propósito del código, un factor que es difícil de capturar únicamente con números o mapas estructurales.

Quizás el hallazgo más significativo concernía al tipo de representación de datos utilizado. Los investigadores esperaban inicialmente que el simple hecho de añadir mapas más complejos del flujo de ejecución del código mejoraría las predicciones. En cambio, descubrieron que un tipo específico de mapa de flujo, que rastreaba el orden de las sentencias, de hecho introducía ruido que confundía a los modelos. Cuando este mapa de flujo se combinaba con las mediciones tradicionales, a menudo empeoraba las predicciones, ya que la computadora luchaba por ignorar los detalles irrelevantes. Sin embargo, cuando los investigadores cambiaron a la representación más avanzada que combinaba las dependencias estructurales con el texto y la lógica real del código, los resultados cambiaron drásticamente. Esta representación más rica proporcionó una señal complementaria que los modelos pudieron utilizar de manera efectiva. De hecho, para algunas tareas, los modelos entrenados únicamente con esta representación avanzada funcionaron casi tan bien como aquellos entrenados con el conjunto de datos completo, demostrando que la comprensión profunda de la estructura y la semántica del código era un predictor poderoso por derecho propio.

El estudio también destacó los límites de lo que puede predecirse a partir del código por sí solo. Si bien los modelos pueden pronosticar de manera confiable correcciones técnicas impulsadas por la complejidad, no pueden prever fácilmente las decisiones humanas detrás del renombrado o la reorganización del código para fines de claridad. Esto sugiere que, si bien las máquinas pueden ser excelentes identificando cuándo un software está técnicamente en deuda de mantenimiento, la decisión final de refactorizar a menudo depende de la visión y el contexto de un desarrollador que existen fuera del código mismo. La investigación concluye que el futuro del mantenimiento de software automatizado no reside en reemplazar el juicio humano, sino en utilizar estas herramientas predictivas para resaltar las deudas estructurales que son más urgentes, permitiendo a los desarrolladores concentrar su tiempo limitado en los cambios que más importan. Al comprender qué señales son fuertes y cuáles son ruido, podemos construir mejores herramientas para mantener nuestra infraestructura digital sana y sostenible.