SonarQube, uso desde eclipse

Segunda entrada sobre el SonarQube, en este caso y a diferencia de la primera entrega, en la que vimos la instalación y primer uso, en esa ocasión vamos a ver el uso desde el entorno de desarrollo Eclipse.

Este tipo de herramientas son muy útiles para tener un cierto control sobre el código fuente de nuestros desarrollos.

Pueden llegar a ser un poco delicados si se abusa del número de reglas que apliquemos, pero con una configuración inteligente puede resultar una herramienta muy útil.

Os dejo el vídeo.

Cadena de suministro de Software

Lo primero decir que me encanta la imagen destacada de esta entrada. Primero porque representa una cadena y segundo porque me parece muy bonita estéticamente hablando.

El concepto de cadena de suministro de Software no es muy usado, está mas de moda el de devops. Pero a mi la verdad es que el de devops no me gusta tanto, porque hace referencia a desarrolladores y operadores y prefiero utilizar el de cadena de suministro de software, como hacen referencia en Nexus de Sonatype.

Me gusta mas porque desde que nuestro cliente tiene una necesidad, hasta que esa necesidad se pone en producción en forma de un programa, hay que pasar por una serie de fases o una cadena para suministrar ese Software.

Por eso me gusta mas, porque creo que representa mejor lo que pasa, pero claro devops es un nombre mas cortito.

Os dejo bastantes reflexiones mas sobre este concepto en el vídeo

SonarQube #1: Instalación y primer vistazo

Empezamos una nueva serie sobre una herramienta de cuadro de mando de calidad. Es muy utilizada porque tiene una versión bastante completa que es gratuita.

Permite tener un cuadro de mando de la calidad del código y centralizar la gestión.

Pero mejor vamos a ver como se instala y a echarle un primer vistazo.

Cual es el porcentaje adecuado de cobertura de código

En mi opinión, lo mejor que puedes hacer es olvidarte del porcentaje de cobertura de código. Me explico.

Cuando lees el libro de Kent Beck, que es el autor que puso de moda las pruebas unitarias, y que viene a ser el manifiesto de programación extrema, te das cuenta que no habla en ningún momento de porcentajes de cobertura. El lo que dice es qué hay que escribir todas las pruebas que se te ocurran, de cosas que pueden fallar, obviamente. Y una vez que el código pasa todas esas pruebas y no eres capaz de encontrar ninguna prueba más tu código ya es correcto.

A la hora de probar nuestro código existe un grupo de herramientas que son las de cobertura de código que nos ayudan en nuestro trabajo. Estas herramientas, en el caso de Java, lo que hacen es poner la máquina virtual en un modo en el que la máquina va diciendo por que líneas de código va pasando cuando se ejecuta código. De tal forma que si nosotros ejecutamos nuestras pruebas unitarias con una herramienta de cobertura de código y vemos que hay una serie de líneas de código por las cuales no se ha pasado, eso nos proporciona una información muy valiosa. Puede ser por dos motivos o bien nuestro juego de ensayo no es tan completo como nosotros creíamos y se nos ha escapado alguna casuística o bien es lo que se llama código muerto, es decir en algún momento ese código tuvo alguna utilidad pero en este momento ya no la tiene y no se usa y se puede eliminar.

El problema viene cuando se confunde un medio con un fin es decir el fin de las pruebas unitarias es asegura que código es correcto la cobertura del código es un medio. Si nos obsesionamos con los porcentajes con un 70% o 60% u 80% de cobertura es cuando estamos equivocando el medio y el fin.

Obviamente si nuestra cobertura de código es baja es prácticamente imposible que nuestro juego de ensayos sea completo ya que hay muchas líneas por las cuales no pasamos. Pero también se puede dar el caso inverso, es decir que hayamos pasado por todas las líneas de código no quiere decir que las condiciones que hemos puesto en el JUnit sean las correctas o todas las necesarias. De hecho podríamos poner como única condición el siempre valido assertTrue(true) y nuestra cobertura de código sería alta.

Es por ello que, como decía al principio, no creo que haya que darle especial importancia al porcentaje de cobertura. Si es un buen indicador pero necesita de una persona que supervise porque él nivel es bajo o si un nivel alto realmente me está asegurando la calidad.

Porque te preocupas por el código, si no lo mira nadie.

Hoy quiero hablar de un tema que tenia en la cabeza desde hace tiempo y que la excelente entrada de Javier Garzás sobre la calidad del producto me viene como anillo al dedo.

El tema es como he vivido la evolución de la informática de desarrollo desde que empecé a trabajar, desde el punto de vista de un técnico que se dedica a la industrialización del desarrollo de software y a la arquitectura J2EE.

A principios del año 2000 (porque decir principios de la última década suena a muy mayor) estaba en un proyecto en el que una persona, y no programador precisamente, me hizo el comentario que figura como título de la entrada: “Para que te preocupas tanto por el código, si no lo mira nadie”.

Es lo que se llevaba en esa época, cumplir los plazos y que la aplicación hiciese lo que tenia que hacer. Es decir se le daba muy poca importancia a los técnicos, eramos básicamente programadores, los que cortaban el bacalao eran los funcionales. Y los clientes tampoco es que se preocupasen mucho por el código.

Siempre me ha gustado intentar hacer las cosas lo mejor posible, así que por aquella época empecé a utilizar herramientas como PMD y Chekstyle, JUnit, etc que cuando las proponía usar me miraban raro. Parece que son herramientas nuevas, pero llevan desde hace más de 10 años.

Pero tenía claro que al final esa falta de preocupación por la calidad tenia que acabar explotando por algún sitio. Y así ha sido.Hoy día la mayoría de clientes de la zona están en mayor o menor medida implantando controles de calidad en el producto, independientemente de que exijan a sus proveedores la ISO o el CMMI.

Hoy día no resulta extraño encontrarse clientes con un Sonar, un SVN, un Jenkins, etc.

La siguiente gran práctica que creo que va a incorporarse va a ser el tema del TDD y todo lo relacionado con la automatización de pruebas. Ahí estaremos.

Auditoría de código en un proyecto ya empezado

Cuando tienes que asumir la industrialización del desarrollo de un software ya empezado, uno de los problemas a los que tienes que enfrentarte, es que hacer con la auditoría de código, que normalmente no se cumple.

Uno de los objetivos de la industrialización es bajar la deuda técnica y uno de los parámetros tiene que ver con el cumplimiento de la auditoría de código.

Es muy complicado el llegar a los objetivos de cumplimiento de una atacada, salvo que se pueda hacer una intervención ex-profeso, cosa que no suele suceder, primero, porque normalmente suele haber cosas más importantes en las que invertir los, normalmente escasos, recursos del proyecto.

Yo lo que suelo pedir es que por lo menos la deuda técnica se vaya reduciendo. Es decir, no espero que se pare todo para cumplir la auditoría, pero si que por donde se vaya pasando se vaya haciendo el esfuerzo de adecuar el código. Que los indicadores de cumplimiento vayan subiendo.

En el peor de los casos por lo menos podrás decir que el equipo está haciendo el esfuerzo de mejorar la calidad.

Auditoria de código, un arma de doble filo

Llevo utilizando herramientas de auditoria de código desde hace más de diez años. Concretamente el PMD y Checkstyle y durante un periodo de tiempo muy corto, el Together. Siempre he estado muy interesado en estos temas de hacer las cosas no solo que funcionen sino además procurar hacerlas bien.

En estos más de diez años he ido pasando por una serie de estadios con respecto a la auditoria de código. Inicialmente me parecía muy importante y ponía a mis proyectos una configuración con muchas reglas. Eran épocas en las que estos temas de cuidar la calidad no estaban muy en boga que digamos, así que era una especie de bicho raro.

