Priorizando la Arquitectura Sobre el Framework en el Desarrollo Web

Hola a todos. Mi nombre es Alexandre Rivet, y bienvenidos a mi charla sobre valorar la arquitectura sobre el framework en el desarrollo web. Un poco sobre mí, soy canadiense. Vivo en la ciudad de Quebec, así que soy francés. Y soy un desarrollador front-end senior en NextApp desde hace nueve años. NextApp es una empresa constante, así que he visto muchos proyectos usando diferentes lenguajes, bibliotecas, herramientas, frameworks, lo que sea. Debido a eso, tuve que aprender formas de ser eficiente en mi trabajo sin enfocarme demasiado en tecnologías específicas. Y una de las formas de lograr esto es enfocándome en la arquitectura. Por eso es mi tema de hoy.

Por lo que he visto en los múltiples proyectos de React en los que he trabajado para mis clientes, mucha gente tiende a pensar solo en React y las nuevas herramientas que acaban de salir. Sin embargo, si solo te enfocas en tecnologías, terminarás con el proyecto difícil de mantener. Bueno, tal vez no para ti, pero tal vez porque lo diseñaste. Pero lo será para los recién llegados al proyecto. Y esa es básicamente mi situación en muchos proyectos.

Así que, el año pasado, me pregunté por qué teníamos tantas dificultades trabajando en STEM que no diseñamos nosotros mismos. Comencé a buscar en línea por qué la verdadera razón detrás de esto, y me encontré con una presentación llamada Cómo Leer Código Complejo. Fue una charla dada por Filiane Hermann, quien es de Ámsterdam. Aprendí recientemente. Ella también escribió un libro llamado El Cerebro del Programador. Y Filiane establece un vínculo entre el funcionamiento de nuestra memoria y cómo ayudarnos a ser mejores en programación.

Para explicar mi punto sobre la arquitectura, voy a tomar prestado uno de sus ejercicios. Voy a mostrarles brevemente símbolos. Traten de recordar tantos símbolos como sea posible, lo suficiente como para poder dibujarlos. Va a ir muy rápido. ¿Están listos? Tres, dos, uno. Eso fue muy rápido, ¿verdad? ¿Serían capaces de reproducir toda la serie? Probablemente no, y eso es normal. La gente tiende a recordar alrededor de tres símbolos cuando se los muestro. Cuando vemos algo, la información pasa por nuestra memoria a corto plazo.

Así que, a pesar de esto, si muestro un símbolo nuevamente, será más fácil para él recordarlo. Eso es porque después de ver la información, nuestro cerebro comienza a interpretarla. La interpretación la realiza nuestra memoria de trabajo. Analiza la información y decide qué hacer con ella. Sin embargo, si toma demasiado tiempo, la información se perderá en la memoria a corto plazo para nueva información. Cuando estás agotado después de un largo día de trabajo codificando, la mayoría de las veces es porque tu memoria de trabajo ha sido sobrecargada.

En francés, decimos que estamos sin jugo de cerebro. Una cosa importante que decir es que la memoria de trabajo no depende solo de la memoria a corto plazo. Para probar eso, vamos a hacer el mismo ejercicio pero con un pequeño giro. Voy a mostrarte un símbolo. Trata de recordar tanto como sea posible en el corto período de tiempo. ¿Listo? Tres, dos, uno. Si te pido que escribas lo que viste, sería más fácil, ¿verdad? Eso es porque reconocemos esos símbolos. Eran letras.

Eso es porque nuestra memoria a largo plazo apoya a nuestra memoria de trabajo en el análisis de lo que hemos visto. Hemos entrenado nuestra memoria a largo plazo toda nuestra vida para reconocer estas letras. El mismo principio se puede aplicar en programación. Si digo public void if else, use state props para React-specific. Todos esos son conceptos que hemos aprendido a reconocer rápidamente porque los hemos visto muchas veces, y creamos memoria a largo plazo sobre ellos. Así que no tenemos que preguntarnos, ¿qué significa? Simplemente lo sabemos. Nos hace leer el código más rápido.

No es suficiente encontrar fácilmente nuestro camino en el código y entender rápidamente lo que está sucediendo. Incluso si línea por línea, tuviéramos información para entenderlo, nuestra memoria a corto plazo se vuelve insuficiente. Como dije, de dos a seis elementos como máximo a la vez. No estoy seguro si ya estaba en el libro, pero este es un punto interesante en relación con esta métrica. ¿Por qué somos capaces de entender palabras de más de seis letras si nuestra memoria a corto plazo es tan limitada?

Haremos una última versión del mismo ejercicio. Así que, aún los símbolos, trata de recordar tanto como puedas. ¿Listo? Tres, dos, uno. ¿Captaste lo que estaba escrito? Cuando doy esta charla frente a una multitud, hago que toda la audiencia diga cats love cake al mismo tiempo. Es mágico. ¿Por qué fue tan fácil? Bueno, porque era el mismo número de letras en el mismo ejercicio, pero ahora, ¿lograste recordar todo? La solución es bastante simple.

