Hemos visto anteriormente los defectos bloqueantes o ‘Blockers’, así llamados porque ninguna violación se puede tolerar, y los defectos ‘Critical’ tan graves que requieren una corrección inmediata, aunque se puede admitir una excepción si se puede justificarla, y eso de manera muy rigurosa.
En nuestro Quality Profile SONAR, los «bloqueadores» se concentran en todo que pueda detener una transacción o un programa y los «críticos» en las prácticas de programación que supongan un riesgo para el rendimiento.
Vamos a concluir esta serie sobre las mejores prácticas de programación ABAP con las reglas restantes, que afectarán principalmente a la capacidad de mantenimiento del código.
Nuestra aplicación ABAP no tiene un tamaño muy grande: un poco menos de 700 archivos para aproximadamente 26.000 líneas, pues un promedio no muy elevado de 40 líneas de código por programa.
La tasa de comentario es correcta, por encima del 22%. También podemos ver un porcentaje significativo de código duplicado.
Pero esto es un promedio que puede reflejar una varianza y por lo tanto realidades muy diferentes. Para comprobar esto, vamos a ver lo que tenemos en los defectos ‘Major’.
Nivel de comentario
Las principales violaciónes de este tipo son métodos, clases, forms, funciones, etc. sin comentarios, junto con una serie de objetos con un nivel de comentarios insuficiente.
Podemos ver que hay un ABAP orientado Objeto con clases y métodos. Este tipo de código no es muy común, pero al menos podemos comprobar que se puede analizar con SONAR.
SONAR también lista:
- Archivos con una densidad de comentarios de menos de 20%.
- Objetos (desarrollados en estos archivos) con una densidad de comentarios de menos de 15%.
El código es fácil de mantener si es comprensible. Más largo y complicado es un programa, más esfuerzo se necesitará para introducir un cambio, y más alto el riesgo de introducir un defecto al mismo tiempo. La presencia de comentarios en el código debe permitir al desarrollador comprender más fácilmente la lógica del programa, las evoluciones o correcciones anteriores y por lo tanto minimizar los costes de mantenimiento y los riesgos para la estabilidad de la aplicación.
Código duplicado
También tenemos 58 programas, un poco más de 8% del total, con código duplicado.
Código duplicado es código ‘Copiado-Pegado’. Un programador debe implementar una nueva función, un tratamiento ya codificado en un otro fichero (generalmente por el mismo), por lo que le resuelta más fácil reproducirlo tantas veces como sea necesario.
Esta mala práctica es ciertamente más peligrosa que un nivel de comentario insuficiente, porque cualquier cambio en uno de estos bloques de código duplicado debe introducirse en todas sus copias, o la a que se olvida dejará de funcionar correctamente. Esto multiplica el número de todos los cambios que hacer, sabiendo por supuesto que es imposible recordar todas las duplicaciones. El esfuerzo de mantenimiento es mucho mayor, y lo más importante, el riesgo de introducir un defecto es muy alto.
Se recomienda corregir estas violaciónes tan pronto como sea posible, y reemplazar los bloques de código duplicados por funciones reutilizables.
Estructura de código
Un código incorrectamente estructurado es difícil de leer.
Aquí tenemos tratamientos de tipo CASE (para más detalles sobre esta instrucción, puedes ver el post sobre los defectos criticos o ‘Critical’) que tien uno o más ‘caminos’ WHEN con varias líneas de código, lo que significa que el desarrollador ha programado un procesamiento lógico en una estructura condicional. Si el tratamiento tiene múltiples lineas (más de 4 regla por defecto), se recomienda encapsularlo en una función que será llamada por el WHEN.
SONAR identifica un procesamiento condicional imbricado, como un IF con 3 o más niveles, Introducir un cambio en una tal estructura requiere un esfuerzo significativo para entender la lógica, pues de nuevo más costes de mantenimiento y mayor riesgo de error.
Lo mismo ocurre con las expresiones condicionales complejas, con más de 4 AND u OR. A continuación se muestra un ejemplo de código proporcionado por SONAR para ilustrar esta regla.
Tamaño y complejidad
Otros defectos importantes que se pueden encontrar en una aplicación ABAP, aunque pocos en la que hemos analizado: los programas grandes o con demasiados objetos.
La complejidad también supone un riesgo para el mantenimiento de una aplicación.
De hecho, casi no hay ningún objeto con un nivel significativo de complejidad en esta aplicación. Es normal porque es un código que utilizo para hacer demo, no es una apliación real.
Conclusión
Recuerdas que estas son sólo algunas reglas de tipo ‘Major’ encontradas en el código analizado. Hay muchas otras en el Quality Profile ABAP de Sonar. Probablemente volveremos en el futuro con una oportunidad de examinarlas, en relación con otros artículos sobre el mundo ABAP.
Equipos de proyecto, gerentes de aplicaciones SAP o stakeholders suelen pensar que SONAR, porque es Open Source, sabe trabajar solamente con las nuevas tecnologías J2EE. De hecho, hemos visto a través de esta serie de posts que es fácil y rápido realizar análisis de código ABAP con SONAR, e implementar procesos – un Quality Gate, por ejemplo – que puede detectar riesgos para la robustez y el rendimiento al mismo tiempo que controla los costes de mantenimiento.
Esta entrada está disponible también en Lire cet article en français y Read that post in english.