{"id":1031,"date":"2014-02-23T17:06:01","date_gmt":"2014-02-23T16:06:01","guid":{"rendered":"http:\/\/qualilogy.com\/es\/?p=1031"},"modified":"2014-02-23T18:39:43","modified_gmt":"2014-02-23T17:39:43","slug":"analisis-plsql-con-sonarqube-evaluar-la-calidad-2","status":"publish","type":"post","link":"http:\/\/qualilogy.com\/es\/analisis-plsql-con-sonarqube-evaluar-la-calidad-2\/","title":{"rendered":"An\u00e1lisis PL\/SQL con SonarQube \u2013 Evaluar la calidad (2\/3)"},"content":{"rendered":"

\"PLSQLEva2\"<\/a>Lo siento por el tiempo pasado desde el \u00faltimo post de esta serie sobre PL\/SQL y SonarQube, pero estaba muy ocupado entre viajes, el trabajo y mi laptop que decidi\u00f3 abandonarme, por supuesto invocando la ley de Murphy para justificar fallar en el peor momento.<\/p>\n

En los posts anteriores: despu\u00e9s de configurar un an\u00e1lisis de c\u00f3digo PL\/SQL con SonarQube<\/a>, hemos elaboraro nuestro propio Quality Profile<\/a> con una orientaci\u00f3n a la robustez, el rendimiento y la seguridad en las reglas Blockers<\/a> y Criticals<\/a>.<\/p>\n

\u00bfA que parece ahora nuestro dashboard SonarQube? <\/p>\n

Hemos examinado en el post anterior las m\u00e9tricas de tama\u00f1o<\/a> y no dimos cuenta que el n\u00famero medio de l\u00edneas de c\u00f3digo por objeto (procedimiento, funci\u00f3n, trigger, etc. ) no estaba mal.<\/p>\n

Con el nuevo widget File Bubble Chart, descubrimos m\u00e1s de 58.000 l\u00edneas de c\u00f3digo en un \u00fanico archivo ‘CreatePackageBody.sql’, con toda la l\u00f3gica de negocio implementada en la base de datos, lo que sin duda resultar\u00e1 en un coste de mantenimiento alto para esta aplicaci\u00f3n.<\/p>\n

Complejidad y duplicaci\u00f3n<\/h2>\n

Complejidad<\/h3>\n

\"PLSQL_Complexity\"<\/a> Si echamos un ojos a la Complejidad Ciclom\u00e1tica (CC), encontramos resultados similares: la complejidad promedio por objeto es relativamente baja con 6.9 puntos de CC, y un m\u00e1ximo de 12 puntos. Pero la complejidad por archivo supera los 600 puntos, y tenemos un total de poco m\u00e1s de 10.000 puntos de CC en toda la aplicaci\u00f3n, lo cual no es muy alto.
\n\"PLSQ_CCglobale\"<\/a><\/p>\n

El esfuerzo de test para esta aplicaci\u00f3n no es muy importante. Recordemos que la Complejidad Ciclom\u00e1tica es una medida de la cantidad de diferentes ‘caminos’ en una aplicaci\u00f3n. Lo ideal ser\u00eda hacer pruebas de todos los caminos, por lo que la CC nos da una idea del esfuerzo de pruebas.<\/p>\n

Se considera que a partir de 20 000 puntos para una aplicaci\u00f3n, es necesario realizar un control de calidad (QA) espec\u00edfico, definir y realizar casos de test y si es posible, automatizar las pruebas. En nuestro caso, podemos dejar el equipo del proyecto realizar estas pruebas de forma interna.
\nPero como se puede ver con el siguiente Treemap que he configurado para mostrar la Complejidad Ciclom\u00e1tica …<\/p>\n

\"PLSQL_CCBig\"<\/a><\/p>\n

Nuestro fichero ‘CreatePackageBody.sql’ representa 90% de la complejidad y por lo tanto, de la l\u00f3gica de la aplicaci\u00f3n. As\u00ed que una vez m\u00e1s, tenemos cifras correctas a nivel de aplicaci\u00f3n excepto que la casi toda la aplicaci\u00f3n se encuentra en un solo archivo.<\/p>\n

Duplicaciones<\/h3>\n

\"PLSQL_Duplications\"<\/a>Despu\u00e9s de la complejidad, voy a interesarme en el nivel de duplicaci\u00f3n, bastante alto. Sin sorpresa, el mismo archivo monstruoso que implementa la l\u00f3gica de negocio se encuentra de nuevo en primera fila.<\/p>\n

\"PLSQL_DuplicHotspot\"<\/a><\/p>\n

Sin embargo, nos encontramos con un gran n\u00famero de Copiado\/Pegado en los otros archivos, especialmente en el fichero ‘Create_tables.sql’. Este script se encarga de crear las tablas de la base de datos, lo que significa\u00a0que se duplican muchas estructuras de datos.<\/p>\n

Eso puede indicar que el modelo de datos no est\u00e1 optimizado. Esto sucede por una aplicaci\u00f3n de tipo Legacy, porque es m\u00e1s f\u00e1cil agregar nuevas tablas que hacer evolucionar las existentes. Pero m\u00e1s tablas significa m\u00e1s enlaces, y por consiguiente un rendimiento inferior y m\u00e1s complejidad para mantener estas estructuras de datos.<\/p>\n

En el contexto de una auditor\u00eda real de la calidad de esta aplicaci\u00f3n, yo tomar\u00eda el tiempo para investigar este fichero y investigar esta hip\u00f3tesis y encontrar algunos ejemplos que pueden apoyar un refactoring del ‘data model’.<\/p>\n

Por ejemplo, hay 687 sentencias ‘CREATE TABLE’ en este archivo, y entonces 687 tablas en total (sin contar las ‘views’). 8 963 l\u00edneas duplicadas en este script significa un promedio de 13 l\u00edneas, pues 13 campos similares en cada tabla. Tiene sentido tener algunos campos ‘claves’ para llevar a cabo los ‘join’, pero tal vez no tantos.<\/p>\n

Componentes con riesgo<\/h2>\n

Despu\u00e9s de ver los indicadores cuantitativos, ya tenemos una gran cantidad de informaci\u00f3n con respecto a esta aplicaci\u00f3n, sin duda m\u00e1s que por lo general conocen los responsables del proyecto, por no hablar de los stakeholders y los responsables de TI.<\/p>\n

La segunda parte de una evaluaci\u00f3n de la calidad consiste en identificar las principales amenazas, y esto requiere buscar los componentes de mayor riesgo. Hemos visto en los art\u00edculos anteriores:<\/p>\n