Categoría: Arquitectura aplicaciones

Una vez un jefazo que tuve comentó (no literalmente) en una reunión que un jefe de proyecto debía de gestionar el proyecto desde la atalaya, no pegado al barro de la máquina.

Creo que el arquitecto de software debe tener un planteamiento similar. Por una serie de motivos:

Todologo

Es prácticamente imposible en un proyecto un poco grande el que una única persona conozca al detalle todas las herramientas y tecnologías como para poder ayudar a un programador. De algunas si que podrás ayudar a un programador, porque en tu carrera te hayas tenido que pelear con ella. Pero de otras no.

Un arquitecto tiene que lidiar tanto con el desarrollo puro con todas sus herramientas, que si JSF, que si JPA, que si,…. También con las bases de datos, con la gente de sistemas, para la arquitectura de las máquinas, de las comunicaciones, etc

Como dice la sabiduría popular: «el que mucho abarca, aprieta poco».

Por eso creo que un arquitecto debe tener la siguiente actitud:

Coordinador

Por eso es importante que la persona que lleve la arquitectura sea alguien con un perfil de coordinación. Que tenga un equipo de trabajo con diferentes especialistas.

Si te pegas mucho al barro pierdes la visión de la globalidad del proyecto y acabas corriendo el riesgo de dar soluciones parciales y lo que arreglas en un apartado lo estropeas en otro. O también corres el riesgo de dar soluciones poco elaboradas, que se acaban volviendo en contra del proyecto.

En el libro sobre Expreme Programing se hacia referencia a un cuadro de mandos en el que se ponía todos los mandos al máximo y el sistema era estable, porque una técnica se compensaba con la otra.

Esta es la labor del arquitecto, ver la globalidad y hacerlo estable. Por ejemplo, tengo MySQL y como tiene ciertas carencias lo tengo que diseñar con un sharding y eso me provoca ciertos problemas que puedo solucionar con una caché transversal. Esa visión transversal es la que debe tener un arquitecto. No tanto el ponerse a instalar el caché o a optimizar el JSF.

Sino los de sistemas acaban viendo solo los problemas de sistemas y los de desarrollo solo los de desarrollo y eso no es bueno. Es el planteamiento tradicional que se intenta superar con planteamientos de DevOps.

No caer en las tentaciones

A mi, a pesar de venir de la rama de desarrollo, me gusta el tema de sistemas, más como hobby que profesionalmente. Tengo mi nube casera y cosas similares.

A veces es muy tentador cuando te encuentras con cosas de sistemas, por ejemplo, que no van bien, remangarte y hacerlas tu. Pero ese no es el trabajo del arquitecto. En todo caso si es el hacer que la gente de sistemas haga las cosas bien. Lo mismo pasa con temas de desarrollo. Si por ejemplo un código no pasa la auditoria de código. Es muy tentador el adecuarlo tu.

El problema no es lo que puedas hacer sino lo que dejas de hacer. He conocido a más de un jefe de proyecto que venia de la rama técnica y que ayudaba mucho a los programadores cuando no sabían hacer cosas. El problema es que descuidaban sus verdaderas responsabilidades. Y que un programador no lo haga muy bien, es delicado, pero que no lo haga bien un jefe de proyecto lo es mucho más.

Uno de los proyectos personales que he realizado ha sido ISValidator. Fue a finales del año 2001, así que ha llovido mucho desde entonces.

Mi intención era muy simple. En todas las aplicaciones típicas CRUD lo primero que realizas es coger los datos y validarlos. Así que me propuse hacer una librería para ello. Le dediqué mucho tiempo a pensarla, ha hacer algo modular, etc. No la típica situación «quick and dirty» que suele haber en los proyectos.

No me quedó mal, pero por decirlo de alguna manera me empecé a emocionar y a contemplar más casuísticas. Así que se fue complicando todo, hasta un punto en el que casi yo mismo me perdía en el código.

También es cierto que por aquel entonces era un programador.

Para lo que si me sirvió es para aprender algunas cosas.

• Los componentes tienen que estar muy bien pensados para que sean buenos, y a veces aun a pesar de estar muy pensados no son del todo buenos. Se necesitan personas con muchos conocimientos de diseño.
• Un componente no es un código con muchos parámetros, que es lo que suele pasar cuando se hacen las cosas con prisas.
• Hay que ser humilde y no pretender abarcar mucho, ya que puede que si abarcas demasiado acabes generando un monstruo que no controles.

