Evaluando la calidad del código con modelos de lenguaje grandes

El desarrollo de software depende mucho de escribir código que sea fácil de leer, mantener y mejorar. La Calidad del Código es un factor clave en el éxito de los proyectos de software, ya que afecta lo bien que los desarrolladores pueden trabajar con el código. Varios aspectos determinan la calidad del código, incluyendo cuán complejo es, cuán fácil es de leer, cuán bien se puede probar y si sigue buenas prácticas. Hay herramientas disponibles, llamadas Herramientas de Análisis de Código Estático, que ayudan a medir estas cualidades. Sin embargo, algunas cualidades requieren juicio humano, como la Legibilidad, que no pueden medirse fácilmente con herramientas.

Los Modelos de Lenguaje Grande (LLMs) han surgido como activos potenciales para evaluar la calidad del código. Estos modelos pueden procesar lenguaje natural y entender la sintaxis del código. Este documento examina la efectividad de los LLMs en evaluar la calidad del código en comparación con herramientas tradicionales como SonarQube. Nos enfocamos en cuán bien los LLMs pueden evaluar aspectos del código que no son fácilmente medibles por herramientas automatizadas.

#Calidad del Código

La calidad del código se refiere a varios factores que contribuyen a la efectividad general del código. Algunos de estos factores incluyen:

1. Complejidad: Cuán complicado es el código. Una mayor complejidad puede hacer que el código sea más difícil de mantener y entender.
2. Legibilidad: Cuán fácil es para alguien leer y entender el código. El código bien escrito debe ser claro y directo.
3. Testabilidad: Cuán fácil es probar el código para asegurarse de que funcione como se espera.
4. Interoperabilidad: Cuán bien interactúa el código con otro código o sistemas.
5. Reusabilidad: Cuán bien se pueden usar partes del código en diferentes proyectos o contextos.
6. Buenas Prácticas: Seguir prácticas de codificación establecidas que mejoran la calidad.

Las herramientas de análisis de código estático ayudan a evaluar estos factores examinando el código y generando informes. A pesar de la ayuda que brindan estas herramientas, hay algunos aspectos que aún necesitan juicio humano.

#Herramientas de Análisis de Código Estático

Herramientas como SonarQube analizan el código fuente para identificar problemas potenciales y proporcionar métricas sobre varios aspectos de la calidad del código. SonarQube evalúa el código y genera calificaciones de mantenibilidad basadas en reglas específicas. Las calificaciones van de A a E, siendo A la mejor calidad y E la peor. Estas calificaciones indican el costo y el esfuerzo requeridos para solucionar los problemas identificados.

Mientras que las herramientas de análisis de código estático pueden resaltar problemas relacionados con la calidad del código de manera efectiva, tienen limitaciones. Por ejemplo, pueden no captar completamente las sutilezas de cuán legible o comprensible es el código sin la visión humana. Algunos problemas pueden ser sutiles, como malas convenciones de nombres o comentarios confusos, que las herramientas estáticas a menudo pasan por alto.

#El Rol de los Modelos de Lenguaje Grande

Los modelos de lenguaje grande son sistemas de inteligencia artificial entrenados en grandes conjuntos de datos de texto. Pueden entender y generar texto similar al humano, lo que los hace adecuados para varias tareas, incluida la evaluación de código. Al usar procesamiento de lenguaje natural, podrían evaluar la calidad del código y proporcionar retroalimentación similar a la de los revisores humanos.

Dada su potencialidad, exploramos si los LLMs podrían complementar las herramientas de análisis estático tradicionales en la evaluación de la calidad del código. Específicamente, analizamos dos versiones del LLM conocido como ChatGPT: 3.5 Turbo y 4o.

#Metodología de Investigación

Para evaluar la capacidad de los LLMs en la evaluación de la calidad del código, seleccionamos dos proyectos de Java de código abierto con diferentes calificaciones de mantenibilidad: uno calificado como A y otro como B. Se analizaron un total de 1,641 clases de estos proyectos. Comparamos los resultados de las evaluaciones de los LLM con los de SonarQube.

Se instruyó a los LLMs para que proporcionaran una puntuación de 0 a 100 basada en la legibilidad y la calidad general. También definimos pautas específicas sobre cómo el LLM debería justificar su puntuación, centrándonos en la claridad y brevedad. Los resultados de ambos, LLMs y SonarQube, fueron analizados estadísticamente para determinar correlaciones y discrepancias.

#Selección de Proyectos

Se eligieron dos proyectos de código abierto para esta investigación:

1. Quarkus: Un marco nativo en la nube para escribir aplicaciones Java, con una calificación de mantenibilidad de A.
2. Shattered Pixel Dungeon: Un juego roguelike de código abierto con una calificación de mantenibilidad de B.

Estos proyectos fueron seleccionados para proporcionar un contraste en los niveles de calidad del código mientras aseguramos que el tamaño del código fuera sustancial para un análisis significativo.

#Métricas para Comparación

Comparamos métricas específicas derivadas del análisis de SonarQube, incluyendo:

