Hoy terminamos nuestra evaluación de la calidad del código Cobol analizado con el Sonar.
En el post anterior, hemos trabajado con las métricas que medían el tamaño del código, su complejidad, el nivel de documentación y de duplicación, lo que nos permitió formular algunas primeras recomendaciones a los responsables de esta aplicación. Sigue leyendo
La calidad de código de las aplicaciones es una preocupación constante desde siempre. Las malas prácticas de programación son responsables de defectos que impactan a los usuarios y los costes de mantenimiento. La Deuda Técnica, simple metáfora al principio, se ha convertido en una herramienta para medir la calidad y estos costes.
Unos cuantos años antes, los softwares que permiten la identificación de estos defectos eran raros y costosos. Hoy en día, herramientas Open Source tales como Sonar permiten que todos – equipos de proyectos, proveedores, consultores de Calidad, etc. – puedan detectar de manera sencilla y a buen precio estas malas prácticas.
El mundo Open Source ha sufrido durante mucho tiempo de una imagen de ‘geek’, porque primero fueron los entusiastas del mundo J2EE que utilizaron estas herramientas. Pero los tiempos cambian y ahora es posible analizar código Legacy como Cobol y ABAP con Sonar.
Este es el objetivo de nuestra serie de posts: demostrar que es posible evaluar la calidad de las aplicaciones Cobol sin saber nada del mundo Mainframe. Sigue leyendo
Una regla se conoce o no. Una ‘best practice’ se aplica o no. Pero si no se aplica, ¿es porque no es aplicable o porque no es conocida?
Debes presentar los resultados de tus primeros análisis Cobol y, por supuesto, quieres demostrar el valor de estos análisis a los equipos de proyectos, proveedores, stakeholders, etc.
Esto requiere la definición de un modelo de medición de la calidad – un conjunto de reglas y niveles de criticidad – que permite la rápida identificación de las malas prácticas más costosas y peligrosas. Obviamente sería un fracaso denunciar una violación a una ‘mejor práctica’ que no está aplicable – por ejemplo, el uso de SQL (ver. nuestro último post).
¿Cuáles son las reglas aplicables? ¿Cuál de los umbrales de severidad elegir? Cómo ajustar el modelo de Calidad en un Quality profile Sonar para las aplicaciones Cobol ?
Vamos a mostrar en este post cómo configurar tu propio modelo calidad, con una View Sonar y un widget muy útil. 
Sigue leyendo
Los posts anteriores sobre la preparación y el análisis de código Cobol con Sonar y Jenkins provocaron unos comentarios preocupados por los resultados de análisis y las normas disponibles en el dashboard Sonar.
¿Permiten estos resultados una evaluación de la calidad de las aplicaciones Cobol? ¿Qué valor podemos entregar a los equipos y el management? Y para aquellos que no están familiarizados con el mundo Mainframe, ¿cuáles son las ‘mejores / peores prácticas’ para el código Cobol?
Muchas preguntas, y no vamos a poder responder a todas en un único post. Vamos a dedicar este a la presentación de las diferentes normas y los defectos de calidad que se encuentran frecuentemente en las aplicaciones Cobol.
El objetivo es: has hecho un análisis, los resultados aparecen en el dashboard Sonar. Ahora, ¿por dónde empezar? Sigue leyendo
Hemos visto en el post anterior cómo crear un análisis de código Cobol con Sonar y Jenkins.
En realidad, no hemos utilizado todas las reglas Cobol disponibles en Sonar. ¿Por qué? Debido a que algunas reglas están desactivadas, ya que se usan solamente en un contexto determinado y entonces requieren alguna configuración. Por ejemplo, las reglas de nomenclatura no están estandarizadas en Cobol, y con frecuencia serán diferentes entre departamentos o incluso entre equipos del mismo departamento.
Así que necesitamos gestionar diferentes modelos de calidad, es decir diferentes conjuntos de normas según el proyecto. Sonar lo permite gracias a los ‘Quality profiles’ que incluyen las reglas activadas durante un análisis de código.
Vamos a ver en este post, cómo crear un nuevo perfil con todas las normas de calidad Cobol, y asignarlo a un proyecto existente. Sigue leyendo
Continuamos nuestra serie sobre el análisis de código Cobol, con el objetivo de demostrar que es simple y fácil de iniciar un proceso de evaluación de la calidad de este código Legacy, sin ser un experto en este idioma.
Ya tienes una plataforma de análisis de código, con Sonar y Jenkins. Si no es el caso, una serie anterior de post explica cómo instalar estas herramientas:
en nuestro entorno.
Analizas código Java o .NET con esta plataforma y se te pide hacer lo mismo con aplicaciones Cobol. El problema: no conoces nada del mundo Mainframe. ¡Qué lío!
No, nada de pánico. Nuestros dos posts anteriores explicaban:
Ahora ha llegado el momento: vamos a ver como implementar el proceso de análisis en nuestra plataforma Sonar-Jenkins. Let’s play. Sigue leyendo
Hemos visto la semana pasada lo que había que saber sobre Mainframe Cobol, antes de entrar en una reunión con los especialistas de esta tecnología y preparar un proceso de análisis con Sonar.
Vamos ahora a examinar las cuestiones para organizar los análisis con Sonar (que veremos en un artículo próximo).
Estas cuestiones también nos permitirán precisar las reglas de entrega del código fuente.
Hice unos cuantos posts hace unos meses (Sonar – Análisis Cobol con Jenkins, Open Source & código Legacy) con el fin de demostrar que no es necesario ser un gurú de J2EE o un experto Open Source para analizar aplicaciones Legacy de Cobol (o ABAP) con Sonar y Jenkins.
Y veo bastante visitantes llegando a estas páginas a mi blog, lo que refleja el interés por este tema.
Pero alguien me dijo recientemente: «Estamos analizando código J2EE regularmente con Sonar, y todo va de maravilla. También tenemos planes para poner las aplicaciones Cobol en Sonar y Jenkins, pero no sé nada del mundo del mainframe».
Por lo tanto, este post (y los siguientes) tendrá como objetivo ayudar a la implantación de un proceso de análisis de código Cobol con Sonar y Jenkins.
Hacé ya bastante tiempo que no hablé de Sonar. He sido ocupado un poco recientemente descubriendo nuevos territorios (ver los posts Elasticidad del código, La calidad en el Cloud) y me retrasé en poner al día mi entorno Sonar. Por otra parte, hay una nueva versión 3.0 con un montón de novedades.
Así que sin más preámbulos, ha llegado el momento para una actualización de Sónar.
Seguí jugando con el plugin City Model para Sonar de eXcentia.
Para quienes se perdieron los anteriores episodios, los puedes encontrar aquí: City Model, City Model – Nueva versión, La métrica ABC.
Este plugin es muy divertido. Y todo el mundo me dice que es fantástica la representación visual del código en forma de una ciudad. Ir rápidamente a lo más importante es precioso cuando se debe evaluar periódicamente la calidad de una aplicación.