TinselCity

Finalmente me decidí a dar en público la charla de Pensando en Arquitectura, en Madrid y en Zaragoza. Publiqué también las notas de la charla pero son poco útiles, me temo, y alguien puede preferir leer que escucharme farfullando y agitando las manos, así que me he decidido a intentar poner aquí estas ideas por escrito para que… bueno, por si acaso.

Pensando en Front-end

Aunque no haya sido intencionado y, mirando atrás, probablemente ahora hiciera las cosas de otra forma, mi carrera profesional me ha ido llevando a enfocarme en el desarrollo web y más concretamente en la parte del front-end. Y a medida que iba evolucionando en esto, ya desde hace… qué sé yo, n años, me iba dando cuenta de que es un área bastante “maltratada” del desarrollo. En concreto, siempre he tenido la sensación no sólo de que se veía como algo secundario en importancia, sino que además se trataba como algo donde, por algún extraño motivo, no era necesario aplicar las mismas prácticas de buen desarrollo que se aplicaban en otras áreas.

Así, alrededor del año 2010, me encontré con la situación bastante general de un montón de gente que se ponía a usar JavaScript sin querer hacerlo y, por tanto, sin intentar entenderlo. De ahí termino surgiendo una charla que llamé “Pensando en JavaScript”. El título aunque pueda parecer inspirarse en los libros de Bruce Eckel, era mucho menos ambicioso y sólo hacía referencia a una película de Clint Eastwood: Firefox. En el momento clave de la historia, la voz en off le recordaba que si quería poder manejar los sistemas avanzados de armamento del avión que acababa de robar, debía…

“Recuerde! Debe pensar en ruso!” (con un falso acento ruso de película).

La charla pretendía dar una visión del lenguaje centrada en comprender cómo funcionaban los detalles. Di la charla 3 ó 4 veces, hasta que pensé que era suficiente y me cansé.

Era un paso muy básico. No iba a solucionar el problema general de la tierra quemada que era (¿es?) el front-end en cuanto a calidad y hacer las cosas bien, pero por lo menos era un primer paso que podía intentar aportar. Con los años la situación ha mejorado. No gracias a mi, evidentemente, ni tampoco ha mejorado muchísimo, pero reconozco que ha mejorado. Sin embargo, han ido apareciendo problemas más avanzados. Y con eso, hace un par de años pensé en dar una vuelta a las historias que iba viendo, intentando buscar alguna forma sencilla de afrontarlo. No era tanto un interés personal sino un intento de hacer entender a la gente que el caos, el desconcierto, el despropósito en muchos casos, en que se convertía el desarrollo de front-end no tenía por qué ser así, que podía ser algo más razonable.

No creo que esta especie de segunda parte espiritual de charla realmente pueda conseguir eso. Pero decidí por lo menos intentar con un nuevo título, “Pensando en Arquitectura”, sacar algunas ideas que puedan ayudar a algunos a encontrar alguna forma de sentido en ese caos, de recuperar, por lo menos, un poco de orientación.

Probablemente el síntoma más claro de toda esa confusión y caos sea eso que alguien llamó “JavaScript Fatigue”. No voy a entrar en ese tema, pero lo tomo como síntoma del caos. Y así, una parte de la inspiración podría ser otra película, una mala, incluso peor que Firefox: Si hoy es martes esto debe ser Polymer… perdón, Si hoy es martes, esto debe ser Bélgica.

Pensando en Arquitectura

Me interesa tratar un par de temas principales. Con algunos añadidos, al final, vamos a ver estos:

  • Qué es la Arquitectura de Software y cómo hacerlo.
  • Las particularidades que pueda tener (o no) la Arquitectura en el área del Front-end.
  • El papel de los frameworks/librerías/etc y cómo tratarlos.

¿Qué es Arquitectura?

Hay tantas definiciones de la Arquitectura de software, que a veces me llego a preguntar si realmente el nombre, la palabra arquitectura, está bien elegida. El caso que es difícil encontrar una definición que sea sencilla pero que consiga capturar la esencia del concepto. Así que opté por la solución fácil: crear mi propia definición :)

