Corría el mes de marzo del 2013, en Móstoles, asignatura Calidad Software del grado de ingeniería del software de la Universidad Rey Juan Carlos, profesor, el que aquí suscribe, cuando se propuso a los alumnos que lo mejor para aprender a evaluar calidad software era evaluar calidad software, y para ello íbamos a evaluar la de los proyectos Java más vistos por aquellas fechas en Github.
Para ello, los alumnos podían utilizar una o varias herramientas de análisis de código (principalmente análisis estático y de caja blanca) tales como PMD, Checkstyle, Sonar, Code Pro Analytics y obtener distintas métricas de los proyectos antes mencionados, sobre todo aquellas que afectan a la mantenibilidad del código. Concretamente, obtuvieron valores de % código repetido, densidad de la complejidad ciclomática, % de cobertura de pruebas unitarias, y número de líneas de código.
Con todo, dado que el trabajo realizado por los alumnos fue de muy alta calidad, sumado a que las aplicaciones evaluadas son de fuentes abiertas más que las páginas de este blog tienen el objetivo de difundir conocimiento de manera abierta, para mejorar la creación de tecnología… he querido compartir contigo los datos.
Datos que son muy interesantes, ya que una de las cosas que más necesitamos en calidad software es ratios de referencia para las métricas y tener los de 51 aplicaciones… puede ayudarte mucho.
Valores de calidad software de 51 aplicaciones de Github
Una de las métricas destacadas del estudio realizado era densidad de complejidad ciclomática. Y los resultados obtenidos fueron los que se adjuntan en la siguiente tabla, ordenados de mayor a menor densidad de la complejidad ciclomática. También podéis ver el porcentaje de código repetido y, si existía o se podía calcular, la cobertura de pruebas unitarias.
| Nombre Aplicación y versión |
Líneas de Código |
Densidad de Complejidad Ciclomática |
% Código Repetido |
CoberturaPruebas |
| JSON – java | 2823 | 0.395324123273114 | 0.6% | 0% |
| yuicompressor | 5853 | 0.330428839911157 | 2.8% | |
| Rhino | 56586 | 0.328385112925459 | 2.3% | |
| Config-master | 8348 | 0.319597508385242 | 0.8% | |
| The MongoDB Java driver 2.12.0 | 16456 | 0.31951871657754 | 0.7% | 9.8% |
| aws-sdk-java | 331988 | 0.314701133 | 11,02% | |
| DiskLruCache | 766 | 0.304177545691906 | 0% | 85.1% |
| EssentialsProject | 573 | 0.3037 | 4.54% | |
| Parboiled | 7147 | 0.300125926962362 | 1.7% | |
| Clojure | 37258 | 0.287106124859091 | 4.2% | 0% |
| 58.com argo version 1.0. | 10544 | 0.286323975720789 | 2.2% | 3.1% |
| Retrofit 1.0.0 | 2056 | 0.285992217898833 | 0.9% | 61.9% |
| SlidingMenu-master | 2186 | 0.2813358 | 30612% | |
| Jna-master | 1859 | 0.2805 | 1.54% | 4.5% |
| CraftBukkit-master | 64454 | 0.2712632 | 4,88% | |
| ActionBarSherlock-master | 19547 | 0.2539 | 118052% | |
| spring-framework 3.2 | 197163 | 0.2529227781 | 1,7 | |
| FBReaderJ | 52079 | 0.2469 | 7.46% | |
| TeleHash | 4185 | 0.2463 | 0,71% | |
| Bukkit | 29610 | 0.243161094224924 | 12% | 0 |
| erjang 1.1 | 44649 | 0.23449 | 12.41% | 0.5% |
| jsoup | 13192 | 0.2343 | 2% | 1.6% |
| storm | 45288 | 0.233836777954425 | 52% | 0% |
| endlessAdapter | 177 | 0.23 | 9,03% | |
| argoMaster | 11220 | 0.23 | 7,86% | |
| BuildCraft | 32293 | 0.22791 | 13.07% | 0% |
| vert.x | 15927 | 0.2261568 | 12.6% | |
| Twitter4J | 31082 | 0.225 | 1.32 % | |
| Facebook_Android_SDK | 12223 | 0.2230221713 | 4,35% | |
| greenDAO – DaoGenerator 1.3 | 1304 | 0.22163 | 3.44% | 21.8% |
| h2o | 38804 | 0.219534068652716 | 0.65% | |
| stratego_12-2009 | 4932 | 0.2183 | 11.68% | 23,50% |
| Java-WebSocket | 5046 | 0.216 | 1.8% | 8,60% |
| acra | 4657 | 0.21387 | 4.87% | 0% |
| elasticsearch-master | 209426 | 0.212929 | 4.94% | |
| Jedis | 13564 | 0.2114 | 4.1 % | |
| Android BillingLibrary | 1806 | 0.2048 | 5.89% | |
| Mustache | 6997 | 0.197 | 1.15 % | |
| k9mail | 52328 | 0.19423 | 5.29% | |
| reddit-is-fun | 11350 | 0.1931 | 0.09% | 14.3% |
| RxJava | 9134 | 0.17999 | 12.3% | |
| viewserver | 584 | 0.1777 | 2.05% | |
| Solandra | 8123 | 0.1755 | 0.59 % | |
| http-request | 3591 | 0.1743 | 27.59% | |
| Android Master | 17476 | 0.174 | 7.77% | |
| Voldemort | 125616 | 0.171021207489492 | 4.82 | |
| junit | 22451 | 0.166771190592847 | 4.28 | |
| disruptor | 7450 | 0.137 | 9,93% | |
| NewQuickAction | 590 | 0.13179 | 1.3% | |
| REST LI | 74623 | 0.1232 | 0.62 % | |
| lazylist | 460 | 0.102 | 0% |
Resultados métricas de proyectos más vistos de Github en Java
A partir de ellos concluimos que aunque un programa esté entre los proyectos más vistos de Java en Github, no lleva implícito que tenga una cierta calidad de software.
Algunos proyectos tienen un % de cobertura de pruebas unitarias bastante aceptable o vimos rastros de haber sido analizados con alguna herramienta de análisis (algunos por ejemplo tenían una carpeta .Sonar), denotando una cierta preocupación por controlar la calidad del código, en otros, como en el del proyecto JSON-java, los desarrolladores no se preocuparon demasiado en la calidad de su software, y en la fecha en la que se analizó el estudio, este no tenía ningún caso de prueba programado y el valor de su densidad de la complejidad ciclomática era el mayor de todos.
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Las 3 matrices de priorización Ágil - 19 octubre, 2023
- Etapas del Agile Product Management - 12 octubre, 2023
- Agile Product Management: DINÁMICA «Árbol Solución Oportunidad» + «Valores Esperados» - 5 octubre, 2023
Hola,
¿Qué valor se debería tomar como límite para la densidad ciclomática? Nosotros tomamos el de 0,3 (aunque creo que somos demasiado generosos.
Lo mismo para el porcentaje de líneas duplicadas. Nosotros tomamos mayor o igual al 10% como inaceptable de 5% a 10% como malo y menor del 5% como aceptable.
Las líneas de código en si no es una métrica de calidad quizás sí el nº medio de líneas por metodo u otras similares.
¿Cuales son vuestros valores?
¿ faltaría alguna métrica importante?¿cuál?
Un saludo
Hola,
En el estudio, nosotros no establecimos un valor límite de densidad de complejidad ciclomática (que como tal no hay), sino que usamos esa métrica para poder comparar de forma general la complejidad ciclomática de todos los proyectos, independientemente de su tamaño.
Si en vez de usar la densidad hubiéramos tomado la complejidad ciclomática total de cada proyecto la comparación entre todos ellos no sería objetiva (ya que es normal que un proyecto más grande tenga más cc que uno pequeño.)
En mi opinión, para mejorar la calidad del código, en vez de fijar un límite para la densidad de la complejidad ciclomática, me centraría más en la complejidad ciclomática de cada método (según Checkstyle si es más de 11 hay que refactorizar).
Aún así…tampoco creo que sea recomendable quedarse con un límite fijo de complejidad que nunca debería pasar un métododo, sino revisar cada caso concreto.
Saludos
Hola, muchas gracias por publicar los resultados, son muy interesantes. Me gustaría saber si alguien puede recomendarme un par de buenos libros sobre calidad del software en los que aprender más sobre métricas como la Densidad de
Complejidad Ciclomática para entender exactamente cada término y aprender a mejorar mi propio software.
¡Gracias!