{"id":984,"date":"2014-01-20T22:25:24","date_gmt":"2014-01-20T21:25:24","guid":{"rendered":"http:\/\/qualilogy.com\/es\/?p=984"},"modified":"2014-01-21T16:39:50","modified_gmt":"2014-01-21T15:39:50","slug":"analisis-plsql-con-sonarqube-majors","status":"publish","type":"post","link":"http:\/\/qualilogy.com\/es\/analisis-plsql-con-sonarqube-majors\/","title":{"rendered":"An\u00e1lisis PL\/SQL con SonarQube \u2013 Majors"},"content":{"rendered":"

\"PLSQL_Majors\"<\/a>Continuamos esta serie en el an\u00e1lisis de c\u00f3digo PL\/SQL con hoy las normas de tipo Majors.<\/p>\n

Vimos antes c\u00f3mo organizar nuestro entorno<\/a> y configurar nuestro an\u00e1lisis de c\u00f3digo con Jenkins y SonarQube<\/a>.<\/p>\n

Hemos creado nuestro propio Quallity Profile<\/a> y revisado las reglas de tipo Blockers<\/a> y Criticals<\/a>, todas orientadas a Robustez (fiabilidad) y Seguridad.<\/p>\n

<\/p>\n

La reglas de tipo Major<\/h2>\n

Si vamos a los Majors, comenzamos a tener reglas que afectan el mantenimiento.<\/p>\n

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

Voy a pasar a Minors una serie de buenas pr\u00e1cticas relativas a la legibilidad o la portabilidad del c\u00f3digo, porque no quiero que sea una prioridad. Y pasar a Criticals ciertas reglas Majors que tratan de robustez, rendimiento y seguridad.<\/p>\n

\u00bfPor qu\u00e9? Porque estos defectos afectan al usuario. Un error que interrumpe la aplicaci\u00f3n o la deja en un estado inestable, con una posible corrupci\u00f3n de datos, o con tiempos de procesamiento demasiado largos afectan al usuario, mientras que los defectos en la legibilidad o la capacidad de comprender el c\u00f3digo aumentan el trabajo – y por lo tanto tiempos y costes de mantenimiento – pero sin consecuencias directas para el usuario. Quiero poner este tipo de buenas pr\u00e1cticas en el segundo plano – en Majors o Minors.<\/p>\n

Esto es por supuesto una decisi\u00f3n personal en el contexto de este an\u00e1lisis, y lograr una ‘demo’ que me permitir\u00e1 mostrar a un cliente c\u00f3mo usar y qu\u00e9 beneficios se pueden conseguir con SonarQube. No voy a hacer caso omiso de los defectos que afectan a los costes de mantenimiento, pero no quiero que aparezcan en primera l\u00ednea, prefiero centrarme en violaci\u00f3nes que supongan un riesgo para el usuario final.<\/p>\n

Adem\u00e1s, la mayor parte del c\u00f3digo utilizado para realizar este an\u00e1lisis es bastante antiguo y de una \u00e9poca en que estas buenas pr\u00e1cticas de programaci\u00f3n no estaban conocidas. Los desarrolladores que actualmente mantienen este c\u00f3digo no son los responsables de estos defectos, a pesar de que tienen un gran peso en la deuda t\u00e9cnica .<\/p>\n

Deuda t\u00e9cnica y SQALE<\/h2>\n

Si entramos en la p\u00e1gina Squale, la siguiente pir\u00e1mide muestra que la robustez (Reliabililty – 163 d\u00edas), el rendimiento (Efficiency – 192,5 d\u00edas) y la seguridad (Security – 40 d\u00edas) representan un total de 395,6 d\u00edas de deuda t\u00e9cnica (costes de remediaci\u00f3n de los defectos) o 14,7% de un total de 2 677,2 d\u00edas.<\/p>\n

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

El siguiente diagrama demuestra la importancia que representa el mantenimiento, con 3\/4 de la deuda t\u00e9cnica. Volveremos en un futuro post con este diagrama SQALE Sunburst, y com\u00f3 utilizarlo. Pero podemos ver (segundo c\u00edrculo), como la legibilidad (Readibility) y la comprensibilidad del c\u00f3digo (Understandability) son los dos factores constitutivos de la mantenibilidad. Todas las reglas acerca de la Mantenabilidad (tercer c\u00edrculo, exterior) caen dentro de estos 2 grupos.<\/p>\n

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

La flecha indica que en t\u00e9rminos de Cambiabilidad (Changeability), se necesitan 165,6 d\u00edas de trabajo para asignar un alias a cada columna de las tablas, con el fin de facilitar la comprensi\u00f3n y los desarrollos futuros. Esto es m\u00e1s de un a\u00f1o-hombre, y yo no creo que es realmente el m\u00e1s cr\u00edtico. O al menos no como un defecto que impacta al usuario.<\/p>\n

De hecho, son m\u00e1s de 15 a\u00f1os-hombre para eliminar la deuda t\u00e9cnica debida a la mantenibilidad, aunque no sabemos si esta aplicaci\u00f3n sigue con muchas evoluciones o cual es su duraci\u00f3n futura de vida.<\/p>\n

Entonces, voy a bajar una serie de buenas pr\u00e1cticas relativas a la legibilidad o la portabilidad en Minors, porque no quiero que sea una prioridad. Y a mover Majors relativas a la robustez, el rendimiento o la seguridad a Cr\u00edticals.<\/p>\n

Sin entrar en demasiados detalles, las reglas que suben en Criticals son las siguientes:<\/p>\n