Con esas configuraciones tan exigentes aprendes una cosa, que si te pasas poniendo reglas no eres capaz de pasar del hola mundo. Y no siempre acaba compensando la mejora de la calidad con el incremento de coste.

Así que empiezas a aligerar las reglas, haciendo una selección más racional.

Poco a poco afortunadamente estas herramientas se han ido popularizando y cada vez más clientes para los que he trabajando lo han ido exigiendo.

Pero cuando extiendes estas herramientas a todo el proyecto te empiezas a dar cuenta de la dificultad y del lado oscuro de las mismas. 

El que no tiene criterio para hacerlo bien, no lo hará por mucha herramienta que le pongas. He visto a programadores arreglar errores dejándolo objetivamente peor, pero eso si había desaparecido la alerta.

Esto ocurre por un motivo, estas herramientas no solo detectan errores, sino que detectan patrones sospechosos, por eso hay que tener cierto criterio.

Hay que dejar las cosas sencillas. Algunas empresas para las que he trabajado tienen definidas reglas de auditoria de código en las que el pasar o no el criterio no solo depende del nivel de error sino de cuantas alertas tengas. Es decir por ejemplo el tener un número determinado de alertas de nivel Info puede hacer que no pases el criterio.

Este planteamiento es entendible, en el sentido de que una cosa que igual no está mal, pero se repite mucho puede ser una fuente de problemas. Por ejemplo si usas mucho las conexiones a base de datos, puede ser que cierres todas correctamente, pero es un punto de riesgo.

Este planteamiento puede resultar un poco complicado de hacer cumplir a un equipo de trabajo, porque no saben si lo tienen que cambiar o no.

Yo suelo preferir, siempre y cuando el cliente no tenga sus propias reglas, obviamente, planteamientos más sencillos. Los errores son eso errores y hay que arreglarlos si o si, y el resto de cosas, warnings, info, etc es opcional el arreglarlos.

Una de las cosas que si suelo incorporar a las reglas de auditoria son todas aquellas reglas que aunque no son importantes si son automatizables por los entornos de desarrollo. Por ejemplo el hacer que los if lleven siempre llaves.

La calidad del código II

La calidad en el código es un tema que me interesa desde hace ya algunos años.

Lo que me sorprende es comprobar que me ha sido imposible implantar estas prácticas en los diferentes sitios en los que he desarrollado mi trabajo. Quizá sea por mi incapacidad para trasmitir el mensaje, no lo se, pero me he encontrado con ciertos posicionamientos.

  • Se ve como algo caro. Como si hubiese que desembolsar mucho dinero para comprar productos, cuando existen hoy día herramientas gratuitas y libres que funcionan muy bien.
  • Se ve como que eres un purista que vas a poner un sistema que va a parar el desarrollo en pos de la excelencia técnica. Cuando es perfectamente factible implantar un sistema progresivo. A mi personalmente me gusta la técnología, pero me gusta mas la pasta ($).
  • Se ve como pijadas que no van a hacerte que entregues a tiempo. Si es cierto que comprometerse a que despues de un igual o una llave exista un espacio en blanco puede parecer una chorrada, y que no va a hacer que el programa funciona mejor, pero es que cumplirlo tambien es una chorrada. Te lo hacen los propios editores de código al formatear.
  • Pero sobre todo el principal problema es que los clientes no miran el código. Como me dijo una persona hace tiempo: “Para que te preocupas tanto por el código si nadie lo mira”. El problema de este planteamiento es cuando te encuentras en un proyecto grande que lleva 8 años desde que se inció y tienes que mantener código que tira para atras solo el leerlo.

Yo veo la calidad en el código como una forma de diferenciarse de la competencia, como una forma de mantener un mínimo de control en proyectos en los que hay una circulación de gente fuerte. Y sobre todo me parece que no es para nada caro si no entramos en planteamientos maximalistas.