Nuestro cerebro es excelente agrupando o fragmentando información. Nuestro cerebro puede asociar un conjunto de letras, crear un concepto único. Cuando ves las letras CAT, no piensas en esas tres letras. Se convierten en uno con el concepto de un gato porque creaste memoria a largo plazo sobre esos siendo el animal. Los cerebros humanos son excelentes para reconocer patrones. Crear asociaciones en nuestra memoria a largo plazo ayuda enormemente a nuestra memoria de trabajo a interpretar la información rápidamente.

Para hacer grandes aplicaciones de React que sean fáciles de trabajar, necesitamos formas de crear memorias a largo plazo útiles que puedan ayudar a nuestra memoria de trabajo. Ahora, ¿cómo hacemos eso en React? Voy a darte un par de consejos. El primero, usa componentes. Esto es básicamente el rasgo más conocido de los cuatro. Puede sonar obvio para algunos, pero he trabajado en proyectos donde cada página era un solo componente, un solo archivo de dos mil quinientas líneas de código. Así que, incluso después de trabajar meses en este archivo, todavía me perdía. Así que, crear componentes con nombres que representen lo que realmente hace. Es el mismo principio que dar nombres y variables a variables o funciones.

Y es más útil crear memoria a largo plazo sobre los nombres de los componentes que qué línea de código contiene qué tiempo de código contiene lo que estás buscando. Los mismos consejos, cuidado con demasiadas dependencias. Digamos que tienes una gran aplicación y has creado muchos componentes, bueno, nombre y todo. Pero todavía tienes problemas para encontrar lo que estás buscando en la base de código. ¿Por qué es eso? Una de las razones que veo en muchos proyectos es por la dependencia externa utilizada en el componente. Digamos, por ejemplo, que quieres tener un estado global en tu aplicación. Puedes usar el context API o Redux o Xtend, tú lo nombras. No es importante. Esas herramientas te permiten acceder a estados en cualquier componente que desees. En teoría, esta es una gran característica que previene problemas.

En la práctica, puede ser bastante peligrosa. Al requerir un valor, se vuelve fácil simplemente agregar un nuevo selector al componente y listo, tienes acceso al valor. Sin embargo, si repites esta acción una y otra vez, podrías obtener algo como esto, donde la mayoría de tus componentes se vuelven dependientes de tu estado global. Ya no reciben props. Simplemente van a la información por sí mismos. Necesito ser claro sobre algo. Esto no es culpa de la biblioteca que estás usando. Esto es una ley de arquitectura. Dado que tienes un problema relacionado con el estado global, ¿cómo puedes saber cuál es el culpable? Y si eres nuevo en tu proyecto, buena suerte encontrando el problema por ti mismo.

Estarás aquí por un tiempo. Entonces, ¿qué podemos cambiar en nuestra arquitectura para desarrollar una memoria a largo plazo de nuestro código y encontrar problemas más rápido? Bueno, antes de la llegada de los hooks en React en los viejos tiempos, había un patrón desarrollado por la comunidad para separar la lógica de la aplicación de la lógica de renderizado. Había dos nombres para ello. El componente versus contenedor o el componente DOM versus componente inteligente. El componente DOM recibe props y renderiza HTML. Eso es todo. No hay dependencias externas, excepto las props. Los componentes inteligentes se encargan de obtener información, manejar el estado y dar datos al componente DOM como props. No hacen mucho renderizado excepto alimentar información. Los componentes inteligentes suelen estar en la raíz de un árbol de conceptos. Una pieza que puede ser directamente independiente del resto de la página, el resto de la aplicación. Y normalmente, al aplicar este patrón, obtendrás principalmente componentes DOM en tu aplicación y unos pocos componentes inteligentes.

Así que, en tu árbol, tendrás menos dependencias de tu gestión de estado global, por lo que tendrás menos puntos de fallo en tu problema. Se vuelve más fácil crear memorias a largo plazo del estado global ya que hay menos componentes directamente impactados por él. Recibir esta información múltiples veces también crea la memoria, hace que la memoria sea más duradera. Si quieres tener aún más memoria a largo plazo sobre esto, incluso puedes dar nombre a los componentes inteligentes que haga más obvio que tienen esta lógica. Por ejemplo, tal vez podrías usar el añadir un sufijo al nombre de tus componentes. La descripción no es importante siempre que lo haga más claro, más obvio.

El tercer consejo para ti es hacer las APIs independientes. En aplicaciones de una sola página, una de las características más frecuentes que veo es que la aplicación necesita cargar contenido desde una API, desde un servidor. Hay algunas bibliotecas que te ofrecen manejar todo lo que gira alrededor de la llamada a la API. Un ejemplo de eso es un proyecto en el que trabajé donde decidimos usar GraphQL porque era algo nuevo y brillante. REST estaba muerto, larga vida a GraphQL. Así que, haremos la solicitud de esta manera. Crearemos, definiremos una consulta y usaremos el use query de la biblioteca que estamos usando para obtener la información y tener estado de carga, estado de error, y así sucesivamente. En mi ejemplo aquí, uso Apollo, pero no es el único que ofrece este patrón. Relay, Redux Toolkit, y muchos otros también lo hacen. Eso es solo para el ejemplo. En un momento, descubrimos que GraphQL nos estaba ralentizando más que usar una simple API REST para nuestro caso de uso. No era un caso de uso para nosotros.

