domingo, 23 de enero de 2011

Interface City. La ciudad escalable.

La mayoría de la gente que se acerca hoy día a un ordenador por primera vez no se sorprende apenas ante las opciones más básicas que el software nos ofrece. Bien porque es muy joven (los niños se inician en la informática de forma totalmente natural) o bien porque ya sabe más o menos qué esperar.
Por eso no se sorprenden ante el que para mí, es el más importante hito de la historia del software: el poder deshacer los cambios. El Undo. El CONTROL+Z (COMANDO+Z si eres de Mac).
Hoy día, la gente escribe, edita, retoca, diseña, <lo-que-sea-que-haga-con-un-programa> y cuando se equivoca le da al “deshacer” y aquí no ha pasado nada. Pero esto no siempre ha sido así, y no hablo de las máquinas de escribir. Yo he llegado a usar, hace años, en mi Amstrad, editores de texto en los que, como te cargases un párrafo, adiós.
Por eso cuando vi por primera vez la opción de “deshacer cambios” me quedé sin palabras. Y no digamos cuando apareció el concepto de deshacer, no sólo el último cambio, si no los n últimos. Creo recordar que la primera vez que lo vi fue en un editor de textos, el AmiPro. Antes que en el Word incluso.

Esta posibilidad de deshacer los cambios, o de poder cambiar lo creado, es visto desde cierto ángulo la piedra angular del software, lo que ha hecho que toda la humanidad se vuelque en hacer que todo sea software en la medida de lo posible. Sí, porque así es más fácil gestionar el cambio.
Si, como yo, eres de los que piensa que en este mundo la única constante es el cambio (el anicca que lo llaman los budistas), entonces entenderás porqué alabo tanto sus virtudes. Si todo cambia, y el software agiliza el cambio, viva el software.

Ojalá el mundo analógico gozase de esta virtud. Y es que, como os voy a contar en este monólogo, yo creo que el mundo analógico tiene mucho que aprender del mundo digital.
El software, como a su vez se “construye” con software, pues se beneficia como nadie de la facilidad para el cambio, y por eso cada muy poco tiempo tenemos nuevas versiones de nuestros programas favoritos (en realidad podría ser mucho más frecuente pero luego están los intereses comerciales).
Y como cambia tanto (porque “no cuesta”) los que nos dedicamos a ello hemos tenido que aprender una serie de doctrinas, patrones y best-practices, para que tanto cambio no nos desmoralice, y podamos gestionar nuestros proyectos de desarrollo de software eficientemente.

Por que si en el mundo analógico todo cambia, no os quiero ni contar en el mundo del software. Hay quien dice (basándose no sé en qué) que el mundo digital, refiriéndose a los ordenadores e internet, va diez veces más deprisa que el analógico. En todo caso eso será hoy día, porque si lo comparamos con la Edad Media, diría diez veces no, mil.
Y es que si hoy día “las cosas” van más deprisa es principalmente gracias a los ordenadores (especialmente al software). Y es que, como intento decir, si consigo dejar de enrollarme, el mundo analógico que ha creado el software, se ha visto rebasado por su creación. El alumno es mejor que el maestro. Y os explico por qué.

Cuando se “creó” el software y se empezó a publicar programas que nos hacían la vida más sencilla, la forma en cómo esto se hacía era imitando un poco al mundo analógico. El mundo del software aprendió mucho de la arquitectura, por ejemplo. De hecho, los famosos patrones de diseño que todos los programadores usamos, son una copia de un concepto, también llamado patrones de diseño, del mundo de la arquitectura. Y no es otra cosa que una serie de reglas y recomendaciones que garantizan un resultado óptimo. Por ejemplo, se podría decir que, a día de hoy, la mejor forma de hacer una salida en una autovía es mediante una rotonda elevada, que permite igualmente entrar y salir a la autovía, así como hacer un cambio de sentido de la forma más simple. 


Una rotonda elevada es un patrón de diseño.

