{"id":247,"date":"2013-01-28T15:51:10","date_gmt":"2013-01-28T14:51:10","guid":{"rendered":"http:\/\/qualilogy.com\/es\/?p=247"},"modified":"2013-01-28T17:08:12","modified_gmt":"2013-01-28T16:08:12","slug":"buenas-practicas-de-programacion-abap-los-defectos-critical","status":"publish","type":"post","link":"http:\/\/qualilogy.com\/es\/buenas-practicas-de-programacion-abap-los-defectos-critical\/","title":{"rendered":"Buenas pr\u00e1cticas de programaci\u00f3n ABAP – Los defectos ‘Critical’"},"content":{"rendered":"

\"Qualilogy<\/a>Hemos visto en el articulo anterior las violaci\u00f3nes ‘Blockers’ a las buenas pr\u00e1cticas de programaci\u00f3n ABAP<\/a>.<\/p>\n

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

Tambi\u00e9n hemos configurado nuestro Quality Profile ABAP para identificar defectos cr\u00edticos, que se centran en el rendimiento, y que vamos a ver en este art\u00edculo.<\/p>\n

\"Mon<\/a> Se me olvid\u00f3 mencionarlo la \u00faltima vez, pero mi an\u00e1lisis ABAP representa m\u00e1s o menos 700 programas para 43 000 l\u00edneas con 26 000 l\u00edneas de c\u00f3digo (el resto es comentario). Esto es para dar una idea de la cantidad de defectos con respecto al tama\u00f1o de la aplicaci\u00f3n.<\/p>\n

Los problemas de rendimiento son principalmente el resultado de buenas pr\u00e1cticas no respetadas en los tratamientos SQL. Pues no son espec\u00edficos de c\u00f3digo ABAP. A continuaci\u00f3n, podemos ver los m\u00e1s numerosos en la aplicaci\u00f3n que he analizado:<\/p>\n

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

Un SELECT * no es una pr\u00e1ctica aceptable en todos los lenguajes, porque este query devuelve todas las columnas de la tabla. Si el n\u00famero de filas devuelto tambi\u00e9n es importante, el tama\u00f1o de los datos transportados por la red probablemente impactar\u00e1 al rendimiento. Adem\u00e1s, cuando se agregan nuevas columnas en la tabla, los datos de estas nuevas columnas estar\u00e1n en el SELECT * aunque no se utilizan.<\/p>\n

Un SELECT DISTINCT permite eliminar filas duplicadas. El problema es que este tratamiento es muy pesado en t\u00e9rminos de rendimiento, especialmente si algunos de los campos utilizados con la cl\u00e1usula DISTINCT no tienen indice. Adem\u00e1s, debemos asegurarnos de que este tratamiento es \u00fatil porque a menudo sucede que no hay filas duplicadas. Finalmente, es posible evitar a menudo este tratamiento con una programaci\u00f3n diferente si pensamos bien la cl\u00e1usula WHERE.<\/p>\n

No se recomienda acceder a una base de datos a trav\u00e9s 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\u00f3n. El problema de rendimiento puede ser peque\u00f1o para una nueva aplicaci\u00f3n con una tabla que contiene pocos registros, pero con el tiempo, los datos se a\u00f1adir\u00e1n a esta tabla, el tama\u00f1o va a crecer, el bucle se hace m\u00e1s largo y los problemas de rendimiento comienzan a aparecer.<\/p>\n

Un SELECT sin condici\u00f3n, es decir, sin cl\u00e1usula WHERE, devuelve todos los registros en la tabla. A menudo es una indicaci\u00f3n de un error de programaci\u00f3n (se olvido el WHERE) o una programaci\u00f3n incorrecta. Una vez m\u00e1s, a lo largo del tiempo, con m\u00e1s datos en la tabla, este SELECT ser\u00e1 la causa de un problema de rendimiento.<\/p>\n

Bueno, encontramos en estas reglas criticas una buena pr\u00e1ctica que no se relaciona con el rendimiento, pero con la estabilidad de la aplicaci\u00f3n. Una sentencia CASE … ENDCASE permite diferentes tratamientos para diferentes valores de una variable o un campo. Es un ‘switch’, La cl\u00e1usula OTHERS permite gestionar todos los dem\u00e1s casos (todos los otros valores) no tratados espec\u00edficamente por el CASE. Es una simple cuesti\u00f3n de gesti\u00f3n de errores: si ocurre un evento no previsto, la ausencia de la cl\u00e1usula OTHERS significa que ning\u00fan tratamiento especial se har\u00e1. El programa seguir\u00e1 funcionando, tal vez con valores err\u00f3neos o incorrectos. El riesgo es alto de que se produzca un error y que no sea registrado. Adem\u00e1s, este error se produce normalmente mucho m\u00e1s lejos en el c\u00f3digo, y por lo tanto la detecci\u00f3n de su origen es a menudo muy largo y costoso en t\u00e9rminos de mantenimiento.
\nAlgunos clientes consideran que esta mala pr\u00e1ctica es un bloqueador. Estoy de acuerdo con eso.<\/p>\n

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

Una instrucci\u00f3n UPDATE o DELETE sin una cl\u00e1usula WHERE significa actualizar o suprimir todas las filas de la tabla. \u00a1Es mejor asegurarse de que es el tratamiento que se espera y no es un error!<\/p>\n

SAP proporciona un sistema tamp\u00f3n 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\u00e1lculo que implican una agregaci\u00f3n (COUNT, AVG, MAX, MIN, etc.) tienen el efecto de prohibir el uso de este buffer. Y esto, \u00a1el programador no lo sabe siempre!<\/p>\n

Entonces, un tratamiento que no utiliza deliberadamente (bypassing) el ‘buffer’ tendra que ser muy bien justificado!<\/p>\n

Por \u00faltimo, utilizar una cl\u00e1usula LIKE no permite, una vez m\u00e1s, predecir el n\u00famero de registros devueltos, especialmente cuando la tabla crece con el tiempo. Y las consultas imbricadas (SELECT … IN SELECT …) deben evitarse en todos los lenguajes.<\/p>\n

Todav\u00eda hay otras normas criticas que no hemos visto, simplemente porque no he encontrado este tipo de defectos en el c\u00f3digo que he analizado. Por ejemplo,<\/p>\n