En estos meses, bajo el proyecto Smart Software Quality que ayer os comentaba, lanzamos la evaluación de la calidad del producto software (concretamente de la mantenibilidad) de 1000 proyectos Java de GitHub. Os dejo en este post un resumen del estudio, si quereis más en la página de Smart Software Quality hay un informe más extenso.
Las métricas obtenidas, están relacionadas con la característica mantenibilidad del modelo de calidad de la ISO 25000 (te dejo un post sobre qué es eso de la ISO 25000) y han sido la complejidad ciclomática, el código repetido, incumplimiento de reglas de PMD (relacionadas con el diseño, el acoplamiento, los comentarios, las pruebas, código sin utilizar, etc.) entre otras.
Los 1000 proyectos que elegimos son los mejor valorados en GitHub y tienen un tamaño de hasta casi 2 millones de líneas de código, con una media de 35180 líneas de código. Más de la mitad de los proyectos (59.94%) tienen un tamaño de entre 10 y 10000 líneas de código.
Los problemas más repetidos
Con una gran diferencia, las reglas más incumplidas han sido las de comentarios (con 47.63% de ocurrencias) y acoplamiento (43.63%).
Dentro de los comentarios, “Comment Required” es la regla que más se incumple, con un 75.76%. Destaca la falta de documentación de APIs públicas (con 75,76% de las ocurrencias con respecto a las totales) y un tamaño excesivo de comentarios (24.24%). Solo un 3,65% de los proyectos no tiene ningún comentario mayor de 6 líneas.
De entre todas las reglas de acoplamiento, con un 99.09% de ocurrencias, la Ley de Demeter es la regla más infringida de todas ellas.
Relaciones entre métricas
Los datos recopilados también nos han servido para obtener posbiles relaciones entre métricas de calidad del software.
El estudio que hemos hecho en este punto es bastante extenso, pero como ejemplo, abajo os dejo la relación entre la complejidad ciclomática y las líneas de código.
Figura 1. Relación entre la complejidad ciclomática y las líneas de código.
Se ha visto que en los datos de la muestra que hay una correlación fuerte entre el número de líneas de código de un proyecto y su complejidad ciclomática (cosa que es bastante lógica, pero que no está demás contrastarla).
También existe una relación significativa entre el número de líneas de código repetido y el tamaño del código fuente.
No hemos apreciado relación entre la densidad de la complejidad ciclomática y la densidad del código repetido.
- Diario: cómo Javier Garzás evita quedarse obsoleto estudiando a un X10 con IA-Esteroides - 7 noviembre, 2024
- Si creas Historias de Usuario con IA ¿A quién pertenecen? ¿A ti o la IA? El mono Naruto te lo explica - 31 octubre, 2024
- HistorIAs de usuario y como a Maximiliano lo ENGAÑABAN con la IA y como una viejuna historia del 1500 le salvó - 24 octubre, 2024
Una duda: si se genera documentación con formato JAVAdoc, casi con seguridad todas las funciones van a tener (al menos) un comentario con más de 6 líneas. ¿Eso también se tiene en cuenta (en vuestro análisis)? ¿Se sigue considerando como «comentarios demasiado grandes»?
Muy buena apreciación, gracias! 😉
El tamaño excesivo de comentarios está sacado con la regla CommentSize de PMD, que si que cuenta como comentario excesivo un JAVAdoc de más de 6 líneas.
CommentRequired se centra más en que exista el JAVAdoc para cada método, elemento público…
Puede ser más útil comparar las dos violaciones de reglas entre sí. Me resulta curioso que con un 75% que no exista documentación sea lo que más se incumple, y que en comparación no haya tantos comentarios de tamaño excesivo. Por lo que veo comparando esas métricas es que falta más documentación, y que no todas (aunque es cierto que una parte si) las ocurrencias de comentarios excesivos son por el JAVAdoc, que en muchas ocasiones no está.
Por ejemplo, uno de los proyectos con más violaciones de CommentSize, tiene un comentario enorme con el copyright al inicio de cada archivo del proyecto, y sin embargo ningún JAVAdoc…
No está puesto pero hemos encontrado también por ahí algún que otro insulto en un comentario…Resulta bastante gracioso jeje
Javier,
me sorprendió ver que los comentarios son parte de las métricas de calidad usadas. Considerando que el código debería autoexplicarse usando nombres de métodos y variables que indiquen la intensión de esa parte de código o del método publico. Por tanto, los comentarios aparte de aumentar la díficultad para entender lo que hace un código (considerando el espacio que agrega), la intención de éstos es explicar algo que no puede hacer por sí mismo.
Con respecto a la ISO 25000, no se puede hacer mucho si explicitamente exige los comentarios para métodos, en este caso, los expuestos (públicos)
Me gustaría ver más opiniones sobre ésto.
De acuerdo con el comentario de Hector, muy atinado.
Los comentarios «excesivos» te llevan a un mal nombrado de clases,variables, métodos, entre otros. Irónico que las buenas prácticas soliciten nombrar todos los métodos públicos.