💻 computer science

A Concern-Centric Empirical Evaluation of Multi-Language Code Smells: An LLM-Assisted Study of JNI Software Evolution

Este artículo presenta una evaluación empírica centrada en las preocupaciones de los "smells" de código JNI mediante el uso de análisis asistido por LLM de 8.207 commits en 15 proyectos de código abierto, revelando que las definiciones existentes de los "smells" cubren solo el 36,5% de las preocupaciones de mantenimiento de los desarrolladores y proponiendo tres nuevas definiciones de "smells" para abordar las brechas identificadas.

Autores originales: Md Shahrukh Ansari, Salman Abdul Moiz

Publicado 2026-09-07

📖 5 min de lectura🧠 Análisis profundo

CC BY 4.0

Autores originales: Md Shahrukh Ansari, Salman Abdul Moiz

Artículo original bajo licencia CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). ✨ Esta es una explicación generada por IA del artículo a continuación. No ha sido escrita ni avalada por los autores. Para mayor precisión técnica, consulte el artículo original. Leer descargo de responsabilidad completo

El software moderno a menudo se siente como una máquina bien aceitada, pero debajo de la interfaz elegante, suele estar construido a partir de muchas partes diferentes que hablan lenguajes distintos. Para que un programa sea rápido, eficiente o capaz de comunicarse con hardware especializado, los desarrolladores suelen combinar código escrito en un lenguaje con código escrito en otro. Una forma común de hacer esto es a través de un puente llamado Java Native Interface, que permite que un programa escrito en Java pueda alcanzar y utilizar potentes herramientas escritas en C o C++. Si bien esta mezcla de lenguajes otorga un gran poder al software, también crea un tipo de desorden único. Del mismo modo que un traductor podría tener dificultades para mantener consistentes dos dialectos diferentes, el software puede desarrollar fallos ocultos donde los dos lenguajes no logran ponerse de acuerdo sobre cómo compartir datos, gestionar la memoria o manejar errores. Estos fallos, conocidos en la industria como "code smells" (olores de código), no son errores que bloqueen el programa inmediatamente, sino más bien decisiones de diseño que hacen que el software sea difícil de reparar, actualizar o comprender con el tiempo. Durante años, los expertos han intentado catalogar estos olores, creando listas de cómo se ve un mal diseño entre lenguajes. Pero una pregunta crítica permanecía sin respuesta: ¿coinciden estas listas realmente con los problemas reales que enfrentan los desarrolladores cada día cuando intentan mantener en funcionamiento estos sistemas complejos?

Un equipo de investigadores se propuso responder a esta pregunta observando directamente la historia de cómo cambia el software a lo largo del tiempo, en lugar de simplemente mirar el código en sí. Se centraron en quince proyectos de código abierto populares que dependen fuertemente de este puente de Java a C. En lugar de adivinar qué podría estar mal, examinaron miles de actualizaciones, o "commits", que los desarrolladores habían realizado en estos proyectos a lo largo de los años. Buscaban momentos en los que un desarrollador tuvo que detenerse y solucionar un problema de mantenimiento específico relacionado con la conexión entre los dos lenguajes. Para manejar el enorme volumen de datos, utilizaron una herramienta de inteligencia artificial avanzada para leer los cambios en el código y las notas que los desarrolladores escribieron sobre ellos. La IA actuó como un asistente altamente capacitado, escaneando las modificaciones para identificar el problema específico que el desarrollador intentaba resolver, como corregir una fuga de memoria, asegurar una transferencia de datos o reorganizar cómo se comunican dos partes del sistema. Los investigadores luego verificaron manualmente una muestra de estos hallazgos para asegurar que la IA fuera correcta, confirmando que el método era confiable.

El estudio reveló un panorama claro de con qué luchan realmente los desarrolladores. Identificaron once familias distintas de problemas que surgen recurrentemente. Los problemas más comunes involucraban mantener segura la frontera entre los dos lenguajes y asegurarse de que los recursos, como la memoria o los manejadores de archivos, se limpiaran adecuadamente después de su uso. Estas dos categorías por sí solas representaron casi el sesenta por ciento de todo el trabajo de mantenimiento que los investigadores encontraron. Esto sugiere que el trabajo diario más urgente para estos desarrolladores es simplemente evitar que la conexión entre los lenguajes se rompa o presente fugas. Sin embargo, cuando los investigadores compararon estos problemas del mundo real con las listas existentes de "code smells" conocidos, encontraron una brecha significativa. Los catálogos actuales, que fueron creados en gran medida por expertos basados en principios de diseño teóricos, solo cubrían aproximadamente el treinta y seis por ciento de los problemas reales que los desarrolladores estaban solucionando. En otras palabras, las listas existentes pasaban por alto la mayor parte del trabajo que los desarrolladores realizaban para mantener su software saludable.