Recuerdo una empresa en la que trabajé en la que tenían desarrollado un framework para hacer las cosas más rápidas, habían invertido mucho tiempo, pero por ejemplo para hacer un simple combo había que tocar en 7 sitios. ¡7 sitios! . Si era super flexible, flexibilidad que dudo mucho que nunca se llegase a usar, pero lo que si era cierto es que costaba un huevo y parte del otro sacar adelante cualquier mantenimiento.

Empece en esto del desarrollo de webs con Java, cuando no había más que los servlets. Luego vino los JSP, los EJB, el Struts, etc.

Es curioso cuando ves que en una comparativa en la que uno de los «frameworks» que más rendimiento tiene son los simples servlets.

Como comenté en otra entrada, quizá debiéramos de plantearnos el simplificar las cosas.

También me ha llamado mucho la atención la simplicidad en el servidor de los planteamiento del GAE

Me ha tocado en varias ocasiones enfrentarme al reto de definir el diseño técnico de una aplicación CRUD, es decir la típica aplicación de gestión de altas, bajas y modificaciones, con sus correspondientes listados. No es una tarea específicamente de arquitectura de desarrollo, pero dependiendo de la magnitud del desarrollo puede realizarse por la misma persona que define la arquitectura.

Normalmente estas aplicaciones las suelen construir programadores junior, que suelen agradecer que las cosas sean lo más sencillas posibles (En alguna ocasión ya he comentado este tema de Kiss).

Yo suelo utilizar una aproximación que me ha dado buenos resultados:

– Lo primero es ver que tipos de pantallas va a tener la aplicación y que hay de común en ellas. Normalmente suele ser la cabecera y pie, los tipos de paginas y la navegación entre ellas (página de filtro, luego página de resultado y paginas de mantenimiento), las opciones (añadir, guardar, borrar, modificar,…)

Esta es una tarea a realizar por un analista técnico o también por un arquitecto, aunque el arquitecto suele estar menos cerca del programador y se suele ocupar de temas más abstractos que el detalle de la programación.

– El siguiente paso es ver como se pueden mecanizar esos puntos comunes. Seguro que más de uno ha pensado inmediatamente en componentes reutilizables, en librerías de código, etc.

Literatura:
Si, esas cosas de código están bien, pero también hay que pensar en escribir un poquito. Recordemos que la aplicación probablemente la va a construir programadores junior, igual es hasta su primer trabajo, con lo que no tienen mucha experiencia y no queremos tener que estar constantemente con alguien al lado para explicarle las cosas o ayudarle, ya que eso implica incrementar las horas (la del ayudado y la del ayudante). Así que nos interesa que las cosas estén lo más sencillas posible.

Por mi experiencia personal el escribir en un pequeño documento o en una Wiki las reglas que se tienen que aplicar ayuda mucho a los programadores, porque son cosas que no tienen que pensar, ya se las das pensadas y además cuadriculadas. Bastante tienen con pensar el resto de cosas.

El plasmar en un documento cosas como, por ejemplo. Por cada mantenimiento va a haber 3 páginas que se van a nombrar de tal forma y se van a colocar en una carpeta con tal nombre. Cada página va a tener un clase de tal tipo para el código que se ejecuta en el servidor y con nombre tal y en la carpeta cual.

Como he comentado el disponer de este tipo de información facilita mucho el trabajo de los programadores más noveles, porque les centra, además de permitir que se puedan intercambiar programadores de un mantenimiento a otro.

Además disponer de este tipo de estructura de cara al cliente hace que incremente la confianza, ya que demuestra que por lo menos ha habido alguien que le ha dedicado algo de «seso» a pensar estas cosas y a homogeneizarlas, en contraposición a la anarquía del búscate la vida.

Código:
Si tenemos clara la estructura de los mantenimiento y los diferentes componentes (clases, jsp, etc) que hemos tratado anteriormente podemos empezar a pensar en pasar a codificar librerías y componentes.

Hay una cosa muy tonta que me ha dado muy buen resultado y es referida al tema de la presentación en pantalla, que normalmente requiere mucho esfuerzo para dejar a gusto del cliente.

Por ejemplo los botones. Si hemos definido que nuestra aplicación va a tener los botones, Añadir, guardar, borrar, etc, en vez de andar copiando todo el rato el mismo código, dando lugar a que cada uno lo llame de diferente manera, podemos hacer un pequeño componente para cada botón. De tal forma que siempre funcione igual y que además sea más sencillo el incorporarlo a la página, o modificarlo a posteriori si es necesario.

Hay una cosa que es importante tener clara, para automatizar primero hay que cuadricular y para cuadricular primero hay que pensar. No se puede automatizar el que cada uno haga las cosas a su modo. Bueno si se puede, pero es terrible. Lo digo por experiencia…

