Y no es suficiente que solo funcione
Un tiempo atrás, mejor, hace ya mucho tiempo atrás, cuando empecé a desarrollar software, las cosas sucedían por esfuerzos heroicos de todos los implicados, entonces, no existían ambientes independientes, desarrollábamos en las mismas bases de datos de pruebas, cada quien probaba lo que se le ocurría y el control de configuración era llevar los archivos a un directorio de donde sacaban una copia la cual luego era nuestro "release", en conclusión el producto funcionaba de milagro, y era otro milagro, aún mayor, si el cliente aplicaba lo que enviábamos.
Cuando en el universo ocurría una de esas extrañas singularidades de espacio y tiempo, nuestros clientes instalaban y aparecía el perfil de desarrollador de servicios profesionales, quien no era más que un ingeniero que se iba armado con nuestro "release" a copiarlo, así fuera a la fuerza, en los servidores del cliente y luego trataba de resolver todos los errores que encontraba, la solución de esos errores a veces era reportada a la fábrica y la mayoría de las veces se perdía con el café de la siguiente mañana. Es justo anotar también que, mucho del soporte era dado directamente por los grupos de desarrollo pues los encargados del cliente a veces no daban abasto.
Todo ese modelo fue como «un bebé concebido durante una caótica orgía en la que todo el mundo acaba con un terrible dolor de cabeza, y cuando aparece este hijo todos dicen:“No es mío”»
¿Y en donde empieza el sermón?
En esa epoca, y en los años posteriores, acuñamos el término "si compila funciona" refiriéndonos, en forma de chiste, a nuestra desconfianza por el código que hacíamos, pues al no tener ambientes, independientes de desarrollo y pruebas, control de versiones y un proceso de pruebas robusto era como manejar: de noche, sin luces, lloviendo, en una carretera sin señalización, manejábamos alocadamente tumbando algunos árboles, pequeños y grandes, de la orilla del camino.
Carro leñador
Ahora, la expresión "si compila funciona" surge de las decisiones que se toman en desarrollo sin tener una etapa previa de diseño, y mucho menos teniendo en cuenta el mantenimiento posterior de la aplicación.
Fue una época difícil ¿y?
Ya pasaron los tiempos de las caóticas orgías y el carro leñador, ahora tenemos procesos estructurados de entrega y liberación de producto. Los desarrolladores y líderes están siempre preocupados por terminar funcionalidades o tareas del cronograma y los productos funcionan.
Y eso es bueno ¿cierto?
Depende. Déjenme les cuento una historia, supongamos que diseñamos nuestro automóvil soñado: debe tener mucho espacio interior, en caso que quisiéramos ir al supermercado o realizar un trasteo de una casa de 3 pisos, además el equipo de sonido será capaz de amenizar un concierto de reggaetón en el estadio y estéticamente debe proyectar la imagen de "Yo soy el jefe"
El jefe con un tremendo equipo de sonido y gran espacio interior
Ahora, como somos unos bisoños diseñadores automotrices hemos cometido algunos pecados que serán castigados cuando tengamos que hacer alguna reparación, puesto que el mantenimiento no fue pensado en el diseño original y fue una decisión de último momento, así:
- Es necesario bajar el equipo de sonido para hacer un cambio de aceite y para eso necesita una grúa industrial de 20 toneladas.
- El tablero de sonido es tan complicado que solo puede ser operado y reparado por un ingeniero de sonido que previamente ha sacrificado 2 gallinas como ofrenda a su dios Kukulkán.
- El mecánico que realizó la construcción estaba tan convencido que era el mejor automóvil jamás construido, entonces, trabajo sin descanso en el proyecto, propulsado por bebidas energizantes y drogas psicoactivas, entregando a tiempo y volviéndose un loco adicto a estas sustancias lo que lo alejo definitivamente del mundo automovilístico. Ahora nadie sabe las herramientas usadas en la construcción o los cambios en la implementación final.
Entonces podemos afirmar, no es suficiente que solo funcione.
Pero esos son carros no software
El software tiene una complejidad mayor pues es algo virtual, son un enjambre de unos y ceros dando vueltas sin cesar por circuitos electrónicos, que representa información a un usuario u otras máquinas.
El carácter virtual del software lo hace más propenso a cometer errores de diseño, algo que sucede rara vez en la ingeniería que trabajan con cosas concretas, en algo tangible es más sencillo notar los problemas, en cambio, en el software es difícil percibir estos inconvenientes incluso en el producto final.
Un error muy tangible
¿Y cómo es diseñar para hacer más fácil el mantenimiento en el software?
Existen diversas técnicas que ayudan en este objetivo una es el Test-driven development (TDD) en donde las piezas son cuidadosamente nombradas y separadas para mejorar la legibilidad y facilidad de mantenimiento.
¿Y cómo funciona TDD?
De niño una de las tareas que menos me gustaba era ir a comprar plátanos a una tienda que quedaba a 3 cuadras, pues como tengo cierto grado de daltonismo confundo algunos tonos del color verde, por lo tanto, para mi todos los plátanos verdes son iguales y no podía distinguir cuales eran para: freír, sopa o de otra especie, adicionalmente, mi madre algunas veces no me daba dinero suficiente para la compra, por lo tanto, en muchas ocasiones debía volver a la tienda a cambiar los plátanos o a llevar el dinero que faltaba.
Viendo el problema de la compra del plátano daltónico desde el punto de vista del TDD, las labores deben estar separadas en: escoger, pagar y correr. Necesitamos una persona que tenga una experiencia, rapidez y visión perfecta en la escogencia de esta fruta, el encargado del pago debe tener el cambio exacto y el que corre a la casa puede ser el campeón olímpico de los 100 metros planos, ahora, si necesitamos un mejor experto o contratar a alguien con una moto podemos cambiarlos fácilmente. Lo anterior es parte de TDD, en donde cada unidad debe tener responsabilidades bien definidas y concretas, además, deben cumplir con características suficientes para realizar pruebas de unidad automáticas, pero esto último es parte de otra historia.
Si quieren conocer más de TDD pueden ver las siguientes referencias:
- Test-driven development
- Hackable Projects
- Design for Maintainability
