Hemos visto en el articulo anterior las violaciónes ‘Blockers’ a las buenas prácticas de programación ABAP.

Estos defectos son bloqueantes: el código no puede entrar en producción hasta que se realiza una corrección. No se permite ninguna excepción: tolerancia cero, porque el riesgo es demasiado alto de ver una transacción cancelada y que el usuario no pueda realizar el tratamiento deseado.

También hemos configurado nuestro Quality Profile ABAP para identificar defectos críticos, que se centran en el rendimiento, y que vamos a ver en este artículo.

Se me olvidó mencionarlo la última vez, pero mi análisis ABAP representa más o menos 700 programas para 43 000 líneas con 26 000 líneas de código (el resto es comentario). Esto es para dar una idea de la cantidad de defectos con respecto al tamaño de la aplicación.

Los problemas de rendimiento son principalmente el resultado de buenas prácticas no respetadas en los tratamientos SQL. Pues no son específicos de código ABAP. A continuación, podemos ver los más numerosos en la aplicación que he analizado:

Un SELECT * no es una práctica aceptable en todos los lenguajes, porque este query devuelve todas las columnas de la tabla. Si el número de filas devuelto también es importante, el tamaño de los datos transportados por la red probablemente impactará al rendimiento. Además, cuando se agregan nuevas columnas en la tabla, los datos de estas nuevas columnas estarán en el SELECT * aunque no se utilizan.

Un SELECT DISTINCT permite eliminar filas duplicadas. El problema es que este tratamiento es muy pesado en términos de rendimiento, especialmente si algunos de los campos utilizados con la cláusula DISTINCT no tienen indice. Además, debemos asegurarnos de que este tratamiento es útil porque a menudo sucede que no hay filas duplicadas. Finalmente, es posible evitar a menudo este tratamiento con una programación diferente si pensamos bien la cláusula WHERE.

No se recomienda acceder a una base de datos a través de un bucle, especialmente para un tratamiento como INSERT, UPDATE, MODIFY, DELETE. Generalmente, el bucle indica que se lee una tabla o un conjunto de registros para realizar esta actualización. El problema de rendimiento puede ser pequeño para una nueva aplicación con una tabla que contiene pocos registros, pero con el tiempo, los datos se añadirán a esta tabla, el tamaño va a crecer, el bucle se hace más largo y los problemas de rendimiento comienzan a aparecer.

Un SELECT sin condición, es decir, sin cláusula WHERE, devuelve todos los registros en la tabla. A menudo es una indicación de un error de programación (se olvido el WHERE) o una programación incorrecta. Una vez más, a lo largo del tiempo, con más datos en la tabla, este SELECT será la causa de un problema de rendimiento.

Bueno, encontramos en estas reglas criticas una buena práctica que no se relaciona con el rendimiento, pero con la estabilidad de la aplicación. Una sentencia CASE … ENDCASE permite diferentes tratamientos para diferentes valores de una variable o un campo. Es un ‘switch’, La cláusula OTHERS permite gestionar todos los demás casos (todos los otros valores) no tratados específicamente por el CASE. Es una simple cuestión de gestión de errores: si ocurre un evento no previsto, la ausencia de la cláusula OTHERS significa que ningún tratamiento especial se hará. El programa seguirá funcionando, tal vez con valores erróneos o incorrectos. El riesgo es alto de que se produzca un error y que no sea registrado. Además, este error se produce normalmente mucho más lejos en el código, y por lo tanto la detección de su origen es a menudo muy largo y costoso en términos de mantenimiento.
Algunos clientes consideran que esta mala práctica es un bloqueador. Estoy de acuerdo con eso.

Una instrucción UPDATE o DELETE sin una cláusula WHERE significa actualizar o suprimir todas las filas de la tabla. ¡Es mejor asegurarse de que es el tratamiento que se espera y no es un error!

SAP proporciona un sistema tampón o ‘buffer’ que permite leer una tabla directamente desde el buffer y no desde la base de datos, con el objetivo de mejorar el rendimiento. Los tratamientos JOIN o funciones de cálculo que implican una agregación (COUNT, AVG, MAX, MIN, etc.) tienen el efecto de prohibir el uso de este buffer. Y esto, ¡el programador no lo sabe siempre!

Entonces, un tratamiento que no utiliza deliberadamente (bypassing) el ‘buffer’ tendra que ser muy bien justificado!

Por último, utilizar una cláusula LIKE no permite, una vez más, predecir el número de registros devueltos, especialmente cuando la tabla crece con el tiempo. Y las consultas imbricadas (SELECT … IN SELECT …) deben evitarse en todos los lenguajes.

Todavía hay otras normas criticas que no hemos visto, simplemente porque no he encontrado este tipo de defectos en el código que he analizado. Por ejemplo,

• Avoid SQL queries joining on too many tables
• Avoid using GROUP BY in queries

Pero el objetivo no es de enumerar todas las malas prácticas de programación SQL. Tambien tenemos algunas violaciónes críticas específicas de ABAP. Por ejemplo : «Avoid too many functions in function pool».

Un ‘function pool’ es un grupo de funciones utilizadas (llamadas) por un programa. Durante esta llamada, todas las funciones están subidas en memoria, y eso durante toda la vida del programa. Así que más este módulo incluye funciones, más tiempo para cargarlas en la memoria y más espacio ocupan en ella, lo que puede causar problemas de rendimiento. SONAR automáticamente lista todos los grupos con más de 15 funciones.

También tenemos algunas ‘best practices’ que no se relacionan con el rendimiento pero que, al igual que los ‘CASE … OTHERS’, présentan un riesgo para la robustez de la aplicación:

• Forbid use of INSERT/DELETE REPORT/TEXTPOOL
• Forbid use of GENERATE REPORT / SUBROUTINE POOL / DYNPRO

Estas instrucciones están prohibidas porque reservadas para SAP (porque tienen acceso a datos del kernel que pueden desaparecer en futuras versiones).

La regla «Prevent use of EDITOR-CALLS» es una instrucción que llama al editor de texto SAP. Pero esta instrucción no controla los derechos de los usuarios, como es el caso de cualquier transacción ABAP. En otras palabras, el programador puede dar un acceso a alguien que no tenga el correspondiente derecho. Esta declaración se abandona en favor de una otra más controlada.

¿Que justifica que una regla sea de tipo Blocker o Crítico? Se podría considerar que algunas de las violaciónes que hemos comentado en este artículo son lo suficientemente graves como para unirse a la categoría de los bloqueadores. Sí, pero la diferencia es que no vamos a aceptar ninguna excepción para un Blocker, mientras que se puede por un Crítical. Por supuesto, esta excepción debe estar siempre justificada, pero se puede aceptar que este código pasa en producción para tener el tiempo de decidir si una corrección se debe hacer o no.

Terminaremos la proxima vez la presentación de nuestro Quality Profile SONAR con las ultimas reglas ABAP.

 

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