Es recurrente la pregunta que me hacen según la cual siempre se pone en duda la necesidad de realizar software sencillo, fácil de entender (por nosotros y por los demás) pero sobre todo, mantenible. Muchos de quienes nos dedicamos a desarrollar software profesional no tenemos claro aún ciertos conceptos esenciales, como por ejemplo que un diseño matenible no tiene nada que ver con un diseño de algo que es imposible modificar, depurar, evolucionar, etc. Aun funcionando bien, el primero nos dará un mayor rendimiento del trabajo realizado, mientras que en el segundo caso el software pasa a producción moribundo y sin apenas solución de continuidad.

No obstante, nos cuesta reconocer la relación que existe entre la sencillez y la facilidad de mantenimiento.

Mantenible (palabra mantra en el Libro Negro del Programador) no significa trivial, que un principiante sin apenas esfuerzo pueda entender a la primera, sino coherente, un diseño eficiente que facilita los cambios en el futuro y que la adaptación a nuevos requerimientos relacionados son viables (a un coste asumible).

A diferencia del autor de un best-seller que cuando publica un libro que funciona bien recoge royalties según las ventas, cuando publicamos un producto software tendremos más o menos éxito si este puede evolucionar, si puede ser cambiado y fácilmente mantenido.

En Code Simplicity (libro que recomiendo aunque no se lea ni una línea de código) se pueden leer frases auténticamente reveladoras que el autor intenta sintetizar a modo de leyes comunes que gobiernan el desarrollo de cualquier software.

Una de estas afirmaciones que sostiene el autor es que la facilidad de mantenimiento de cualquier pieza de código es proporcional a la simplicidad de sus partes individuales ("The ease of maintenance of any piece of software is proportional to the simplicity of its individual pieces").

Cuando leí esta frase pensé que cuánto tiempo había intuido esta relación pero sin embargo había sido incapaz de sintetizarla de esta manera tan magistral. Una virtud tiene ese libro: sintetiza de una manera genial auténticas verdades que aún siendo sencillas de entender no lo es tanto de aprehender e introducir en nuestro adn de programadores profesionales.

Efectivamente, parece básico pero no es tan elemental tenerlo presente en nuestro día a día.

Si queremos hacer software mantenible, la clave está en conseguir que cada una de sus partes sean sencillas. La cuestión no es contraponer sencillez versus mantenibilidad, sino que ambos conceptos están íntimamente relacionados (y además su relación es proporcional).

¿Por qué nos debemos preocupar de que lo que desarrollamos pueda ser mantenido con relativa facilidad?, por la sencilla razón de que durante la vida de cualquier producto software, sea algo que se venda bajo licencia, un desarrollo interno en nuestra compañía o incluso cualquier proyecto personal, éste va a ser mantenido durante mucho más tiempo que el que ha costado desarrollarlo. Es más, cuanto más éxito tenga, más cambios y mejoras se nos van a pedir, por lo que el ritmo de evolución de un producto puede ser considerado también como un síntoma de su éxito.

Yo siempre pongo el mismo ejemplo: ¿compraríamos un coche que es casi imposible de reparar o al que es muy difícil cambiarle el aceite?.

¿Verdaderamente tenemos esto presente cuando escribimos líneas y líneas de código?.

Estos conceptos de sencillez y facilidad de mantenimiento son fáciles de entender, pero lo que no es tan fácil es tenerlos presentes en nuestro día a día: nadie es capaz de escribir código limpio a la primera, sino que para llegar a él debemos buscar esa solución sencilla mediante refactorings, repaso continuo de lo ya realizado, etc.

Un ingenuo desarrollador simplificará cuando le venga bien, no de manera sistemática, no se preocupará de que lo que hace pueda ser matenido / depurado con facilidad (no percibe que esto le puede golpear en el rostro con efecto boomerang); un programador cándido busca exclusivamente que lo que está haciendo funcione a cualquier precio, sin tener en cuenta eso de que pan para hoy y hambre para mañana...

Si nuestro software es mantenible, estaremos poniendo los cimientos del éxito del mismo. Si no lo es, nacerá moribundo y terminará convirtiéndose en un fracaso y fuente de clientes insatisfechos. Conseguimos este objetivo de mantenibilidad cuidando de que las partes individuales de nuestro producto sean sencillas.

Comparte esta entrada...

¿Por qué leer El Libro Negro del Programador?

Adquirir desde:
Amazon (kindle eBook / papel)
CreateSpace (papel)
PayHip (epub / mobi / pdf)

El libro negro del programador.com
Segunda Edición - 2017

Archivo

Trabajo en...