Los investigadores se dieron cuenta de que los problemas faltantes no eran errores aleatorios, sino patrones recurrentes que merecían sus propios nombres. Encontraron que los desarrolladores frecuentemente tenían que realizar cambios coordinados tanto en el código Java como en el código C cada vez que un solo detalle cambiaba, una situación que hacía que las actualizaciones fueran lentas y propensas a errores. También vieron casos donde el software exponía detalles internos ocultos a través de la barrera del lenguaje, debilitando la seguridad y la organización del sistema. Finalmente, notaron que las responsabilidades a menudo se colocaban en el lenguaje equivocado, obligando a un lado del sistema a pedir constantemente al otro lado que hiciera su trabajo, lo que creaba una complejidad innecesaria. Basándose en estas observaciones repetidas, el equipo propuso tres nuevas definiciones de "code smells" que abordan específicamente estos problemas entre lenguajes. Los nombraron Cross-Language Shotgun Surgery (Cirugía de Escopetazo entre Lenguajes), describiendo la necesidad de cambiar muchos archivos a la vez; Cross-Language Abstraction Leakage (Fuga de Abstracción entre Lenguajes), donde los detalles ocultos se exponen accidentalmente; y Wrong Responsibility Allocation (Asignación de Responsabilidad Errónea), donde las tareas se asignan a la capa de lenguaje incorrecta.

Este trabajo desplaza el enfoque de lo que los expertos creen que debería ser un problema hacia lo que los desarrolladores están reparando realmente. Al escuchar la historia del propio software, los investigadores demostraron que la comprensión actual de los fallos de diseño multi-lenguaje es incompleta. Las listas existentes son buenas para detectar errores locales simples, pero pasan por alto los desafíos arquitectónicos más profundos que surgen cuando dos mundos de código diferentes intentan trabajar juntos. Las nuevas definiciones proporcionan un vocabulario para estas luchas ocultas, ofreciendo una forma de detectar y solucionar estos tipos específicos de desorden antes de que se vuelvan inmanejables. El estudio concluye que para comprender verdaderamente la calidad del software, no debemos mirar solo el código estático, sino la larga y desordenada historia de cómo ese código se mantiene vivo y evoluciona.

Resumen Técnico: Una Evaluación Empírica Centrada en las Preocupaciones de los Malos Olores de Código Multilenguaje

Planteamiento del Problema
Los sistemas de software multilingüe, particularmente aquellos que utilizan la Interfaz Nativa de Java (JNI), ofrecen beneficios de ingeniería significativos pero introducen desafíos complejos de mantenibilidad debido a las dependencias entre lenguajes. Si bien la investigación existente ha propuesto catálogos de malos olores (smells) de código y de diseño específicos para JNI basados en principios de diseño de software y análisis estático, persiste una brecha crítica: se desconoce si estas definiciones de smells predefinidas corresponden a las preocupaciones de mantenimiento reales que los desarrolladores encuentran y abordan durante la evolución del software. Los desarrolladores rara vez describen las actividades de mantenimiento utilizando terminología de "smells"; en su lugar, abordan problemas de ingeniería concretos como fugas de recursos, seguridad en los límites y comunicación entre lenguajes. En consecuencia, la relevancia práctica y la completitud de los catálogos actuales de smells de JNI permanecen en gran medida inexploradas.

Metodología
Este estudio adopta una perspectiva centrada en las preocupaciones (concern-centric) en lugar de una centrada en los smells. En lugar de partir de definiciones de smells predefinidas, los autores minaron el historial de evolución de software de 15 proyectos de código abierto de JNI para identificar preocupaciones de mantenimiento recurrentes. La metodología procedió en cuatro fases:

Recolección y Extracción de Datos: Se analizó el historial completo de Git de 15 proyectos (que comprende 74,656 commits). Utilizando constructos específicos de JNI (por ejemplo, métodos native, JNIEnv, JNIEXPORT), se extrajeron 8,207 diffs de commits relacionados con JNI.
Extracción de Preocupaciones Asistida por LLM: Se empleó un Modelo de Lenguaje de Gran Escala (ChatGPT) para analizar los mensajes de los commits y los diffs de código con el fin de identificar las preocupaciones de mantenimiento subyacentes abordadas. Se instruyó al LLM para que se centrara en actividades de mantenimiento que resuelven problemas existentes, excluyendo adiciones de funcionalidades o cambios de formato. Para garantizar la fiabilidad, se validó manualmente una muestra aleatoria del 10% (65 commits), obteniendo una precisión del 96.92%.
Mapeo y Análisis de Brechas: Los 652 commits que abordaban preocupaciones fueron categorizados en familias de preocupaciones recurrentes. Estas familias fueron sistemáticamente mapeadas al catálogo existente de smells de código y de diseño de JNI por dos investigadores independientes (Cohen's $\kappa$ = 0.913). Las preocupaciones que no pudieron ser representadas adecuadamente por los smells existentes se clasificaron como "no mapeadas".
Derivación de Candidatos a Smells: Las preocupaciones recurrentes no mapeadas que exhibieron consistencia conceptual y naturaleza trans-lenguaje fueron analizadas para proponer nuevas definiciones de smells candidatas específicas de JNI.

Contribuciones Clave
El artículo realiza tres contribuciones principales:

Una Metodología Centrada en las Preocupaciones: Un marco sistemático para evaluar empíricamente los catálogos de smells multilingües mediante la minería del historial de evolución de software, demostrado a través de un estudio a gran escala de sistemas JNI.
Taxonomía Empírica de Mantenimiento de JNI: Una taxonomía de 11 familias de preocupaciones de mantenimiento de JNI recurrentes extraídas de 652 commits validados, proporcionando una caracterización empírica de los problemas de mantenimiento entre lenguajes.
Tres Definiciones de Smells Candidatas Específicas de JNI: La propuesta de tres nuevas definiciones de smells derivadas de preocupaciones recurrentes no mapeadas:
- Cirugía de Repercusión Trans-lenguaje (CLSS - Cross-Language Shotgun Surgery): Motivada por la necesidad de modificaciones coordinadas entre Java y el código nativo (por ejemplo, nombres de clases o firmas codificadas de forma fija en el código nativo).
- Fuga de Abstracción Trans-lenguaje (CLAL - Cross-Language Abstraction Leakage): Motivada por la exposición de detalles de implementación a través de los límites de lenguaje (por ejemplo, código nativo accediendo a campos privados de Java).
- Asignación Incorrecta de Responsabilidades (WRA - Wrong Responsibility Allocation): Motivada por responsabilidades implementadas en un lenguaje donde reside la mayoría de sus dependencias de comportamiento (por ejemplo, métodos de Java que simplemente orquestan la lógica nativa).

Resultos

Preocupaciones de Mantenimiento: El estudio identificó 11 familias de preocupaciones recurrentes. Las más frecuentes fueron Seguridad de los Límites de JNI (33.80% de los commits que abordan preocupaciones) y Fuga de Recursos de JNI (25.39%), seguidas de categorías como Comunicación entre Lenguajes, Gestión de Hilos y Reubicación de Responsabilidades.
Brecha de Cobertura: El catálogo de smells de JNI existente proporciona solo una cobertura parcial de las preocupaciones de mantenimiento de los desarrolladores. Solo el 36.5% (238 de 652) de los commits identificados que abordan preocupaciones se mapearon con los smells de JNI existentes.
Especificidades del Mapeo: Los smells existentes como el Abuso de Referencias Locales y el Desajuste de Gestión de Memoria respaldaron fuertemente las preocupaciones de gestión de recursos. Sin embargo, las preocupaciones arquitectónicas como la propagación de cambios entre lenguajes, los límites de abstracción y la asignación de responsabilidades no fueron capturadas en gran medida por las definiciones actuales.
Nuevos Smells: El análisis de las preocupaciones no mapeadas justificó los tres smells candidatos (CLSS, CLAL, WRA), los cuales abordan deficiencias arquitectónicas no capturadas por el catálogo actual.

Significancia y Reivindicaciones
El artículo sostiene que el historial de evolución del software sirve como una fuente valiosa y complementaria de evidencia empírica para evaluar y extender los catálogos de smells multilingües.

Validación del Trabajo Existente: El estudio confirma que los catálogos de smells existentes capturan eficazmente los problemas a nivel de implementación (gestión de recursos, manejo de excepciones), pero a menudo pasan por alto preocupaciones arquitectónicas recurrentes.
Descubrimiento Bottom-Up: La metodología propuesta ofrece una forma sistemática de descubrir nuevos smells basados en el esfuerzo real del desarrollador en lugar de basarse únicamente en principios de diseño teóricos.
Generalizabilidad: Aunque se centra en JNI, los autores afirman que la metodología centrada en las preocupaciones es aplicable a cualquier ecosistema multilingüe donde se pueda minar el historial de evolución.
Alcance Modesto: Los autores declaran explícitamente que las operacionalizaciones de los smells propuestas son estrategias de detección iniciales derivadas de manifestaciones representativas observadas en el estudio, no definiciones exhaustivas. Reconocen que se pueden identificar manifestaciones adicionales en trabajos futuros y que los hallazgos pueden no generalizarse directamente a sistemas propietarios u otras tecnologías de interoperabilidad sin mayor investigación.

Más como este