Pero, estábamos un poco atrapados allí, porque nuestros componentes de React dependían de las consultas de GraphQL. Como puedes ver en nuestro componente Pokemon sensors. ¿Qué deberíamos haber hecho en su lugar? Bueno, hoy en día tendemos a crear clientes que abstraen nuestro trabajo con la API. Esto nos da más flexibilidad en cómo nos comunicamos con el back end. Así que, por ejemplo, para este ejemplo, el cliente de Pokemon con la función get Pokemon, y ahí está mi consulta en él. Pero, en mi componente, puedo hacerlo de la manera que quiera. Podría usar el use hook para obtener la información con un suspense. Si quiero la misma funcionalidad que el use query de Apollo, por ejemplo, podría usar React query de 10 stack, que solo maneja la gestión. No tiene nada que ver con la API. Si decido que quiero usar esta llamada de API en un componente de servidor, podría simplemente llamar al get Pokemon en el mismo componente, en un componente de servidor de React. También podría usarlo en una aplicación React native, porque mi API es independiente de la UI. Hay muchas piezas de código que se pueden extraer de los componentes de React, y esta es la primera.

La segunda que puedo darte, este es el último paso de hoy, es la lógica de negocio. Esta lógica corresponde a toda la lógica de negocio de tu producto, el tipo de lógica que puedes discutir con alguien que no es programador. Alguien que no conoce React, bueno, es la lógica que gira en torno al modelo de negocio de tu producto. Por ejemplo, digamos que decides hacer un sitio web de compras donde tienes un carrito, puedes añadir artículos a tu carrito, y puedes finalizar la compra y comprar todo. Bueno, el carrito de compras tendrá lógica asociada a él. Por ejemplo, no puedes tener menos uno artículo en tu carrito. Eso simplemente no es posible. Para cada artículo, solo puedes tener una cantidad positiva. Cuando abres este sitio web, el carrito debería estar inicialmente vacío. Si la cantidad de artículos cambia a cero, podría querer eliminar el artículo del carrito. Toda esta lógica se puede implementar sin la UI. Esto es pura lógica de negocio. Cuando la lógica podría ser exactamente la misma en una aplicación de una sola página, renderizado del lado del servidor, en un backend de express, en una aplicación React Native, entonces no debería estar en un componente o un hook. Debería ser extraída. Así que, además, al extraerla, puedes nombrar todo este comportamiento, y puedes incluso facilitar las pruebas automatizadas. ¿Cómo se vería como código en un componente? Podrías crear una simple clase de JavaScript que represente tu carrito con todos estos métodos que representan cómo puedes manipular el carrito. En este ejemplo, puedes actualizar la cantidad de artículos, puedes eliminar un artículo, puedes contar la cantidad total de artículos, e incluso tenemos un método para crear un carrito vacío. Luego, en tu componente, bueno, tendrás toda la lógica de UI, la lógica de estado de la aplicación.

Así que, podríamos crear un estado local, un estado para un carrito donde el carrito esté inicialmente vacío. Usamos el método. En el renderizado, si queremos que se muestre la cantidad total de artículos, tenemos un método para eso. O, incluso, si queremos actualizar la cantidad de artículos, usamos nuestro carrito, y simplemente llamamos al método actualizar cantidad de artículos. Al hacer eso, simplemente creamos una gran separación de preocupaciones entre UI y lógica de negocio. La arquitectura de componentes, de esta manera, es mucho más sencilla de entender, porque se centran en lo que se supone que deben hacer, renderizar UI.

Hacerlo también ayuda a que el código esté más cerca de la forma en que los no programadores hablan contigo sobre la aplicación. Y, al hacerlo, crea una mejor memoria a largo plazo, porque no necesitas convertir lo que alguien está diciendo a cómo está hecho el código. Está más cerca de la realidad. Están más cerca el uno del otro.

Así que, te he dado cuatro trucos para ayudarte a ser más eficiente al desarrollar una aplicación React, para que puedas crear mejores memorias a largo plazo que podrían ayudarte a navegar el código más rápido. Pero, si recuerdas, al principio de la charla, dije algo sobre lo difícil que la arquitectura de aplicaciones puede ayudar a tus futuros compañeros de equipo a ponerse al día rápidamente. Porque, al final, tal como dijo Martin Fowler, cualquier tonto puede escribir código que una computadora pueda entender. Los grandes programadores escriben código que los humanos pueden entender. Gracias. Si estás interesado en lo que hago, lo que digo, y quieres aprender más sobre la práctica que acabo de contar, aquí hay algunos enlaces sobre un artículo en el blog que escribí. Gracias de nuevo.