Continuamos esta serie en el análisis de código PL/SQL con hoy las normas de tipo Majors.

Vimos antes cómo organizar nuestro entorno y configurar nuestro análisis de código con Jenkins y SonarQube.

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

La reglas de tipo Major

Si vamos a los Majors, comenzamos a tener reglas que afectan el mantenimiento.

Voy a pasar a Minors una serie de buenas prácticas relativas a la legibilidad o la portabilidad del código, porque no quiero que sea una prioridad. Y pasar a Criticals ciertas reglas Majors que tratan de robustez, rendimiento y seguridad.

¿Por qué? Porque estos defectos afectan al usuario. Un error que interrumpe la aplicación o la deja en un estado inestable, con una posible corrupción 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ódigo 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ácticas en el segundo plano – en Majors o Minors.

Esto es por supuesto una decisión personal en el contexto de este análisis, y lograr una ‘demo’ que me permitirá mostrar a un cliente cómo usar y qué 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ínea, prefiero centrarme en violaciónes que supongan un riesgo para el usuario final.

Además, la mayor parte del código utilizado para realizar este análisis es bastante antiguo y de una época en que estas buenas prácticas de programación no estaban conocidas. Los desarrolladores que actualmente mantienen este código no son los responsables de estos defectos, a pesar de que tienen un gran peso en la deuda técnica .

Deuda técnica y SQALE

Si entramos en la página Squale, la siguiente pirámide muestra que la robustez (Reliabililty – 163 días), el rendimiento (Efficiency – 192,5 días) y la seguridad (Security – 40 días) representan un total de 395,6 días de deuda técnica (costes de remediación de los defectos) o 14,7% de un total de 2 677,2 días.

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

La flecha indica que en términos de Cambiabilidad (Changeability), se necesitan 165,6 días de trabajo para asignar un alias a cada columna de las tablas, con el fin de facilitar la comprensión y los desarrollos futuros. Esto es más de un año-hombre, y yo no creo que es realmente el más crítico. O al menos no como un defecto que impacta al usuario.

De hecho, son más de 15 años-hombre para eliminar la deuda técnica debida a la mantenibilidad, aunque no sabemos si esta aplicación sigue con muchas evoluciones o cual es su duración futura de vida.

Entonces, voy a bajar una serie de buenas prácticas 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íticals.

Sin entrar en demasiados detalles, las reglas que suben en Criticals son las siguientes:

• EXCEPTION – Catch all exceptions with WHEN OTHERS
• GOTO – Avoid use of GOTO statements
• IF – Avoid nested if statements. Esta regla se refiere a la mantenabilidad, pero me parece lo suficientemente grave como para justificar su promoción a Criticals. También puede afectar, en cierta medida, la robustez de la aplicación, ya que favorece el riesgo de errores de lógica.
• LOOP – Avoid simple loops of the form LOOP … END LOOP
• LOOP – Avoid using EXIT from within a FOR or WHILE loop
• RETURN – Avoid using RETURN from within a loop
• SQL – Avoid nested subqueries (queries in the WHERE clause)

Voy a pasar en Blockers las siguientes reglas:

• SQL – Avoid using the GROUP BY clause
• SQL – Avoid using UNION (celle-ci est de type Info).
• SQL – Do not join on more than X tables
• SQL – SELECT * should not be used

porque impactan el rendimiento de manera significativa. También son reglas SQL que se aplican a todas las tecnologías (Cobol, ABAP, etc.). De hecho, estas reglas no tienen defectos en esta aplicación, así que son conocidas por los desarrolladores.

No será el caso para otros lenguajes, especialmente en ABAP: el conocimiento de las mejores prácticas de SQL no es un punto fuerte de los equipos de proyectos SAP.

Las reglas principales que bajamos a Minors:

• FORMAT – Do not use more that one statement per line
• LITERALS – Avoid using magic numbers
• LITERAL – Avoid new-line or control characters in string literals
• SQL – Columns should be aliased
• SQL – Introduce column aliases using the AS keyword
• SQL – Prefer EXECUTE IMMEDIATE to DBMS_SQL’s package procedure calls
• SQL – Tables should be aliased
• SQL – Use standard ANSI syntax instead of old syntax for join queries

Nota: yo suelo hacer este estudio para cada nuevo cliente, sobre la base de sus propias reglas. El plug-in SQALE de SonarQube es una gran ayuda para hacer esto. Después de esta asignación, en nuestro propio perfil de calidad, la asignación de las normas de acuerdo a su criticidad ahora parece más equilibrada:

El número de Blockers no ha cambiado: las reglas que hemos pasado en esta categoría son claramente conocidas y respetadas por el equipo de proyecto.

La deuda técnica atribuible a Criticals se ha incrementado, pero queda relativamente limitada: debe ser posible corregir estos defectos durante el ciclo de vida del proyecto, o con un proyecto específico de remediación que no requiere una gran inversión.

El número de Majors ha disminuido con algunas reglas que han pasado a Criticals o que fueron rebajadas a Minors. La mayor parte de estas normas Majors están dirigidas a mantenibilidad, y un cliente puede decidir tomar en cuenta la totalidad o cualquier parte de esta deuda técnica, de acuerdo con su propia orientación TI:

• Evitar errores para los usuarios de esta aplicación.
• Reducir los costes de mantenimiento, en función de la duración de vida de la aplicación, de la frecuencia de cambios, de los presupuestos, etc.

El plugin SQALE proporciona una ayuda muy interesante para la adaptación de un Quality Profile,  basandose en las necesidades del cliente. Se debe entender que el Perfil de Calidad ofrecido por defecto con SonarQube para cada tecnología es una base de trabajo y no un conjunto de normas gravadas en el mármol. Es el papel del consultor de Calidad de calificar la orientación TI de cada cliente, para realizar un Quality Profile específico a sus necesidades, de modo que se puede construir un plan de acción realista, que permite una gestión optimal de la deuda técnica.

Probablemente tendremos la oportunidad de realizar en el futuro un post, y probablemente más de uno, para este plugin SQALE.

Esta entrada está disponible también en Lire cet article en français y Read that post in english.