mantenibilidad

A lo largo de esta web así como de El Libro Negro del Programador, se insiste mucho acerca de la necesidad de que una solución software sea mantenible. Es más, si no es mantenible fácilmente, el proyecto puede ser todo un fracaso y traerá consigo un cliente muy cabreado y enojado (que seguramente nunca volverá a confiar en ti) o una compañía que tiene un agujero económico que cubrir.

No se hace software para que funcione ahora, sino para que pueda ser evolucionado y matenido fácilmente con el tiempo. Esto para mí es un mantra que repito y un principio irrenunciable.

Mantener un proyecto software en producción es en definitiva conocer cómo se comporta, tener identificadas claramente las actividades de mantenimiento, poder detectar con sencillez dónde ocurren los problemas pero, sobre todo, tener la capacidad de hacer todo eso de manera eficiente y en poco tiempo.

Administrar, por su parte, está relacionado con lo anterior y es igualmente importante: si la administración de cualquier producto software es ineficiente, estaremos poniendo en peligro su viabilidad en producción.

Por muy bien que funcione aparentemente nuestro proyecto, si este no se puede ni mantener ni administrar correcta y eficientemente, habremos realizado en realidad un proyecto más bien pobre. Para que un software sea mantenible y administrable tiene que desarrollarse desde el principio pensando en su sencillez de mantenimiento y administración.

Realizando recientemente algunas actividades de mantenimiento de la web de la compañía en la que dirijo proyectos software, volví a tener presente este carácter intrínseco tan importante del desarrollo. La web está montada en Drupal y se tenían que actualizar algunos módulos desde hacía algún tiempo. A los que me conocen no les extraña en absoluto que dirija la realización de proyectos software al mismo tiempo que me meto de lleno es aspectos de desarrollo de bajo nivel, ¿acaso se puede dirigir algo sin conocerlo suficientemente?

Existe un proyecto que el mundo drupalero conoce muy bien y que permite realizar las actividades de mantenimiento, supervisión y administración de una web basada en Drupal muy fácilmente y, sobre todo, de manera muy eficaz; se trata, claro está, de drush.

Por poner un ejemplo, si tenemos que actualizar el Core de Drupal de un 7.xx a la última versión (en el momento de escribir esto la 7.32) podríamos implementar los pasos oficiales sobre una instancia stage, que, más o menos, son estos:

• Realizar un backup de nuestro sistema (ficheros y base de datos).
• Descargar la última versión de Drupal.
• Copiarla correctamente manteniendo nuestra carpeta "/sites".
• Ejecutar el script "/update.php".
• Por último comprobar que todo ha ido bien...

Esto es algo habitual y, en mi opinión, que existan tantas revisiones de Drupal 7 para mí es bueno, puesto que cada revisión mejora aspectos del Core o realiza actualizaciones de seguridad.

No obstante, lo anterior puede ser tedioso incluso si se tiene que realizar cada dos o tres meses. En cambio con drush todo lo anterior se puede hacer con:

$ drush up drupal

En una simple línea de comandos realizamos todos los pasos anteriores, por lo que de ser una actividad pesada se convierte con drush en la ejecución de una única orden.

Del mismo modo, con:

$ drush status

, obtenemos una visión general de la instancia de Drupal.

Comento esto como un maravilloso ejemplo de facilidad de manteniemiento: con el primer enfoque podemos tardar 10/30 minutos, con el segundo menos de un minuto. ¿No es esto productividad? Me pregunto si no llenamos nuestro día con actividades similares que podríamos optimizar.

Salvo que estemos haciendo proyectos de prueba o de evaluación y no profesionales que en ningún momento se pasarán a producción, personalmente me preocupo mucho de que lo que se haga ofrezca suficientes posbilidades, información y herramientas para un fácil y ágil mantenimiento y administración. En este punto está la clave del éxito de muchos proyectos software.

¿De qué sirve un producto que ha costado desarrollar X € si el mantenimiento del mismo cuesta el triple? ¿Tiene sentido proyectos en los que existen hasta varias personas dedicadas íntegramente al mantenimiento del mismo? ¿No es esto una evidencia de que las cosas no se han hecho del todo bien durante su desarrollo? Recuerdo hace algunos años cuando dedicaba parte de mi jornada laboral a mantener un sistema de telegestión en un cliente y se me iban las horas buceando en la base de datos con consultas muy tediosas para descubrir y resolver ciertos problemas.

Me pregunto cuántas veces en este tipo de situaciones no tiene efecto esa frase tan española y castiza de "preocuparse por la peseta pero no por el duro" (un duro equivalía en la era pre-euro a cinco pesetas), expresión que en versión tecnológica vendría a ser algo así como "intentar que el desarrollo a corto plazo sea muy barato y no ver que su mantenimiento será muy caro".

En cualquier producto software, se desarrolla una vez pero se mantiene continuamente (al menos hasta que nos quedemos sin clientes).

Del mismo modo, cualquier cliente en su sano juicio antes de comprar algo debería preocuparse por lo que le va a costar el mantenerlo y si su administración es eficiente y ágil.

Es más, podríamos convertir esta misma capacidad en un atractivo más de valor para nuestro producto: su sencillez (y poco costoso) mantenimiento.