Después de una interrupción debido a la reorganización del blog – espero que disfrutáis de la nueva interfaz – vamos a seguir con la serie sobre análisis de código ABAP.
Hemos visto la última vez cómo configurar nuestro primer análisis de código ABAP con Sonar y Jenkins.
Esta semana, vamos a examinar las primeras reglas ABAP, las más importantes cuando se trata de buenas prácticas de programación.
Los dolores en el mundo ABAP
¿Cuáles son los defectos más temidos por la mayoría de las empresas? ¿Cuáles son las malas prácticas de programación que representan el mayor riesgo para su negocio? ¿Cuáles son las principales preocupaciones de los responsables del proyecto y de los stakeholders? En pocas palabras, ¿cuáles son los dolores en el mundo ABAP?
- Cualquier cosa que pueda detener una transacción.
- Cualquier cosa que pueda afectar al rendimiento.
No olvides que SAP es un software financiero, y un error en el proceso de una operación significa, al mejor un retraso y en el peor caso, una pérdida financiera, y en todos los casos una degradación de la imagen. Si ni siquiera eres capaz de realizar una factura correctamente, de editar un orden o de administrar un inventario sin error, ¿cómo quieres que alguien tenga confianza en tu empresa, tus productos, tus empleados.
Quality Profile
Así que voy a crear en SONAR un Quality Profile o perfil de calidad un poco diferente del que viene con el plugin ABAP, para promover las reglas más importantes en términos de robustez y rendimiento.
Para hacer esto, voy a conectarme como ‘Admin’ en Sonar, y configurar un nuevo Quality Profile. No voy a precisar los detalles de esta operación, ya debes saber hacerlo, y si no, es muy intuitivo. También puedes ver este post ‘Quality Profile’, que trata de la creación de un Quality Profile para reglas Cobol, pero el procedimiento es el mismo.
Aquí está el resultado:
He creado un ‘ABAP JPF Profile’ que consta de 51 reglas. He activado 11 reglas ABAP que simplemente eran opcionales en el Quality Profile ‘Sonar way’, porque no son habitualmente utilizadas por todos los clientes. Pero me parecen interesantes, son útiles en el contexto de una auditoría, y si un equipo de proyecto me dice que no forman parte de su modelo de calidad, pues siempre será posible desactivarlas o degradar su criticidad.
Control de errores
Luego inicio un análisis del código que utilizo para hacer demos. Estas son las principales reglas Blockers en SONAR.
Dos reglas permiten identificar una gestión incorrecta de errores: ‘Avoid calling a function module without handling exceptions’ y ‘Handle error codes when using CALL-FUNCTION’.
Los errores suceden, nadie es inmune a un algoritmo erróneo, un caso no previsto, etc. Un tratamiento sin gestión de excepciones significa una interrupción del tratamiento, y por lo tanto de la transacción correspondiente. El usuario no puede terminar la operación, con todas las consecuencias imaginables: corrupción de datos, ‘pantalla vacia’, etc. En el peor de los casos, no se dará cuenta de que ha ocurrido un error.
La segunda regla identifica una llamada a una función cuyo código de retorno no se procesa. Esto no es correcto en todos los idiomas, e indica una mala práctica bastante común. La mayoría de las aplicaciones ABAP se subcontratan a proveedores externos, a veces offshore, y no sabes cuál es el nivel de conocimiento de sus equipos. Así que si tienes tratamientos sin gestión del código de retorno, se prohibe poner este programa en producción y se pide al proveedor que inmediatamente corrige este defecto.
Y que forma sus programadores a esta buena práctica, si encuentras un gran número de esos defectos. Incluso cuando esta regla es conocida, la falta de atención es siempre posible que causará tales violaciónes.
La prueba del código de retorno se realiza a través del parámetro ‘SY-SUBRC’, como se puede ver al observar el defecto en la línea de código.
¿Cómo? Olvidé decir que puedes ir a la línea de código donde se encuentra la violación? Sí, no necesitas buscar un error dentro de cientos de líneas de código, SONAR te llevará allí inmediatamente. Es útil cuando se trata de comprobar el error, o para el programador que tiene que hacer la corrección.
Achtung Verboten !
Las otras dos normas se refieren a instrucciones estrictamente prohibidas.
‘Forbid use of SYSTEM-CALL’ identifica una llamada al núcleo de SAP. Está absolutamente prohibido porque despues de una actualización de SAP (lo que ocurre muy a menudo), el tratamiento llamado en SAP puede desaparecer y con ello el programa dejará de funcionar.
Esta regla es bien conocida, y no he encontrado ningún violación en el código ABAP que tengo. Así que creé mi propio programa ‘Z_SYSTEM_CALL’, con 38 ejemplos de esta instrucción, todos con una sintaxis diferente.
Y puedo ver en la lista anterior de los Blockers en mi análisis que SONAR ha reconocido estas 38 sintaxis sin falsos positivos.
La instrucción ‘BREAK-POINT’ tiene el efecto de interrumpir un programa inmediatamente. En realidad, es utilizado para depurarlo. Su presencia en el código significa simplemente que el programador se olvidó de quitarla una vez que su desarrollo se ha completado. Si quieres darle verguenza a un outsourcer, muestrale un ‘BREAK-POINT’ en la versión que el acaba de entregar. Por lo general, encuentro 1 o 2 (o más) en cada aplicación.
Todos los Blockers que hemos visto corresponden a reglas con cero tolerancia. Deben corregirse de inmediato esos defectos, no se permite ninguna excepción y el código no se instalará en producción. Algunos pueden considerar que una gestión incorrecta de excepciones es ciertamente grave, pero no bloqueante, pero no es el caso a menudo. La gestión del código de retorno es en los 5 primeros Blockers de la mayoría de los clientes que conozco.
Veremos en el próximo post las reglas críticas, principalmente sobre el rendimiento.
Esta entrada está disponible también en Lire cet article en français y Read that post in english.