Categoría: Arquitectura & DevSecOps

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…

En esta entrada quiero traer a colación un tema que me ha supuesto una enorme mejora, a la hora de industrializar el desarrollo de software, sobre la formas de trabajo de hace algunos años. Me refiero a la virtualización.

Todos conocemos las posibilidades de la virtualización, que nos permiten tener muchas máquinas virtuales en una única máquina física.

Yo quiero dar una visión de la virtualización desde el punto de vista de un equipo de desarrollo sobre las mejoras que nos proporciona, lo que se da en llamar devOps. Ya que a veces solo se ve la virtualización como una forma de ahorrarse tener muchos servidores físicos permanentemente levantados, que es el enfoque más típico de sistemas.

Algunas situaciones en las que me ha servidor la virtualización:

– Facilitar el acceso a las redes de los clientes:

Muchas veces cada cliente tiene su software de VPN particular, unos con un fabricante y otros con otro, así que si no tienes la suerte de trabajar para un único cliente te puedes encontrar con varios clientes de VPN instalados en tu máquina. Por experiencia, al de 4 programas de VPN, el windows deja de funcionar y ni siquiera arranca.

Tener una máquina virtual por cada cliente te permite poder solventar esta casuistíca.

– Evitar el reinstalar programas compartidos

Aparte de permitir tener máquinas virtuales para tener las VPN de cada cliente, estas máquinas virtuales te permiten tener ciertas infraestructuras de forma compartida para interactuar con la infraestructura del cliente. En muchos casos en cada cliente necesitas una serie de programas, como clientes FTP, navegadores, herramientas de compilación, etc…

Yo he tenido la experiencia, trabajando para un cliente, en el que yo tenia instalados los programas necesarios para acceder a las máquinas del cliente (favoritos incluidos) en mi máquina y cuando me fui de vacaciones se la tuve que dejar, con las contraseñas y demás a una compañera. Técnicamente el ordenador es de la empresa, pero siempre acabas teniendo algunas cosas personales. Para evitar esto utilizamos una máquina virtual para dejar todos esos programas instalados y así que varias personas pudiesen utilizarla.

– Facilitar el realizar pruebas

Antes de la existencia de la virtualización, cuantas veces no hemos tenido que utilizar nuestro ordenador para probar programas, que al final acaban dejando basurilla en el ordenador haciendo que no vaya muy fino. Y al final teniendo que gastar tiempo en reinstalarlo.

Con las máquinas virtuales te puedes permitir tener máquinas de usar y tirar para realizar estas pruebas. Con una plantilla de cada tipo de instalación que utilices puedes crearte las máquinas que necesites.

– Facilitar tener configuraciones del cliente

A todos los que nos gusta tener versiones actualizadas de los programas que usamos, sobre todo navegadores, el tener que utilizar versiones homologadas por los clientes es un poco fastidio, sobre todo cuando son versiones muy viejas.

Y el problema ya se complica si trabajas para diferentes clientes, cada uno con sus versiones diferentes.

La virtualización te permite tener máquinas con la configuración requerida, y usarlas solo para realizar esas pruebas.

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.