[English version]

Cuando comenzamos el desarrollo de un nuevo sistema software debemos responder a varias preguntas. Probablemente podemos estar tentados de enfocarnos sobre los aspectos arquitectónicos o la selección de la tecnología. Pero, existe un aspecto clave que no debemos olvidar, el usuario.

01_POST_SEPT

Por muy obvio que pueda parecer, desarrollamos aplicaciones para las personas que van a emplearlas. Y como sabemos bien, cuando las personas intervienen entran en juego otras variables, tales como las sensaciones o los sentimientos. De tal forma que todo el trabajo realizado puede cuestionarse, alabarse u odiarse en cuestión de minutos u horas, por no mencionar si los bugs empiezan a hacer acto de presencia.

Supongamos que somos un chico de backend, podríamos decir que el color del botón no es nuestro problema, si, por otra parte, lo que somos es de front, furiosamente trasladaríamos que el rendimiento de la base de datos tampoco es nuestro y siempre, siempre, podríamos culpar a la chica responsable del API de los errores de comunicación porque no ha definido interfaces claros. Si te sientes identificado con alguna de estas situaciones, lamento decirte que tú y tu equipo tenéis un problema. Los usuarios ven el sistema como un todo, así que les da un poco igual dónde está el problema, lo que saben es que aquello no funciona como se suponía.00_POST_SEPTPor tanto, si asumimos que nos debemos focalizar en los usuarios, la pregunta debiera ser: ¿por dónde empezamos? La respuesta no puede ser más simple, por las interacciones de los usuarios. Espera un momento, ¿de qué estas hablando? Dejadme que os lo explique de otra forma:

Tu esfuerzo principal debería estar en proporcionar a tu usuario un entorno de trabajo real en el que pueda verificar que el software funciona como espera.

En realidad, tener éxito en el desempeño de esta tarea implica tomar una aproximación doble: tanto primero el front como modular. Antes de entrar en detalle sí que me gustaría indicaros que cuando hablo de front no tengo porque referirme a un interfaz de usuario Web o APP, sino que también puedo hablar de un API si tu producto o proyecto está orientado a desarrolladores y lo que proporcionas es un interfaz REST, OpenGraph o lo que sea.

Una vez definido a que tipo de frontend me refiero, paso a analizar los puntos clave que deberían considerarse, lógicamente no todos aplican a todo tipo de aplicación, pero, espero, me sepáis disculpar.

• En primer lugar un entorno de trabajo operativo no es un prototipo del UI, sino un sistema sobre el que usuario puede interactuar, reactivo a las entradas del usuario y que ofrece diferentes salidas en función de las peticiones realizadas.
• Un entorno de trabajo operativo no es un entorno terminado sino en crecimiento continuo, en el que añadimos funcionalidades, pero siempre desde un punto de vista de lógica global del sistema. Es decir, si un punto crítico de la aplicación es la autenticación del usuario, será ésta una de las primeras iteraciones a incluir dentro de nuestra emulación.
• Todos los cambios deben entregarse los antes posible, pero sin afectar a aquellos módulos que ya han sido desarrollados y probados. Eso implica que no podemos construir el sistema como un pequeño – o gran – monstruo sino que debemos adoptar una estrategia de desarrollo modular.
• Si en nuestra aplicación accedemos a un API o una capa de middleware, el diseño de esta debería ser como consecuencia de las expectativas de frontend y no al revés. Considerando la arquitectura modular comentada anteriormente, nuestro API tampoco sería un monolito sino un conjunto de APIS independientes, aunque lógicamente relacionadas.
• Una vez que nuestra capa front se adecúa a las expectativas del usuario, podemos comenzar el desarrollo de la capa de back. Aunque sea una obviedad, nunca me canso de repetir que es el back el último responsable del control de datos, seguridad y calidad de los datos entrantes y salientes. Así que, si hay que duplicar chequeos, comprobaciones y demás, ¡hagámoslo! En realidad, los chequeos de front y back tienen objetivos distintos.
• Por supuesto, no podemos olvidar nuestra responsabilidad como desarrolladores, eso significa calidad y eso involucra testing. Por tanto, realizar tests unitarios, con una aproximación orientada – lógicamente – a probar el comportamiento, es algo imprescindible para todas las capas involucradas.

02_POST_SEPT

Recordad que antes os comentaba que nuestro front podría ser, en realidad, un API o librería, en ese caso existen una serie de características que deberían ser tenidas en cuenta.

• Debemos enfocarnos en lo que los desarrolladores esperan y no crear pesadillas sin sentido. De hecho, hay cientos de APIS que están realmente mal diseñadas, incluso las comerciales.
• Incluid buenos comentarios, tanto para los métodos como para los objetos de entrada y salida.
• Indicar de forma precisa y clara, que es requerido y que no lo es.
• Mantener un número mínimo, pero suficiente, de objetos y métodos. Abstraigamos cuando sea posible y evitemos la duplicidad de objetos y funciones que hacen cosas sólo ligeramente distintas.

En cualquier caso, esta aproximación involucre decisiones arquitectónicas en las que la modularidad y el uso de mocks son esenciales. De esta forma y desde un punto de vista puramente técnico, ¿cómo deberíamos crear nuestra pila tecnológica? En mi opinión existen diferentes aproximaciones que podrían tomarse en consideración,

• Deberíamos utilizar una arquitectura de frontend que nos permita una adecuada separación de "conceptos". Por favor, ¡no mezcléis el acceso a los datos y el pintado de los mismos en la pantalla! Probablemente vuestra pantalla de pintado cambie mucho pero es menos probable que lo hagan los mecanismos de acceso a la información. El aislamiento es clave para prevenir errores y, además, cuanto más aisladas estén las capas más sencillo será la realización de mocks.
• No trabajamos solos, así que debemos involucrar a nuestros compañeros de back y/o middleware o incluso a los arquitectos software, si ese es vuestro flujo de trabajo, para definir adecuadamente como van a funcionar las interacciones de tal forma que, por ejemplo, evitemos duplicidades, y definamos las abstracciones adecuadas.
• En la capa de front, dad un tiento a arquitecturas basadas en micro-frontends en las que utilizaremos un agregador que proporcione funciones transversales tales como autenticación global, inclusión de los micro-frontend, comunicaciones globales, capa de logging, etc.
• En la capa de back cualquier opción modular puede valer, desde un monolito modular – utilizando diferentes ClassLoader si utilizáis una aplicación basada en Java – o una arquitectura basada en microservicios. No voy a entrar a discutir cual es mejor. En realidad, ¡depende! Aunque, si me preguntáis mi opinión, soy un gran fan de los monolitos modulares.

Por mi experiencia, implementar este mecanismo de trabajo en nuestro proceso de desarrollo de software es un escenario ganar-ganar. Por una parte, el usuario estará involucrado desde el comienzo, de tal forma que su satisfacción incrementará. Por otra parte, nosotros como desarrolladores estaremos enfocados en la funcionalidad y en el valor, evitando así futuros problemas.

En resumen, involucrar a los usuarios desde el comienzo, proporcionándoles un entorno de trabajo real y ser ágiles en ofrecer resultados son esenciales y diferenciales. La tecnología es importante, pero está más relacionada con aspectos tales como el mantenimiento y la extensibilidad que con la satisfacción inicial del usuario. Como podéis ver, desarrollar software es una tarea compleja.

Si te interesa lo que hacemos, cómo trabajamos y crees que podemos aportarte no dudes en aplicar a nuestras ofertas de empleo.