He tenido la suerte de vivir la época del despegue de la informática personal a nivel doméstico, con un IBM PS2/30286 (maravilloso teclado). No viví la época anterior de los típicos spectrum, comodore, amiga y demás, porque a mi padre le parecía que solo servían para jugar. Cuando en la oficina compraron el primer PC y vio que tenia usos «serios» me compró uno igual. El pastizal que les costó, prefiero no pensarlo, pero bueno creo que lo podemos dar por bien empleado.

Era una época en la que venían a mi casa mis tíos o amigos a cacharrear con el o bien iba yo a sus casas. Un poco el espíritu que ha resurgido actualmente con la RaspberryPi (de la que tengo 2)

En esa época todo era mucho más sencillo y complicado a la vez. Sencillo en el sentido que la informática era algo accesorio, a diferencia de hoy en el que la tenemos por todos los lados. Y complicado en el sentido de que había mucho menos conocimiento, todo era nuevo, cualquier cosita era todo un reto.

Pero sobre todo era todo muy artesano. Tenias un ordenador, una contraseña para acceder a Internet, un tal, un cual, un… Hoy día necesito una aplicación como Keepass para poder tener anotadas todos los usuarios y contraseñas de todos los sitios en los que estoy registrado. He decidido solo tener anotadas las máquinas con IP fija en la red de mi casa, porque ya no las recuerdo de memoria, el resto desisto. (Alguna vez he hecho el ejercicio de contar todo lo que podía estar conectado a la red de casa, tanto mio como del resto de la familia y me salían una veintena…)

En el aspecto profesional también ha habido un cambio significativo. La primera normativa de Java del Gobierno Vasco la decidieron delante mio literalmente, de hecho alguna cosa se incluyó porque la necesitaba para el proyecto que estaba realizando. Recuerdo que se compilaba con unos simples scripts de shell. Auditoría de código, ni sonaba. Hoy día tienen montado toda una metodología, con certificaciones y demás.

A veces echando la vista atrás echas de menos esa época, en la que tenias mucha libertad, estaba todo por hacer. Hoy día estás mucho mas condicionado, pero también es cierto que en aquella época se hacían proyectos, que aunque eran importantes para la época, eran minúsculos comparado con la cantidad y complejidad de lo que se realiza actualmente.

Ya no es posible seguir como artesanos. Hoy se impone la industrialización, el tener método de trabajo y seguirlo. Definir bien cuales son las diferentes fases y los cometidos que se deben cumplir en cada una de ellas.

He tenido la satisfacción de poder participar en la definición e implementación de algunas metodologías de trabajo en los diferentes proyectos en los que he participado. Soy consciente de que es muy tentador el saltarse esas metodologías e ir por libre, volver a la artesanía, pero en los tipos de proyectos que se realizan actualmente, esa anarquía supone un suicidio.

Ha habido proyectos en los que esas metodologías que he ayudado a definir e implantar han dado unos frutos muy buenos y en otros en los que no se ha conseguido implantar tan bien. La diferencia ha estado en la exigencia del cliente, cuando como grupo te llevas palos porque las cosas las haces mal, la gente empieza a entender que no puede ir por libre y que debe de hilar fino, así que se adapta (o nos muelen a palos). Cuando el cliente es poco exigente, es mucho mas complicado hacer ver al equipo de trabajo que debe seguir la metodología, porque no le ven la necesidad, es un razonamiento del tipo: vale lo hago mal, pero tampoco pasa nada.

Como me comentó un antiguo compañero de trabajo las cosas se pueden aprender de dos formas, por las buenas o por la vía rápida, es decir a palos. A veces tienes tiempo para poder hacer pedagogía y compañeros receptivos y otras desgraciadamente no.

Pueden parecer planteamientos duros pero lo que está claro es que tienes que adaptarte al nivel de exigencia de tu cliente y proyecto. Sino o te «adaptan» o te quedas fuera.

La artesanía está totalmente opuesta a la industrialización del desarrollo

No es mala terapia «artesanal» el usar la RaspberryPi, es barata, personalizable y te permite trastear sin poner en peligro lo que te da de comer. Yo la uso.

Mi último año en la carrera de informática coincidió con el despegar de Internet, con el Mozilla 3 y las primeras versiones de Internet Explorer. Yo me metí a aprender a hacer páginas web, era una época en que si hacías un web con frames, gifs animados e iconos que cambiaban cuando pasabas el ratón por encima eras lo más de lo mas. Mi primer web tenia todo eso y además capas… de lo más puntero.

Cuando terminé la carrera me apunté a la primera edición del DESI, un diploma de especialización en soluciones Internet que impartía la universidad de Deusto.