Quizá más que una definición completa, sea una definición que se adapta bien a una determinada perspectiva desde la que observar la Arquitectura. Así puede que queden aspectos sin tratar; aspectos que sin duda son importantes pero que prefiero dejar a un lado para centrarme más en esta perspectiva elegida. Creo que es una buena forma de ver la Arquitectura y creo que los otros aspectos se pueden añadir después con cierta facilidad.

Hay muchas ideas ya establecidas sobre la Arquitectura y muchas de ellas equivocadas. Una muy tradicional es verla como un producto, un entregable que generalmente tiene forma de diagramas de cajas y flechas, quizá acompañados de documentos escritos con descripciones de sistemas. Habitualmente esto está producido por un “arquitecto”, situado en algún tipo de nivel superior al de los meros mortales. También he visto en el último año una idea francamente estúpida que presenta la Arquitectura como la organización, la estructura del código en ficheros y carpetas, con unos ciertos nombres y en un árbol de cierta forma. Y cómo no, también me he encontrado numerosas veces, por ejemplo al preguntar por la Arquitectura de un proyecto en una entrevista, gente que simplemente dice “Nuestra arquitectura? Ah, pues React”.

Si hay algo que tengo claro es que, al menos para mi, la Arquitectura no es un producto sino un proceso.

La Arquitectura de Software es el proceso o actividad de tomar decisiones que tienen un impacto no-inmediato y/o no-local en el dominio del proyecto.

Durante el desarrollo de cualquier proyecto tomamos muchas decisiones, desde nombrar una función hasta incorporar un bus de eventos pasando por hacer 3 equipos de 4 personas o 2 de 6, pero está claro que no todas las decisiones tienen la misma naturaleza. Sobre todo lo que las va a distinguir van a ser las consecuencias que toda decisión tiene. El nombre de una variable local, por ejemplo no tiene impacto más allá del alcance donde está definida. Cómo organizar nuestros equipos seguramente afecte a todo el desarrollo del proyecto de alguna forma. La Arquitectura es la actividad de tomar esas decisiones que tienen impacto.

Puede ser interesante plantearse cómo hacer esto -tomar decisiones- pero quizá antes sea bueno ver quién lo hace. Tradicionalmente estaba ese arquitecto que comentaba, una persona que generalmente está separada del desarrollo en sí, alguien que no escribe código sino que su labor principal es esa toma de decisiones. Yo esto lo veo como un error grave. Creo que es fundamental que la Arquitectura la hagan personas que están directamente involucradas en el día a día del código y del proyecto. Pregunté en Twitter qué era un arquitecto y tuve las dos mejores respuestas que podía tener. En la primera:

 Alguien con experiencia

El arquitecto es un programador, uno con experiencia suficiente como para aconsejar a otros. Pero claro…

 Alguien que no sabe de lo que habla