• Número de "code smells"
• Densidad de líneas de comentario
• Complejidad cognitiva
• Complejidad general
• Conteo de declaraciones (número de declaraciones ejecutables)

Estas métricas proporcionaron una base para la comparación con las puntuaciones asignadas por los LLMs.

#Resultados

#Análisis del Proyecto Quarkus

El proyecto Quarkus contenía 644 clases y un total de 55,839 líneas de código. SonarQube identificó 1,626 "code smells" en el proyecto. La calificación de mantenibilidad mostró que la mayoría de las clases tenían una alta calificación, con un 95.49% calificadas como A y un 3.26% como B.

El LLM asignó puntuaciones principalmente alrededor de 85 o más, con una concentración significativa de clases recibiendo una puntuación de 85. La correlación entre las puntuaciones del LLM y las calificaciones de SonarQube mostró una relación moderada a fuerte, lo que indica que el LLM pudo identificar aspectos de la calidad del código que coincidían con el análisis de SonarQube.

Sin embargo, surgieron discrepancias en áreas específicas. Por ejemplo, algunas clases que SonarQube calificó como de menor calidad recibieron puntuaciones más altas del LLM. Esta diferencia destacó cómo el LLM podría evaluar la legibilidad de manera diferente que el enfoque centrado en el costo de reparación de SonarQube.

#Análisis del Proyecto Shattered Pixel Dungeon

El proyecto Shattered Pixel Dungeon tenía 997 clases y un total de 148,701 líneas de código. SonarQube identificó 4,432 "code smells", y las calificaciones de mantenibilidad mostraron que solo el 67.2% de las clases se calificaron como A, con muchas clases cayendo en calificaciones de calidad más bajas.

Para este proyecto, las puntuaciones del LLM variaron ampliamente, con un número notable de clases recibiendo puntuaciones por debajo de 70. El análisis reveló una tendencia del LLM a calificar clases que SonarQube clasificó como de baja calidad mucho más alto de lo esperado. Además, las evaluaciones del LLM fueron más fragmentadas, lo que indica un enfoque menos consistente en comparación con el primer proyecto.

#Análisis de Correlación

Realizamos un análisis de correlación entre las métricas de SonarQube y las puntuaciones del LLM usando correlación de Spearman. El análisis indicó que ciertas métricas correlacionaban bien, mostrando que los LLMs podrían reflejar aspectos de la calidad del código tal como los evaluó SonarQube.

Sin embargo, los resultados también señalaron limitaciones en las evaluaciones del LLM, particularmente en la captura de la complejidad y las interrelaciones entre diferentes componentes del código. El LLM a menudo se enfocó en la legibilidad del código, mientras que SonarQube consideró un contexto más amplio, incluyendo problemas de diseño y mantenibilidad.

#Limitaciones de los LLMs

Aunque el estudio encontró resultados prometedores para los LLMs en la evaluación de la calidad del código, se identificaron varias limitaciones:

1. Variabilidad de Resultados: Los LLMs pueden producir resultados diferentes para la misma entrada, llevando a inconsistencias en las evaluaciones.
2. Enfoque en Legibilidad: Los LLMs evalúan principalmente la calidad del código basada en aspectos de legibilidad, que pueden pasar por alto problemas más profundos que las herramientas de análisis estático pueden detectar.
3. Discrepancias entre Versiones: Diferentes versiones del mismo LLM pueden dar evaluaciones de calidad diferentes, indicando que depender de una sola versión para la evaluación de código puede no garantizar resultados consistentes.

#Direcciones Futuras

Esta investigación resalta el potencial de usar LLMs junto con herramientas de análisis estático tradicionales para mejorar las evaluaciones de calidad del código. Trabajos futuros podrían explorar el uso más amplio de LLMs a través de diferentes lenguajes de programación y en varios contextos. Áreas específicas para más investigación incluyen:

1. Estudios a Mayor Escala: Ampliar la evaluación para incluir más proyectos y lenguajes para validar hallazgos en un espectro más amplio.
2. Comparación con Otras Herramientas: Evaluar los LLMs junto a una gama más amplia de herramientas de análisis estático podría proporcionar una visión más profunda sobre su efectividad.
3. Optimización de Prompts: Investigar diferentes estrategias de prompting para mejorar la calidad y consistencia de los resultados generados por los LLMs.
4. Integración de Revisión Humana: Combinar las evaluaciones de los LLM con revisiones humanas podría aprovechar las fortalezas de ambas herramientas automatizadas y el juicio humano, llevando a mejores resultados en calidad de código.

#Conclusión

Este estudio exploró las capacidades de los modelos de lenguaje grande en la evaluación de la calidad del código en comparación con herramientas tradicionales como SonarQube. Los resultados indican que los LLMs pueden proporcionar información valiosa sobre la legibilidad del código y la calidad general, complementando las herramientas de análisis estático. Sin embargo, las diferencias en los criterios evaluativos entre los LLMs y las herramientas de análisis estático subrayan la necesidad de un enfoque integrado que combine las fortalezas de ambos. A medida que la tecnología continúa evolucionando, la investigación futura será esencial para refinar estos métodos y mejorar las prácticas de desarrollo de software.