Tanto imita (o imitaba) el software a la arquitectura que de hecho se forjó el concepto de arquitectura software y arquitecto software, que, por si no os habíais dado cuenta, es de lo que suelo hablar en este blog, intentando eso sí, que sea relativamente asequible.
Contrariamente a lo que mucha gente piensa, hacer una aplicación grande, de esas que requieren uno o varios arquitectos, no es como hacer un edificio. Es decir, sí, tiene muchas analogías, pero una analogía más precisa es como hacer una gran ciudad.
Una gran ciudad es algo en constante evolución. Cualquier ciudad que haya ido creciendo en los últimos, digamos, 400 años, habrá sufrido cambios increíbles. Ahora tendrá alcantarillado, agua corriente en las casa, electricidad, carreteras asfaltadas, trenes, metro, telefonía por cable, wifi, recogida de basura por succión, etc.
Algunos de estos cambios fueron terriblemente difíciles y costosos de abordar, porque no se pensó en ellos cuando se hicieron cambios anteriores. Digamos que no ha habido una planificación para gestionar el ciclo de vida de la ciudad. Desde hace algunos lustros se empieza a hacer, pero no aún con el mismo empeño con que se gestiona el cambio en la arquitectura software.

Hay ciertas cosas que no se pueden prever, como fue el tsunami del Índico hace unos años. Si lo hubiesen previsto, las ciudades costeras tendrían, entre otras cosas, grandes vías de salida que permitiesen evacuar a la ciudad rápidamente. No se podría haber previsto un tsunami, pero sí algo más genérico: una catástrofe genérica. Pudiera ser una Catástrofe<Tsunami> o una Catástrofe<Terremoto> o Catástrofe<GuerraCivil> por expresarlo en términos Java :-). En cualquier caso, cualquier día puede suceder una catástrofe, que será menos dramática si la ciudad dispone de vías de escape, sean del tipo que sean. Este es el tipo gestión del cambio que SÍ hacemos los arquitectos software y no tanto los urbanistas o alcaldes...
Es decir, cuando diseñamos aplicaciones software, pensamos siempre en el cambio, sea del tipo de que sea, y eso facilita mucho su gestión y su crecimiento de forma organizada, intentando minimizar así los efectos de la crisis del software.
Por supuesto también hay mucho arquitecto software chapuza (esto es, no son arquitectos software) que no planifican bien el cambio, y cuando la aplicación empieza a crecer y crecer se hace cada vez más imposible introducir cambios nuevos sin que éstos afecten a otros puntos de la aplicación. Al final la aplicación hay que tirarla a la basura y empezarla de nuevo. Y ojo, el que sea software no significa que cueste poco rehacerla.

Siguiendo esta línea de pensamiento, veo que las ciudades habría que diseñarlas como si fuesen una aplicación informática. Llenas de interfaces, como el de Vía de Escape. O como el de Zonas Verdes. Hay muchos más: zona urbanizable, terreno industrial, zonas de ocio y compras, espacios para brigadas de actuación rápida, etc. Este último ejemplo es un interfaz, una abstracción, sobre algo concreto como puede ser policía, bomberos, guarda civil, etc. Si yo tuviese que diseñar una ciudad colocaría por el centro, en las arterias principales, con buenas entradas y salidas varios solares sobre los que construir edificios que alberguen estas brigadas. Hoy pueden ser bomberos, pero mañana pueden ser, que sé yo, cazafantasmas que entran y salen con urgencia para aplacar la aparición de pequeños e incómodos seres verdes viscosos. Es un ejemplo absurdo pero ilustrativo. El urbanista/arquitecto software no piensa en cómo será el edificio de la brigada; da igual, porque hoy será una cosa y mañana otra. Sólo piensa en el interfaz, en que tiene que haber zonas especialmente pensadas para esas brigadas.

Mira, se me ocurre que un interfaz que sin querer los países desarrollados han creado, es el de Estación de Servicio. No digo gasolinera, que es una implementación concreta de algo más abstracto como es Estación de Servicio. Se ha creado una red de Estaciones de Servicio donde poder parar y hacer cosas que hay que hacer cada x kilómetros recorridos: repostar, comer, ir al baño, cambiar los pañales al niño, poner a punto el vehículo… Hoy día repostar implica echar gasolina, pero puede que mañana sea echar hidrógeno, o cambiar la batería que alimenta el motor eléctrico. El caso es que ahí están, cada x kilómetros hay una, situadas estratégicamente para lo que pueda necesitarse hoy o el día de mañana.

Esta forma de diseñar las cosas, siempre pensando en lo abstracto y lo concreto, siempre pensando en interfaces para enfrentarse al cambio, es algo que ha desarrollado e impulsado la arquitectura software. Y aunque de forma tímida se venía haciendo en el mundo real, somos los arquitectos software los que le hemos puesto nombre a las cosas y hemos puesto por escrito las reglas para trabajar de esta manera.
Y esta forma de diseñar debería transcender el mundo software para empezar a aplicarse mucho más en el mundo real, aunque lo cierto, es que sólo tiene verdadero sentido en aquellas disciplinas que están en constante cambio, como es el urbanismo, la formación, la medicina, legislación, etc. De esta última tengo que decir que mantiene, en cierto sentido, una gran similitud con la arquitectura software, y es que las leyes manejan también siempre conceptos abstractos que se aplican a cualquier implementación concreta, actual o futura.

Un arquitecto software por ejemplo, nunca construiría viviendas a menos de 2km de la playa, porque el calentamiento global va a elevar el nivel del mar inundando las zonas pegadas a la playa. 

Eso es pensar en el cambio. Y eso es, precisamente, la misión de un arquitecto software: tener un ojo siempre en el futuro y pensar en la escalabilidad y en el cambio. Y elegir las tecnologías y diseños que permitan afrontar elegantemente el cambio y sobre todo el crecimiento,  para que cuando este llegue, se pueda aplicar sin afectar al resto de la (Ciudad) aplicación.


sábado, 1 de enero de 2011

La copla del desacople

Cuando empiezas a aprender sobre arquitectura software, descubres muchas reglas que a veces son contradictorias. Cuando ya has aprendido patrones de diseño y patrones de análisis, entonces descubres o te enseñan cosas como que tú tienes que ser muy listo pero tu código muy tonto,  y claro, los patrones de diseño no son precisamente código tonto. ¿En qué quedamos?

Un ejemplo claro que me mantiene entretenido últimamente es la regla de alta cohesión-bajo acoplamiento. Del que se derivan otros como el de OCOR (One Class, One Responsability) o el principio Open-Close (abierto para la extensión, cerrado para la modificación). 
Este principio habla de que los diferentes componentes software han de tener una responsabilidad clara, y deben poder reemplazarse sin que afecte al resto de componentes. Este desacople, que se lleva buscando años, adquiere especial relevancia últimamente, aplicándolo al famosísimo desarrollo en tres capas: vista, negocio y datos.

Lo que se pretende es un desacople total entre estas tres capas. Esto es algo totalmente posible hoy día. Imaginad que los datos los cogemos vía un web service. Entonces, nuestra capa de negocio podría ser totalmente reemplazada, siempre y cuando la nueva, que puede estar en otro servidor, incluso en otro lenguaje de programación, utilice las mismas llamadas al web service (el mismo contrato WSDL). Y lo mismo sucede con la capa vista. Últimamente me ando debatiendo entre si hacer o no una capa vista totalmente desacoplada. Esto es algo sólo viable desde que existe ajax, y desde que el javascript se hizo adulto y el JSON emergió. El JSON es a la capa vista lo que el XML a los web services.