Uno de los profesores fue Ricardo Devis, que me acuerdo que nos dijo una cosa que se me quedó grabada, bueno realmente dijo muchas cosas, pero en este momento quiero citar la de «Estáis embrutecidos por la tecnología». Justo saliendo de la carrera, que te empapas de un montón de tecnología, que vayan y te suelten eso así a bocajarro resulta chocante.

Después de más de diez años de aquello, sigo encontrándome en situaciones en las que veo, que efectivamente, estamos embrutecidos por la tecnología. De hecho siguen surgiendo desde metodologías como la programación extrema, que abogan por simplificar los desarrollos y hacer solo lo que necesites, hasta últimamente el concepto de KISS (Keep it simple, stupid) que aboga por lo mismo, mantener las cosas lo mas sencillas posibles.

Investigando sobre arquitecturas de sistemas muy grandes, estilo YouTube, Twitter, etc para un proyecto en el que participé, di con una presentación de Pinterest, la famosa red social de imágenes, en la que explicaban los problemas que habían tenido al ir escalando su aplicación. Y decían lo mismo, mantenlo lo más sencillo que puedas, acabará fallando y cuanto más complicado sea mas difícil te resultará arreglarlo.

Me he encontrado también en proyectos en el que habían dado soluciones, complejas, que las justificaban por la cantidad de patrones que habían utilizado. Luego resulta que las simples consultas a base de datos sin toda esa parafernalia, iban unas 10 veces más rápidas.

Así que creo que debiéramos de empezar a estar un poco mas embrutecidos por los besos (Kiss)

En la época de la construcción de aplicaciones J2EE con tecnología Struts y JSP trabajé en una empresa de servicios en la que introduje el uso de las etiquetas personalizadas (Custom tags).

Estas etiquetas funcionaban como librerías y nos supusieron una gran mejora, ya que, por ejemplo, en vez de tener que hacer corta y pega con el código para una campo de fecha, poníamos la etiqueta que nos habíamos hecho y esta nos generaba el código. Todo el mundo estaba contento, era una tecnología muy sencilla que nos permitía evitar todos los problemas del corta y pega.

Pero no era todo de color de rosas. Un año más tarde, esa misma gente, estábamos poniendo esas, originalmente maravillosas, etiquetas como ejemplo del problema que teníamos. Me explico.

Cada jefe de proyecto en cada proyecto aplicaba un criterio diferente. Unos decían que era mejor validar los datos en la perdida del foco, otros en el submit, incluso hubo uno que hacia mezcla de las dos, el formato en la perdida del foco y el valor en el submit. Unos decían que había que validar los datos antes de pedir confirmación de la operación y otros al revés.

Conclusión, en cada proyecto la etiqueta era diferente, eso provocada que aparte de perder tiempo en adaptar la etiqueta, si un programador tenia que pasar de un proyecto a otro necesitaba un cierto aprendizaje, porque obviamente no solo era la dichosa etiqueta la que se cambiaba en cada proyecto, todos para el mismo cliente, había más cosas que cambiaban.

Es decir, incrementábamos el tiempo de desarrollo y no aportábamos absolutamente ningún valor a nuestro cliente.

Estos errores los he seguido viendo en otras empresas y con otros grupos de personas, porque la gente no parece que sea capaz de interiorizar ciertas cosas:

• Hay que maximizar el aportar valor al cliente.
• TU casa la puedes poner a TU gusto, pero el proyecto, por muy jefe que seas (y en alguno he sido bastante jefe), NO es tuyo, es del cliente.
• Toda mejora supone un cambio, pero no todo cambio supone una mejora.
• Si algo es razonable, aunque tu lo hubieses hecho de otra manera, déjalo y céntrate en mejorar cosas que estén realmente mal.

Acaba de salir el nuevo navegador de Google.

Como desarrollador de aplicaciones Web hay una cosa que me gusta mucho de este nuevo navegador y es la posibilidad de configurar un Web como una aplicación.

¿ Y porque ? Pues porque te elimina todas los elementos de menu del navegador, todos los botones de atrás, adelante, etc. Es decir te acerca mas a una ventana de una aplicación en la que tu gestionas los menús y toda la navegación sin tener una aplicación por encima con la que te puede descontrolar todo el control que necesitas de tu aplicación.

Cosas como no tener que preocuparte de controlar si el usuario te da el botón de atrás porque no lo tienes disponible, o no presentarle la opción de activar el historial.

Es decir que el navegador se comporte sobre ese web como si fuese una aplicación y no un visualizador de páginas/documentos.

Ojalá los demás navegadores lo copien.