Etiqueta: Calidad

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 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.