Tercer artículo de nuestra serie sobre la creación de métricas personalizadas, y por qué la capacidad de definir sus propias métricas en una herramienta de análisis de código no es el factor importante que muchos piensan.

Ya vimos en el primer artículo que las métricas más fáciles de crear no eran las más numerosas y en el segundo en esta serie que las métricas más importantes e interesantes son también las más complejas de implementar, a veces (o a menudo) imposibles.

En este post, vamos a ver este tema de la personalización en términos de tecnología de aplicación, antes de un artículo final donde podremos resumir todo e identificar todas las preguntas correctas. 

Métricas personalizadas y tecnologías

Cuando se me pregunta si es posible crear métricas con una herramienta de análisis de código, mi repuesta es «¿Por qué?». En la mayoría de los casos, no tengo respuestas muy precisas, lo que obviamente no es una buena señal en cuanto a la existencia de una necesidad real.

La pregunta más específica es en realidad: «¿Para qué tecnologías?».

Java

Java es el lenguaje más utilizado en las empresas y en la mayoría de las aplicaciones. Las buenas prácticas de programación son bien conocidas, y más que bien estandarizadas. Claro, hay puristas que debaten si el uso de una tal instrucción en particular constituye una violación de las buenas prácticas, pero seamos serios, todos están de acuerdo en la métricas más importantes.

Las reglas correspondientes existen ya desde años, en muchas herramientas, y se integran fácilmente (SonarQube sabe cómo trabajar con FindBugs, PMD, Checkstyle por ejemplo). De hecho, hay muchas herramientas que incorporan tantas reglas que puedes especializar tu modelo qualimétrico de acuerdo a tus prioridades:

• Aplicaciones nuevas y críticas: quieres ir a la caza de errores posibles para ofrecer aplicaciones robustas y eficientes, y reducir los problemas de los usuarios.
• Aplicaciones viejas y probadas: algunos problemas y retrasos en la nueva versión no son deseable, pero tu prioridad es controlar los costes de mantenimiento y el presupuesto. Eliges las buenas prácticas de programación que afectan al mantenimiento de las aplicaciones.

Por lo tanto, entiendes que, en mi opinión, no hay ninguna razón para establecer tus propias normas de Java, a menos que quieres divertirte, por supuesto, y jugar al gurú.

Otras nuevas tecnologías

Para otras nuevas tecnologías, quiero decir lenguajes distintos del Java como C++, C# o ,NET, etc. Debo decir que yo no soy un experto en ellos, pero aún analicé algunas aplicaciones de este tipo (no son mis favoritas, la verdad), y sé que la mayoría de las normas de calidad de esas aplicaciones son bastante cerca de las que encontramos en Java. Es decir, un IF es un IF y un bucle es un bucle, por lo que vamos a encontrar las mismas buenas prácticas para la estructuración de código, por ejemplo. Luego, claro que siempre hay en todos los lenguajes instrucciones específicas que se recomienda no utilizar.

También creo que la oferta en términos de herramientas y ‘repositorio’ de normas de calidad es cada vez más importante para estas tecnologías. Así que los principios antes mencionados con respecto a la personalización de las normas para Java son aplicables aquí: no reinventar la rueda.

Frameworks

De hecho, existe sólo un caso aceptable en mi opinión: los frameworks propietarios. Imaginamos que trabajas en una arquitectura SOA con un middleware desarrollado y mantenido por la empresa, que encapsula consultas a tratamientos Cobol Mainframe o a cualquier ERP. Evidentemente, es deseable que todos utilizan el framework y que nadie desarrolla su tratamiento sin respetar esa arquitectura.

Cuando se cambia un programa llamado en la capa SOA y los parámetros de esas llamadas, se modifica el framework – las APIs para este programa – para que las aplicaciones sigan funcionando. Pero si alguien ha hecho un pequeño programa en su rincón, habrá que identificarlo y cambiarlo (o volver a escribirlo utilizando el framework). Suponiendo que recordamos de la existencia de este programa, y que se encuentra también al autor. Sino, será mas caro cambiarlo.

Otros casos no tan inusuales: es increíble la cantidad de empresas que han desarrollado su propia versión de Struts o Hibernate. De acuerdo, la mayoría son empresas de servicios que han utilizado estos frameworks propietarios en el desarrollo de aplicaciones para sus clientes, asegurándose así contratos de mantenimiento de estas aplicaciones por toda la vida. He visto portafolios de aplicaciones Java con hasta 3 o 4 frameworks propietarios diferentes.

Así pues, en este caso, es aceptable asumir el coste de la personalización de métrica para asegurarse de que se utiliza el framework. También es necesario que estas reglas sean posibles de implementar. ¿Cómo identificar un tratamiento que no utiliza las instrucciones u objetos de un framework? En el mejor de los casos, se debe identificar todas las instrucciones que tendrán acceso a la capa SOA, en nuestro ejemplo anterior, o a la capa de datos para un framework tipo Hibernate. Y que estas instrucciones se encuentran en el código del desarrollador, y no del framework o de algún objeto del framework instanciado por el desarrollador.

Es terriblemente complicado, y hay que trabajar en el árbol sintáctico (Abstract Tree Metric) y con herramientas y habilidades bastante avanzadas. El coste de crear y mantener esas reglas será bastante alto.

Incluso el coste de utilización de estos indicadores personalizados puede ser importante en el caso de falsos positivos, bastante probable. Me acuerdo de una métrica que verificaba que cada página JSP o HTML estaba asociada a una página de error. Pero la relación con esta página no siempre es sencilla, y a veces pasa por un objeto Struts, a veces por un componente específico de control de errores, etc. Lo primero que yo hacía siempre era de comprobar esta métrica. Por supuesto, si se anuncia a un equipo J2EE que mal maneja lo errores, mientras que el error es tuya … Mal momento de gran soledad.

L4G

Sin detallar lo que llamo un L4G (lenguaje de cuarta generación), digamos las tecnologías de tipo Cliente-Servidor que florecieron en los años 80 y 90: SQLWindows, PowerBuilder, Delphi, NS/DK (en Francia), etc.

Todavía hay algunas aplicaciones con estos lenguajes, y frecuentemente se piensa hacer una migración a otra tecnología, pero nunca se hace. Después de todo, si funciona …

No hay muchas herramientas de análisis de código que cubren estos lenguajes porque no hay bastante demandas de los clientes para que un editor de software toma la pena realizar una inversión, a menos que un cliente sea dispuesto en pagar por el desarrollo. Pues, estos clientes ya tienen suficientes problemas para revisar las reglas más básicas y entonces la personalización de nuevas reglas no es una prioridad.

La única puede estar en un lenguaje como Oracle Forms que todavía está bastante utilizado.. Depende un poco de qué parte del mundo hablamos, siempre me sorprende cómo algunas herramientas son muy utilizadas en algunos países y no en absoluto en otras regiones. Pero todavía hay un montón de grandes portafolios y aplicaciones críticas en Oracle Forms. Sin embargo, sus dueños también suelen conformarse con tener buenos indicadores antes de pensar en el desarrollo de nuevas reglas.

Cobol

COBOL es uno de los lenguajes más normalizados con Java. Eso tiene sentido, teniendo en cuenta que Sun, al origen de la plataforma Java, e IBM, un proveedor líder de hardware y software en el mundo mainframe, siempre han proporcionado publicaciones sobre la calidad del código. Pues las reglas en esta área son bien conocidas y estandarizadas. En el peor de los casos, una regla Cobol no se aplica, y se puede desactivar en la herramienta de análisis de código. Hemos encontrado unos ejemplos anteriormente en este post: ‘Tu proprio modelo de calidad‘.

A mí me pasó una o dos veces encontrar una empresa que había desarrollado una norma específica que no correspondía a una norma existente. Por ejemplo: sabemos que un programa Cobol comporta diferentes secciones y parágrafos, equivalente a procedimientos o funciones reutilizables en el programa mismo. Un cliente había hecho una regla según la cual no era posible llamar a un tratamiento (un parágrafo) si no había sido declarado y programmado previamente (antes de la llamada). La regla se justifica, y es posible implementarla con una expresión regular. Y el cliente insistió, así que …

SAP

A diferencia del caso anterior, SAP nunca ha sido un especialista en calidad del código. La prioridad es vender nuevas versiones, no estabilizar el código ABAP existente. Incluso sucedió que SAP recomienda el uso de instrucciones que representan un riesgo para el rendimiento o la fiabilidad de la aplicación.

Así que muchas, si no todas las empresas con aplicaciones ABAP tienen una lista de buenas prácticas de programación. A menudo nos encontramos con los principales estándares existentes, pero no siempre en la misma forma. Por ejemplo, una norma estipula usar y probar siempre el código de retorno después de una llamada a otro tratamiento. Pero a veces, esta regla puede definirse en una empresa con más precisión respecto al valor del código de retorno, que debe corresponder a, por ejemplo: 0 = sin error, 1 = error de este tipo, … X = errror de tipo X, … En tal caso, es probable que se necesita desarrollar una métrica más avanzadas que la que ya existe, que no sólo verifica la presencia de un código de retorno, sino también su valor.

También conocerás normas en la herramienta de análisis de código que el cliente no tiene en su libro de reglas, y tendrás que consultar si presentan interés para él. A menudo si las interesan, pero no siempre hasta modificar su lista de normas. Esto es normal: va a tener que explicar a todos sus proveedores que no trabajan bien desde hace años sin que nadie lo sepa. Y también es en el mundo ABAP mundo que encontrarás las reglas más complejas o imposibles de automatizar.

Así que en resumen:

• Java y nuevas tecnologías: a menos que quieras jugar al químico loco inventando tus propias recetas, es difícil justificar la necesidad de nuevas métricas, excepto si …
• Frameworks: pero cuidado, los costes de desarrollo, mantenimiento e incluso de uso de métricas personalizadas para un framework propietario serán altos, muy altos.
• Otros lenguajes tipo L4G: poca o ninguna demanda.
• Cobol: lo mismo, pero a menudo tendrás que realizar un trabajo de personalización del modelo cualimétrico.
• SAP ABAP es probablemente el único lenguaje para el que la personalización de métricas puede justificarse. Pero, no todas reglas se pueden automatizar y son las más complejas de implementar.

La creación de nuevas métricas es a menudo de mayor coste de lo que pensamos. El próximo post nos permitirá identificar cuáles son los costes ocultos y resumir todas las preguntas que se debe hacer con el fin de evaluar mejor la necesidad real y el retorno de la inversión.

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