El Mamotreto
Así como le apunto al arquitecto de software por su inviabilidad, hablemos también de arquitectura de software horrible—causa principal de la idea de poner a alguien explícitamente para evitarla—y analicemos por qué ocurre. Primero, quien esté libre de pecado, que arroje la primera piedra. No hay, que yo sepa, ningún Gaudí en el mundo del software. Más bien, somos todos una banda de Calatravas sueltos. Tengo en mi haber mamotretos de todos los colores y formas, que arrancaron como meros experimentos personales para terminar viendo la luz del día en producción, siendo usados por almas inocentes que terminaron sufriendo mis “creaciones”. Ojo, no es excusa.
Pero paremos ahí un instante para hacer esta salvedad: aquel cacho de software hecho para consumo personal, para resolver un problema estrictamente privado y puntual, vaya y pase. ¿ Queremos tener ahí variables globales por todos lados? Adelante.¿Queremos retornar un error -147 sin ninguna otra aclaración? Y dale. ¿Usar una librería open source cuyo último commit fue en el 2007? Y si. Total, nadie va a sufrir esa desprolijidad más que nosotros y nuestra circunstancia.
Ahora bien, cuando dicho cacho de software trasciende esa barrera personal y cruza la línea donde tiene que ser usado por una audiencia mayor o en una relación proveedor-cliente, bueno, la cosa cambia. Es más, cuando un cacho de software es parte de otro cacho mayor desarrollado por otras gentes, el asunto es serio, porque requiere coordinación y consenso. Esto es lo que empieza a trazar la línea entre mera programación y la ingeniería de software.
Arquitectónicamente hablando, he hecho y visto cosas indecibles. Una arquitectura horrible de la cual me avergüenzo hasta el día de hoy involucraba un software compuesto por 4 o 5 procesos que se hablaban entre sí mediante señales del sistema operativo; las infames SIGUSR. Técnicamente, esto no figura en los famosos antipatrones de software, pero debería figurar en el código penal. Primero, el orden de arranque de esos procesos marcaba la diferencia entre armonía o pandemonio (primera gran señal de mala arquitectura). Un script auxiliar se encargaba de que el proceso Y no arrancara antes que el proceso X, y así. Con sleeps y todo. Después, si un proceso se caía—y se caían frecuentemente—otro script monitoreaba y resucitaba de forma acorde. Horrible. Han pasado años desde que creé ese mutante y todavía me persigue en mis pensamientos.
En otra ocasión, literalmente reinventé Pandas. En mi defensa, en el 2016 no era tan popular y maduro como hoy día, pero ya estaba, y yo lo sabía. No me importó. Dije: yo puedo hacerlo mejor. Era cierto? Claro que no.
Otras horripilancias en las que he estado involucrado incluyeron el uso insólito de shims en software de vuelo para acoplar partes de la arquitectura que habían sido pensadas con estilos y conceptos de operación diferentes. Por supuesto, la misión duró lo que dura un gas en un contenedor poroso. ¿La razón? A uno de esos shims se le trabó la cabeza y honró su rol como punto único de falla. Nadie pudo sorprenderse del resultado final. En general, sea de vuelo o no, la sola presencia de shims en una discusión de software debería considerarse suficiente evidencia de que una mala arquitectura está cocinándose. Un shim, por definición, es creado para atar con alambre cosas que no fueron originalmente diseñadas para colaborar. ¿No nos dice algo eso?
En cualquier caso, la arquitectura pedorra no ocurre en un abrir y cerrar de ojos. Se manifiesta y da señales; sólo hay que prestar cierta atención a ciertos términos que delatan que está viniendo como chancho a los choclos: Shim, CORBA, RPC, IDL, XML, IPC, “wrapper”, ASN.1, OWL. Si alguien tira algo de esto: guarda eh. Seguro, estas cosas pueden ser decentes en sí mismas; el daño reside en cómo se las interpreta, usa y combina.
Se entiende entonces que, con tanto software que horripila dando vueltas, se pretenda resolverlo con la figura omnisciente que baja de los cielos para mostrarle el camino a simples mortales.
Pero todos los caminos conducen a que la arquitectura de software es un asunto irremediablemente empírico. En criollo, la verdadera solución a la mala arquitectura es la experiencia: sólo habiendo creado software horrible se puede crear software menos horrible.