…también puede ser que vaya por ahí dando consejos sin tener ni idea m( En fin, con lo que sí me quedo es con que tiene que ser un programador y con que, de alguna forma, les dice cosas a otros.

Cómo hacer Arquitectura

Inocentemente se me ocurrió buscar en Google algo así como “cómo tomar decisiones”. El primer resultado es un prometedor, aunque algo grandilocuente, enlace que dice que “saber tomar decisiones es lo más importante en tu vida”. Luego, cuando pinchas en el enlace, resulta ser un blog chufa de uno que intenta convencerte de que dejar tu trabajo y hacerte bloguero profesional puede ser la mejor decisión del mundo. Oops. La misma búsqueda en Duck Duck Go me lleva a un mucho más prometedor how-to de WikiHow. Pero igualmente, al leerlo la cosa empieza con un… “Paso 1. Comprender el origen de tu miedo” y “Paso 2. Identifica el peor escenario posible”. Después de esa aproximación tan optimista decidí no leer más.

Pero en el fondo es esto, tomar decisiones. Así que tengo un buen modelo de cómo hacerlo en 5 pasos.

  • Identificar la necesidad. Obviamente si no sabemos qué necesidades tenemos, difícil será que podamos decidir sobre ellas. Además, para poder identificar esas necesidades, hay que ser consciente de que pueden tener formas muy diversas. Algunas serán puramente técnicas y otras no.
  • Conocer las opciones. Esta es la parte más tradicionalmente asociada a la Arquitectura. Saber. Generalmente asociado a eso de la experiencia, aunque es importante mantener ese conocimiento al día y cuando no lo tengamos, ser capaces de investigar.
  • Saber evaluarlas. De nuevo aquí hay una labor que viene facilitada por la experiencia. Pero no sólo puede basarse en eso. Necesitamos investigar, probar, evaluar las opciones que hay ahora, en este proyecto. Y saber evaluarlas significa ser capaces de comprender estas opciones, apreciando tanto las ventajas que nos ofrecen como las desventajas que incluyen. Siempre habrá ambas cosas y siempre debemos tener en cuanta ambas.
  • Asumir riesgos y compromisos. Toda decisión lleva asociados, queramos o no, unos riesgos y el único modo de poder decir que realmente estamos tomando esa decisión es si reconocemos y asumimos esos riesgos y el compromiso que supone llevarla a cabo. Es más, no asumir esto, es una grave falta de profesionalidad y de responsabilidad.
  • Comprobar los resultados. ¿De qué serviría tomar decisiones, asumir compromisos y riesgos, si después de llevarlas a cabo no hacemos una evaluación del resultado? Es el único modo tanto de aprender como de poder mejorar.

Además de esto, que es la tarea fundamental de tomar la decisión existen, por supuesto, toda una ser de tareas adicionales. No son menos importantes, sino que son tareas que necesariamente acompañan a esa toma de decisiones razonada y responsable. Así, necesitaremos aún hacer muchas otras cosas como implementar la decisión, que en muchos casos exige esa proximidad al código (insisto, no tiene sentido ver la arquitectura como algo separado del código). O todas las actividades de comunicación: Deberemos presentar al resto del equipo la decisión, ofrecer formación si es necesaria, ofrecer apoyo o motivación… Y por supuesto liderar la adopción de las decisiones. Habría mucho que decir sobre ese “liderazgo”, pero creo que se sale del alcance de este artículo.

La Arquitectura en el Front-end

Durante demasiado tiempo he visto cómo prácticas y procesos que son aplicadas de froma habitual en otras áreas, se descuidan enormemente en el área de Front-end. No me interesa demasiado buscar culpables u orígenes en este momento, aunque tengo algunas teorías, pero creo que podría ser interesante meditar si acaso hay algo diferente, específico del área de Front-end que dificulte esa aplicación.

Yo he encontrado que hay un factor que puede tener cierta influencia. Sé que hay otros y que dejo de lado algunos -como la formación de los desarrolladores de front-end, por ejemplo- que pueden ser importantes. Pero creo que esos otros no son tan sólidos, ni tan externos. La formación la podemos mejorar… la debemos mejorar día a día en cualquier caso. Y aunque es cierto que he visto muchas personas con una formación deficiente, también he visto muchos con mucha disposición de mejorar.

El factor que comentaba es el cambio. Cambio entendido en un sentido amplio, no sólo como cambio en el tiempo, sino también como variabilidad en otros aspectos.

Y, ojo, entiendo que el cambio es algo fuertemente presente en cualquier área del desarrollo. La diferencia en el front-end está en la magnitud. Creo sinceramente que la naturaleza abierta de la web como plataforma produce que el cambio, la variabilidad, sea mucho más intensa en el área de front que en otras. Estándares (o pseudo-estándares) que evolucionan más rápidamente, dispositivos con cientos de morfologías variadas y capacidades diferentes… Incluso los lenguajes, aunque no sean los cambios tan grandes o tan interesantes como algunos creen, han estado cambiando con cierta velocidad. Es más, tengo la impresión de que incluso los cambios por necesidades de negocio, tienden a afectar más frecuentemente a la parte de front por ser “lo que más se ve” (aunque eso sí, no siempre afectan con la misma profundidad que pueden afectar en otras áreas).

También existen algunas pequeñas restricciones que son más propias del front-end. Los temas de ejecución, por ejemplo. Tener que poder funcionar en tantos dispositivos en los que no tenemos ningún control sobre el rendimiento, nos puede obligar a ciertos sacrificios o a tener que tener en cuenta estos factores de una forma más prioritaria al tomar algunas decisiones. En back-end, por ejemplo, el problema está mucho más bajo control. Podremos tener restricciones de máquinas, memoria, CPU, etc, pero en general somos nosotros los que las decidimos (dentro de un presupuesto, claro está).

En cualquier caso, no creo que el área del front-end sea tan diferente de otras. Es cierto que el cambio puede ser mayor, pero conocido esto, gestionarlo no tiene porqué ser muy distinto de otras cosas. En cada caso, eso sí, dependiendo de las circunstancias, el cambio nos llevará a adoptar unas soluciones u otras. Según la capacidad de nuestro equipo podríamos, por ejemplo, centrarnos más en la resiliencia, buscando esa tolerancia a fallos que nos permita ofrecer la funcionalidad fundamental en cualquier caso, o podríamos buscar la rapidez de reacción, con un código mantenible ante todo y un equipo sólido que nos permita producir una solución “al momento” en cuanto encontremos un problema. O podríamos en otro caso diferente decidir restringir la plataforma, sólo soportar navegadores modernos, por ejemplo, o hacer la aplicación sólo para desktop o sólo para móvil, si sabemos que no va a tener otros usos (porque, por ejemplo, sabemos que es una aplicación interna y conocemos las necesidades de todos los usuarios). O podríamos en otro caso más no preocuparnos en absoluto ni invertir en estas cosas porque sabemos que es un prototipo de usar y tirar, que en un mes va a haber llegado al final de su vida útil. Depende.

En cada caso y circunstancia, la decisión será la que mejor se adapte. Pero por lo que yo he podido ver, no creo que el front-end tenga nada tan específicamente diferente como para aplicar otros criterios diferentes o dejar de lado buenas costumbres del desarrollo en general.

El papel de los frameworks

Hablar de frameworks, de su uso, es muy aburrido. Desde nuestra perspectiva de la Arquitectura como toma de decisiones, es incluso más aburrido aún. Desde este punto de vista, los frameworks son “una arquitectura de una sola decisión”.

Lógicamente esa decisión es responder a la pregunta de “¿Qué framework uso para mi proyecto?”, y supongo que no soy el único que está cansado de oírla o leerla en cientos de ocasiones. El problema con esta aproximación es el mismo que hay con cualquier otra decisión… pero más grande. El propio tamaño de la decisión en sí, una decisión que afecta a todo el proyecto y en tantos aspectos, hace que todo se amplifique.

La evaluación de opciones es más costosa. Pero sobre todo, el riesgo es mucho mayor. Me recuerda esas partidas de póquer que veía alguna vez en la televisión cuando mi insomnio era peor… Iban jugando tranquilamente, apostando un poco o un poco más. Y de repente alguien empezaba a subir la apuesta, terminaba en un all-in y en una sola mano perdía todos sus millones de fichas y se quedaba eliminado.

Porque además podemos pensar que bueno, estamos apostando sobre algo sólido, que otras muchas personas han apostado a lo mismo, así que debe ser una buena apuesta. Pero incluso esto es un problema adicional que muchas veces no notamos. Estamos compartiendo la toma de esa decisión con cientos, miles de otros proyectos que, muy probablemente, no tienen las mismas circunstancias que nosotros. Así, ese framework tiene, por necesidad, que dar una respuesta más genérica. Solucionará el problema común que muchos tienen, pero a cambio será muy difícil que solucione los detalles específicos de nuestra necesidad. O peor, el framework puede intentar adoptar una práctica inclusiva, tratando de abarcar cada vez más detalles… Detalles de otros. Quizá los nuestros también, con un poco de suerte, pero a cambio estaremos cargando con las necesidades de todo el resto.

Y con el tiempo todo esto termina notándose. No importa cuál elijamos, los detalles terminarán saliendo a la superficie y, a la larga, la probabilidad de que tengamos una fricción que eleve el coste de usar ese framework al mismo nivel del beneficio que nos aporta, es alta. Más aún cuando muchos de estos frameworks que van surgiendo un día cualquiera, muchas veces se interesan por cabalgar olas, más que por navegar a un destino.

Estrategias y/o alternativas

Con todo esto no quiero decir que usar un framework sea algo malo. Como todo tiene sus ventajas y desventajas. Lo que sí quiero decir es que el riesgo y coste son suficientemente altos como para hacernos considerar algunas estrategias alternativas.

Algunos frameworks optan por ofrecer un riesgo “sobre algo más seguro”. Por ejemplo, Polymer presenta la idea de construir sobre estándares. Sin embargo, viendo el estado de Polymer y la evolución de esos (futuros) estándares, no parece que esto sea una solución sino, como mucho, un apaño. Algo similar ocurre cuando un framework “tiene una gran empresa detrás”, como React o Angular. Sí, esto puede dar más garantía de longevidad, de soporte, etc. Pero nada asegura que nuestros intereses y necesidades sean los mismos de esa gran empresa. Nombro alguno, pero todos los “grandes frameworks” (y no tan grandes) pueden tener estos mismos problemas. Y nada de estas cosas realmente soluciona nuestro problema de tener que asumir un gran riesgo.

He pensado algunas opciones:

  • Fraccionar el riesgo. Este es un concepto que ya aplicamos todos los días: Modularidad. Igual que modularizamos nuestro código, podemos modularizar las decisiones. Podemos buscar soluciones más pequeñas, separar una necesidad grande en varias necesidades independientes y buscar una solución para cada una de ellas. Por esto me gustan más frameworks pequeños, que se centran en un aspecto, nos ofrecen una solución y nos dejan los medios para hacer el resto según nuestra necesidad. Ojo, que algunos parecen ofrecer esto pero luego terminamos teniendo que elegir otras soluciones fijas para otras partes.
  • Mejorar la información. No siempre es posible retrasar una decisión así. Pero siempre que podamos, mejoraremos la información que tenemos para tomar la decisión. “Deja para mañana la decisión que no tengas clara hoy” – decía el libro The Wary Programmer (El Programador Desconfiado). Es un gran riesgo ya antes de empezar un proyecto, hacer un create-react-app, ng new, Ember new, vue init o cualquier otro similar, cuando aún ni siquiera sabemos qué vamos a necesitar.
  • Estudiar los frameworks. Sigo diciendo que los frameworks son aburridos. Sobre todo su uso. Pero a veces podemos mirar en su interior y ver cómo uno o varios implementan determinada solución. Extraemos la idea el conocimiento, y -dependiendo del caso- podemos decidir implementarla nosotros. Se trata así de importar ideas, no dependencias. La idea puede ayudarnos a crecer y más adelante podremos plantearnos también descartar nuestra implementación si encontramos una mejor, con un coste más bajo.

Conclusiones

No tengo muchas conclusiones, la verdad. Me gusta esta visión de la Arquitectura como proceso de toma de decisiones. Creo que puede ayudar bastante verlo así. No creo tampoco que el front-end sea tan diferente como para necesitar soluciones muy distintas a otras áreas, aunque si tenga alguna peculiaridad -como ese cambio desbocado- que debemos tener en cuenta. Creo también que los frameworks tienen sus usos, pero que es mejor tratar de buscar decisiones más pequeñas. Estamos arriesgando proyectos y presupuestos que involucran a más gente y tenemos la responsabilidad de asumir riesgos y compromisos de forma razonable.

Finalmente, aunque llevo tiempo dando vueltas a estas ideas y me haya decidido a dejarlas por escrito o en una charla, no creo que nada de esto sea suficientemente estable aún. Me encantaría conocer y discutir opiniones de quien quiera compartirlas. Es más, no creo que mi charla vaya a ayudar a casi nadie, pero sin embargo sí creo que ese debate abierto puede hacerlo y que es necesario e interesante para todos.

Dejo abierta la posibilidad de comentar aquí abajo para quien quiera.

Discussion

Enter your comment. Wiki syntax is allowed: