El mito de la mantenibilidad

Parece que seguimos revisando mitos.

¿Realmente es necesario que un software sea mantenible? Si la respuesta es que sí...¿en qué grado? ¿hasta qué punto? ¿para qué usuarios/clientes? ¿Cuándo lo hacemos y a través de qué actividades?

El IEEE define mantenibilidad como: “La facilidad con la que un sistema o componente software puede ser modificado para corregir fallos, mejorar su funcionamiento u otros atributos o adaptarse a cambios en el entorno”.

En la ISO 9126-1 se define que la mantenibilidad está indicada por los siguientes subatributos:

• Facilidad de análisis
• Facilidad de cambio
• Estabilidad
• Facilidad de prueba

Desde mi punto de vista, el uso de buenas prácticas en el análisis y desarrollo nos conducen a:

• Facilidad de análisis: la documentación facilita el análisis y entendimiento de la arquitectura, decisiones tomadas, etc. Una arquitectura coherente en todo el producto, facilita el análisis.
• Facilidad de cambio: la documentación facilita la identificación de elementos afectados por un cambio, su trazabilidad, etc.
• Estabilidad: el aislamiento entre componentes y el uso de una arquitectura coherente en sus distintos aspectos, facilita que los cambios no produzcan efectos indeseados. 
• Facilidad de prueba: las buenas prácticas en el diseño, desarrollo y ejecución de pruebas, facilitan llevar esta tarea a buen término.

Es decir, vemos que para conseguir la mantenibilidad, podemos hacerlo a través de todas estas vías. 

En mi opinión, normalmente no es necesario hacer un esfuerzo adicional (extraordinario) para que un software sea mantenible. Lo que sí es necesario, es que se sigan ciertas pautas en todo desarrollo, independientemente de que se nos exija esa mantenibilidad. La mantenibilidad debería estar "de serie" en cualquier desarrollo. De hecho, es de las características del software que deberían ir EN PRIMER LUGAR. El resto, pueden derivarse de ella.

A continuación, vamos a revisar unas cuantas técnicas específicas enfocadas a mejorar la mantenibilidad, y que por tanto deberían estar presentes en todo desarrollo software (independiente de que la metodología sea tal o cual, ágil o no...):

• Establecer políticas de diseño, codificación y pruebas enfocadas a este tema. Por ejemplo, el uso de patrones puede ayudar. Sin embargo, no debemos caer en el uso indiscriminado de patrones (la conocida "patronitis").
• Facilitar la configuración del software.
• Evitar cambios significativos en la arquitectura del sistema durante el desarrollo.
• Coherencia (en arquitectura, en nomenclatura, en comentarios, etc). No podemos trabajar con técnicas heterogéneas, del mismo modo que no podemos ser superexigentes en la arquitectura, y relajados en los comentarios o nomenclatura). 
• Uso de estándares conocidos. Hacer públicos dichos estándares, manteniendo informado al equipo sobre los mismos, y sobre cualquier cambio en los mismos. Asegurar la formación del equipo en estos estándares. Realizar controles (llamadlos revisiones, auditorías, da igual), y asegurarse de que se cumplen.
• Documentación (de los casos de prueba, de resultados de pruebas, de requisitos, de decisiones funcionales y técnicas, etc).
• Mejora del código en base a métricas (complejidad, etc). Sin control y seguimiento, no se puede mejorar. No podremos mejorar si no sabemos como estamos.
• Planificación del mantenimiento.