Gracias al JSON, podemos hacer una capa vista totalmente en Javascript, con llamadas asíncronas al servidor para traer cualquier dato que haya que pintar. Las llamadas desde la capa vista siempre devuelven los datos en formato JSON, lo que significa que los controladores del servidor (la C en el MVC que existe en todas las capas vistas bien hechas) podrían ser Java, .NET o PHP por ejemplo. Esto, a priori es genial. Desacoplamiento perfecto. Pero hacer esto es un sobredimensionamiento ¿o no? Supongo que depende de quién lo vaya a programar. Si eres más experto en JQuery que en Java, pues claro, viene bien hacer esto.
Si en tu equipo de desarrollo hay expertos en Javascript/JSON con dominio de JQuery o Prototype, te puedes permitir el lujo de hacer un diseño/arquitectura de baja fidelidad en un lenguaje tipo PHP o Grails, y si el proyecto convence, pasarlo a Java o .Net sin necesidad de tocar ni una línea de la capa vista. Esto es realmente útil, porque lo cierto, y este es otro mandamiento de la arquitectura software, es que para el usuario el interfaz es el sistema, y si ve un interfaz bonito y usable, tienes muchas papeletas para triunfar. Si tu proyecto está pendiente de aprobación o lo tiene que revisar con lupa un equipo de QA, poder prototipar la capa vista sin preocuparse demasiado por la arquitectura de la aplicación es un lujazo, cada día más necesario.  Sí, porque, ¿Cuántas veces habéis hecho unas pantallas para una demo que no ha dado tiempo a terminar, pero tiene que dar el aspecto de que está terminado y funcionando? Yo también muchas veces. Y hacer este tipo de fachadas (pantallas con funcionalidad simulada) es muy más fácil, y da un aspecto más realista cuando todo el interfaz se construye en el cliente (está desacoplado), y sólo tienes que simular las llamadas JSON.

Es así de triste pero es muy cierto: miles de aplicaciones web se venden gracias a su interfaz. Es tan absurdo como elegir un coche sólo porque su carrocería es muy elegante. Con el tiempo se aprende que una arquitectura robusta con un interfaz feo y sobre todo difícil de usar, no vende. Así que si quieres triunfar en este mundillo, más te vale aprender un poco de “capa vista”, y ponerle a tu coche una buena carrocería y un salpicadero impactante.

Todo esto es lo que me hace debatirme entre hacer una capa vista totalmente desacoplada o no. Para la capa de datos ni me lo planteo. Insisto en si me lo estoy planteando para la capa vista es porque la capa vista vende, y, repito, para el usuario/cliente lo es todo. Supongo que acabaré aplicándome la copla ésta del desacople, y lloraré cuando vea trabajar a un desarrollador de .Net, en su maravilloso IDE donde todo está integrado y la programación es casi visual.

Otro inconveniente que observo al llevarme la capa vista a JSON es que, los IDEs no están tan preparados para el Javascript como lo están para el Java, Groovy o .Net. El Javascript ha madurado muy deprisa. Lleva mucho tiempo entre nosotros, pero hasta que no empezó a comer ajax no dio el estirón. Y menudo estirón ha dado. Se le han quedado pequeños todos los IDEs. Espero que esto se resuelva rápido, porque a pesar de la existencia de joyas como Selenium para testar el interfaz y la capa vista en general, sigue habiendo un trecho que recorrer a día de hoy, a principios de 2011.

El caso amigos es que, recapitulando, hay que desacoplar correctamente las clases, los paquetes donde guardas las clases y los componentes software que usan esas clases. Desacoplar la capa vista o la capa datos es también recomendable, pero es un sobreesfuerzo que se ha de sopesar con mucho cuidado. La tecnología JSP y JSTL (dentro del mundo Java) pierden fuerza con estas nuevas tendencias… con lo que me ha costado dominarlas :-)
Sin embargo, no es ni mucho menos, la primera vez que una nueva forma de hacer las cosas triunfa por un solo detalle, a pesar de tener muchos otros en contra. A veces ese único detalle es tan crucial, que merece la pena el sobreesfuerzo. No estoy 100% seguro de que, en el caso que nos ocupa –ese detalle de tener la capa vista totalmente desacoplada– vaya a ser tan crucial. Supongo que es un poco pronto para ello, pero acabaremos haciéndolo. Sobre todo si nuevas tendencias en el desarrollo como CQRS, o el desarrollo orientado a eventos reloaded triunfan próximamente.

Otra vez, se confirma lo que siempre digo, y es que para ser un buen arquitecto software, no basta con saberse las reglas muchas veces contradictorias, sino cuando aplicar una y no su inversa.