archivo

Archivos diarios: abril 20, 2010

Este plugin de Sonar me ha parecido muy interesante ya que permite definir diferentes vistas agregadas de los resultados, de manera que podemos obtener vistas por proveedor, departamento de la organización, equipo de trabajo, responsable del proyecto, etc…

Se trata, por tanto, de una forma de poder obtener conclusiones globales sobre la calidad del código y de la programación de manera objetiva (según las reglas Sonar) en función de las variables que se definan, de manera que, por ejemplo, podamos tener métricas sobre la calidad del código de las aplicaciones entregadas por los distintos proveedores de servicios de desarrollo de software o si fuéramos proveedores de estos servicios podríamos identificar qué técnicos o equipos de trabajo son los que realizan mejor código.

Se trata de un plugin de pago, 1800 USD por instancia de Sonar y año. También se puede solicitar una licencia de evaluación.

Os dejo un par de direcciones, la primera contiene la descripción del plugin y la segunda un Sonar de ejemplo donde se puede ver el resultado de utilizarlo.

Desde hace unas semanas tenemos en marcha Sonar en nuestra organización para recoger métricas realizando una revisión estática del código. Estamos muy contentos con la implantación de la herramienta y realmente le estamos viendo bastantes posibilidades de cara a un futuro, no obstante es algo que tenemos que tomarnos con prudencia, ya que cada programa es un mundo y no podemos juzgar de antemano y sin un estudio en profundidad de las métricas y de las circunstancias del producto si el mismo a nivel de codificación ha resultado de calidad o no. Hay mucho que trabajar en este sentido, ya que independientemente de lo anterior, una vez analizadas sus bondades y defectos nos permitirá por un lado mejorar la mantenibilidad de los sistemas y la calidad general del producto.

Uno de las cosas que más nos llamó la atención fue que para casi todos los proyectos para los que recogíamos métricas el valor de Cobertura era 0% o lo que es lo mismo, que el 0% del código de gran parte de los sistemas de información de la casa no esta cubierto por pruebas unitarias.

Una vez descubierto esto (no es que hayamos descubierto ninguna maravilla, simplemente es algo que con el día a día no se prestaba atención, pero que sin embargo son tan obvios y llamativos los datos que nos da Sonar que no podemos dejar pasarlo por alto), vamos a meter mano en este tema, porque muchos errores que se detectan en la fase de pruebas del producto o en producción se podían haber detectado previamente con unas sencillas pruebas unitarias, de esta manera mejoraremos la eficiencia de funcionamiento de nuestra Oficina de Calidad, ya que tendrán que dedicar menos tiempo a detectar y reportar este tipo de incidencias y por supuesto reduciremos el número de errores que nos llegan a producción.

De las pruebas unitarias se habla mucho, incluidos los propios proveedores de servicios de desarrollo de software, pero después queda demostrado que del dicho al hecho hay mucha distancia.

La clave de todo está en el equilibrio, si intentamos cubrir con pruebas unitarias todo el código, lo mismo cuesta más el collar que el perro, pero no verificar nada tiene tan poco equilibrio como lo anterior. Por lo menos sería necesario que se verificasen los métodos más conflictivos, comprobando si en función de distintas posibilidades se ejecuta o no el código contenido en los mismos. Como esto dependerá mucho de la complejidad de las aplicaciones, el factor de cobertura será distinto entre ellas, pero una cosa es esa y otra cosa la nada.