Olvida el mal código, concéntrate en el sistema

Esperamos que disfrutes el resto de la charla. Gracias, y nos vemos la próxima vez. Adiós.

Así que voy a intentar convencerte hoy de que te estás centrando en lo incorrecto. Hablas demasiado sobre el código bueno o malo, y en lo que realmente deberías estar enfocado es en cómo configuras todo tu sistema, tu architecture.

Ahora, ¿alguien ha visto esta diapositiva de la Conferencia de NextJS que se hizo bastante popular en Twitter? Esto es una acción de servidor, y lo que está pasando es que tienes un componente de React con SQL justo ahí en el componente de React, lo cual es un poco extraño. Y más temprano hoy, David de Redwood también anunció que ahora pueden hacer lo mismo, donde tienes cosas de SQL mezcladas con cosas de JSX. Ahora, ¿cómo te hace sentir esto cuando lo ves? ¿Cómo te sientes? ¿Alguien se siente enfadado? Sí, de acuerdo. ¿Alguien se siente molesto, como algo raro, como si esto fuera algo malo y extraño que hacer? De acuerdo. Ahora, ¿qué pasaría si te dijera que así es exactamente como nos sentimos acerca de JSX hace 10 años. React se lanzó, inventaron JSX, y todos los barbones en internet estaban como, oh Dios mío, ¿estás mezclando HTML y JavaScript? ¿Qué demonios te pasa? ¿Por qué harías eso? Es la separación de preocupaciones, todo eso. Y luego llegó CSS, CSS en JS y el internet se volvió loco de nuevo. ¿Por qué estás mezclando todo esto? Y ¿qué pasaría si te dijera que todo el punto de todo esto es, de hecho, la separación de preocupaciones.

Ahora, se siente, ya sabes, digo separación de preocupaciones, y podrías estar pensando, espera, pero estás mezclando todas las preocupaciones. Tienes el estilo mezclado con la lógica de la database, tienes la búsqueda mezclada con todo lo ‑‑ ¿puedo ver mis notas? De acuerdo. Así que estás mezclando todo. Eso no parece una separación de preocupaciones. Pero hay una forma diferente de pensar en la separación de preocupaciones. ¿Y si separaras tus preocupaciones por dominio empresarial, no por la tecnología que estás utilizando? La palabra negocio está haciendo mucho trabajo aquí. Nos gusta ‑‑ no sé, ¿quién aquí ha trabajado con arquitectos sofisticados y personas que tienen títulos que suenan muy altos como ingeniero principal y cosas así? Solo da un grito. Vale. Algunos de ustedes. Vale. ¿Quién aquí ha escuchado hablar de modelado de dominio o negocio esto, negocio aquello, ese tipo de cosas? De acuerdo. Perfecto. Así que esto es mucho trabajo y ‑‑ oh, maldita sea, me falta ‑‑ se suponía que había otra diapositiva allí. Vale. Así que la palabra dominio de negocio está haciendo mucho trabajo allí. Lo que quiero decir con eso es un buen ejemplo de eso es Lego. Así que estos son dos sets de Lego.

Ambos resultan ser mis primeros grandes sets de Lego. A la derecha tienes cómo solían ser los grandes sets de Lego en los 90. Aquí está el super coche de Lego. Viene en una caja realmente grande. Me encantó. Como niño esto era como oh, Dios mío, obtienes 1.300 piezas y lo primero que haces, lo abres y clasificas cada pequeña pieza en su propia cajita. Toma un tiempo. Y luego finalmente puedes empezar a construir tu Lego y puedes encontrar todas las piezas. Si necesitas un engranaje, está en la caja de engranajes. Si necesitas una rueda, está en la caja de ruedas.

Ahora, más tarde, cuando me di cuenta de que, hey, ahora soy un adulto, puedo simplemente comprar Lego cuando quiera. Lo sé, como una idea loca. Compré el Saturno 5, que fue mi segundo set de Lego. Ese tiene 1.969 piezas, que creo que está cuidadosamente calibrado para coincidir con cuando Apollo 1 aterrizó en la luna y todo eso, porque subió en el Saturno 5. Ese no venía con una caja en la que clasificar los Legos. Venía en un montón de bolsitas. Construyes el cohete Saturno 5 yendo etapa por etapa. Para aquellos de ustedes que no lo saben, los cohetes son multi-etapa. Se lanza. La primera etapa quema su combustible. Suelta la primera etapa, y el resto del cohete sigue adelante. Así es como construyes el Saturno 5. En cada bolsita, obtienes exactamente las piezas para una etapa del cohete. Lo construyes desde el suelo, y todas las piezas están mezcladas. Tienes piezas que son del revestimiento exterior. Tienes piezas que van para la estructura interna y todo eso. Todo está revuelto. Lo realmente genial es que es mucho más fácil y mucho más divertido de construir que el super coche porque nunca tienes que buscar entre más de 200 o 300 piezas, lo cual es mucho más fácil de hacer. Puedes esparcirlas sobre una mesa y dices, oh sí, esa, esa, esa, y simplemente la construyes y disfrutas del proceso de construcción en lugar de pasar mucho tiempo buscando el Lego correcto. Ahora sé que algunas personas dicen que esa es la parte divertida.

Personalmente, odio esa parte. Y este concepto de separar por preocupaciones de negocio va más allá de los simples LEGOs. Esto es, hay una nueva, en realidad no, no estoy en la construcción. No sé cuánto tiempo ha estado esta tendencia, pero tienen esta cosa llamada construcción modular donde prefabrican piezas enteras de un edificio y luego simplemente las izan y las apilan una encima de la otra como LEGOs y obtienes un edificio. Es mucho más barato, es mucho más rápido, y lo que me sorprende, si ves en la parte inferior ahí, eso es un baño prefabricado. Obtienes un baño completo con toda la fontanería, con todos los eléctricos, con los azulejos dentro, con la bañera, con el lavabo. Todo está ahí y simplemente lo colocas en tu casa y conectas, supongo, una tubería de alcantarillado un enchufe eléctrico, y una fuente de agua y obtienes un baño completo. La idea es que es rápido. Tienen cocinas prefabricadas, etc, etc.

Obtienes unidades contenidas y cumplen una función. Otro más cercano a casa, si alguno de ustedes ha estado por aquí durante un tiempo, esta es una famosa diapositiva de, creo, 2017 de Cristiano Rostelli, no sé si lo pronuncié bien, donde habla de cómo la antigua separación de preocupaciones era JS, CSS, HTML por capas. La nueva separación de preocupaciones es botón, modal, lista, etc., y tienes un componente que es autónomo y cumple la función y sabe todo lo que necesita hacer.

Entonces, la razón por la que la gente hace esto o la razón por la que la gente está emocionada con esta modularidad es la complejidad arquitectónica. Ahora, la complejidad arquitectónica suena como un término súper sofisticado pero te prometo que es bastante fácil de entender. La idea es que si usas unidades autónomas que no son solo mezclas de bits que tienes que construir artesanalmente cada vez que estás construyendo algo, vas a tener un tiempo más fácil lidiando con tu base de código, bloqueando características, etc.

Hubo, estas son estadísticas de un estudio de 2013, fue en realidad una tesis de doctorado de Daniel Sturtenrand. Hizo este estudio en el MIT en 2013, se publicó en 2013, no sé cuánto tiempo estuvo trabajando en él, pero estaban mirando un software de la industria que es utilizado por personas reales, desarrollado en la industria, por lo que no es como un proyecto de un estudiante de posgrado, no es un proyecto de código abierto, es un código real que genera dinero. No revelaron quién o qué era la empresa, así que no lo sé. Rastrearon el software a través de ocho lanzamientos importantes, por lo que es un estudio de larga duración. Duró un par de años, y lo que encontraron es que alto... Bueno, tengo que tener cuidado de dónde pongo mi cabeza. La alta complejidad arquitectónica conduce a una caída del 50% en la productividad, un aumento de tres veces en la densidad de defectos, eso son errores, y un aumento de 10 veces en la rotación de personal.

Ese último es un poco dudoso si me preguntas, porque es como... Resulta que las personas que trabajan en un código más arquitectónicamente complejo también son más experimentadas, personas que siempre tienen más probabilidades de irse porque ya han estado en la empresa durante más años, y tienen más oportunidades en otros lugares. A veces la gente simplemente se aburre. No quieres trabajar en lo mismo durante diez años. Pero la caída del 50% en la productividad y el aumento de tres veces en la densidad de defectos fue muy sólido La forma en que estudiaron esto fue... Compararon a las personas que trabajan principalmente en... En realidad, no. Todos eran un autocontrol. Así que simplemente miraron a las personas, y miraron cuánto tiempo mientras trabajaban en una característica pasaste en archivos con alta complejidad arquitectónica y cuánto tiempo pasaste en archivos con baja complejidad arquitectónica. Y explicaré cómo medir eso en un momento. Y vieron que cuanto más tiempo pasaste trabajando en archivos más complejos, menos productivo eras, y más probable era que cometieras un error. Lo que en el habla de la gente normal significa que si trabajas en un código que es difícil de entender, vas a cometer más errores y te va a llevar más tiempo. Lo cual a veces es como... ¿Por qué estos investigadores intentan investigar cosas tan obvias? Así que mi última obsesión ha sido encontrar investigaciones reales que confirmen mis prejuicios y cosas que he notado en la realidad. Porque entonces puedo decir, esto no es solo una corazonada, hay investigación. Lo cual funciona muy bien en los debates en línea. Pero sigamos adelante.

Entonces, ¿cómo mides la complejidad arquitectónica? Bueno, primero tienes que empezar a pensar en tu código como un gráfico de dependencias. Digamos que esto es un montón de código. Cada una de estas formas representa un elemento o una cosa en tu código. Puede ser una función, una clase, un archivo, una constante, lo que sea. Solo elementos de tu código que tienen diferente complejidad, diferentes tamaños. Y la mayoría de ellos son de tamaño promedio.

Si observas cómo estos elementos de tu código se llaman entre sí, puedes trazar líneas entre ellos. Así que esto es un gráfico de dependencias. Los imports son un buen ejemplo de un gráfico de dependencias. Pero también cuando llamas a una función, dependes de esa función para hacer lo correcto para lo que estás intentando construir.

Entonces, en este ejemplo, ves que las líneas, no hay muchas de ellas. ¿Qué? ¿Cinco, seis líneas? Cinco líneas. Y ya parece un desastre. Eso es porque las líneas están cruzando la base de código. Así que tengo el triángulo a la izquierda yendo todo el camino hasta el triángulo a la derecha para hacer una llamada a función o lo que sea que esté haciendo. Y eso aumenta tu complejidad arquitectónica. Va a ser realmente difícil entender cómo funciona este código cuando solo miras un archivo, porque todo está revuelto. Y traté de hacerlo con más líneas, pero entonces realmente no tiene sentido.

¿Y si tomaras los elementos que están realmente relacionados, que se llaman entre sí, y los agrupas juntos? Y luego puedes volver a trazar las líneas, y ves que tienes un par de áreas que tienen muchas conexiones internas y que están muy poco conectadas al exterior. Puedes llamar a eso un módulo. Entonces, si miras, así es como puedes identificar modules naturales en el código que ya tienes. Así que aquí aumenté el número de conexiones. Y puedes ver que en azul están circulados los modules que tienen conexiones internas fuertes, un acoplamiento interno fuerte, pero están poco conectados al exterior.

Y lo genial de esto es que puedes empezar a pensar en esos modules como un componente de nivel superior, como un elemento de nivel superior. Y una de las cosas que Sturtevant o Sturtevant encontró en su estudio es que los ingenieros más experimentados ya piensan en el código de esta manera. Ni siquiera leen los elementos individuales. Solo ven, oh, esto es un bucle for recorriendo esta cosa, y realmente no leen el cuerpo, solo entienden el componente de nivel superior o el elemento de código de nivel superior que hace la cosa. Y olvidé lo que iba a hacer. Pero el punto es, tienes modules, y puedes identificarlos mirando tu gráfico de dependencias. Entonces, ¿de qué diablos estoy hablando, verdad? Como que solo estoy divagando aquí.

Entonces, piensa en un motor de coche. Este es un motor W16 de, creo que el Bugatti Chiron. Esta cosa es increíble porque produce un montón de caballos de fuerza. Tiene 3,500 partes. Y si miras esa imagen, no tienes idea de lo que está pasando. Al menos yo no. Todo está revuelto. Está estrechamente acoplado en un espacio muy, muy pequeño. Tienen muchas cosas que tienen que empaquetar en un pequeño espacio. Pero si lo miras desde un nivel superior, te das cuenta de que la API para un motor de coche es en realidad bastante simple. El aire y el combustible entran por un lado, y los gases de escape y el par motor salen por el otro lado. Entonces, si piensas en un motor como un módulo en tu código, puedes simplemente colocarlo, insertarlo, conectar los puntos de la API porque están claramente definidos, y obtienes un objeto funcional que puede ayudarte a lograr una tarea.

Ahora, lo sé, esto es una exageración, una exageración, olvidé la palabra. Pero de todos modos, han encontrado estas estructuras en grandes proyectos de código también. Entonces, esto es de un estudio de 2008 por McCormack, Rasnack, y Baldwin quienes estudian la complejidad arquitectónica y cómo la gente real organiza el software y qué conduce a mejores resultados en el software design, blah, blah, blah. Pero esto es una red, se llama DSM, que significa Diagrama de algo, pero básicamente la forma en que lees esto, cada eje representa archivos y el punto entre, así cada eje de la matriz, cada lado de la matriz es un archivo, cada punto dentro de la matriz representa una dependencia entre esos dos archivos. La razón por la que obtienes esa línea diagonal en el medio es que cada archivo depende de sí mismo o también llaman a esto matriz de visibilidad, donde la idea es qué archivos pueden ver en otros archivos o en otras funciones.

Ahora esto es cuando Mozilla algún tiempo antes de este estudio hizo un refactor y puedes ver que antes del refactor, el código era muy interdependiente, había mucha complejidad arquitectónica y luego cuando los ingenieros entraron y limpiaron el código, ves muchas menos dependencias porque estaban enfocándose en la complejidad arquitectónica, no en el mal código real dentro de cada módulo porque resulta que eso es más importante. Y también puedes ver esto en ejemplos más pequeños, en códigos más pequeños. Este es en realidad un gráfico de dependencia que saqué de nuestra base de código la semana pasada, donde nosotros construimos una nueva característica y la forma en que nos gusta construir cosas es simplemente lanzar cosas a la pared y luego Swiss entra y lo limpia y hace que todo esté bonito y organizado. Y en la parte superior, puedes ver, código muy confuso, hay un círculo de dependencia en el medio que está marcado por los círculos rojos y como todo está un poco enredado. Y luego, y también puedes ver que tenemos carpetas de componentes y carpetas de hooks y como un componente hijo muy pequeño va tres niveles arriba a un componente padre para llegar a un archivo padre para obtener un hook, etc. Y luego después, simplemente organizo las cosas por dominio empresarial. Obtienes carpetas bien nombradas que te dicen, oye, sabes, resumen de construcción, dentro de él está un índice y otros componentes y tiene un hook y es algo independiente. Puedes tomar esa carpeta y dondequiera que la coloques en tu base de código, va a funcionar porque puede cuidar de sí misma. Entonces, mira, el punto de lo que estoy tratando de decirte es que debes contener tu mal código, ponerlo en una pequeña caja y luego darle a la caja una interfaz bonita para que otras personas puedan usar tu mal código sin preocuparse de cómo el código en sí mismo realmente funciona y sin tener que leerlo. Esto también se llama una abstracción. Y lo principal que debes asegurarte cuando estás construyendo abstracciones es asegurarte de que no se filtran. Si recuerdas las diapositivas que te mostré desde el principio, esa es mi tesis por qué los componentes de servidor de React y las acciones de servidor aún no están del todo ahí es que la abstracción es un poco filtrada pero realmente me gusta la dirección en la que estamos yendo con eso donde podrías tener componentes autocontenidos que hacen todo en un solo archivo.

Y rápido, la forma más fácil de notar la complejidad arquitectónica es si usas una herramienta que dibuja un gráfico de dependencias, puedes ver que está todo enredado. Si tienes importaciones de puntos, puntos, puntos, barra, eso simplemente grita complejidad arquitectónica. Si tienes dependencias circulares, algo ha salido muy mal. Y generalmente si no puedes decir dónde funciona el código junto y cuál es una interfaz pública eso también es una mala señal. La mayoría de las veces he visto que eso sucede cuando las personas exportan cosas para que puedan tener pruebas unitarias y cosas así. Tengo una diapositiva más. Entonces la forma de solucionarlo es organizar las cosas por dominio empresarial, ponerlo en una carpeta, asegurarte de que cualquier cosa que esté estrechamente acoplada vive junta. Y luego un gran consejo que tengo es limpiar y validar tus entradas en los límites de un módulo. Y luego simplemente perfora las propiedades del data hacia abajo, y eso realmente funciona muy bien. Y sabes, si alguna vez tienes dudas entre copiar y pegar algún código que parece similar y separar las preocupaciones, siempre opta por separar las preocupaciones. Incluso si parece similar pero habla de un concepto diferente, es un código diferente y te prometo que juntarlo y hacerlo, optar por el principio DRY te disparará en el pie más tarde. Y eso es lo que tenía que decir sobre la complejidad arquitectónica. Si usas ese código QR, puedes ir, tengo un boletín de noticias, cosas así, algunas lecturas adicionales para cualquier nerd que quiera leer algunos documentos.

Y eso es todo, gracias. Ahí vamos.

Bueno, eso fue divertido. Voy a decir algo que nunca se ha dicho en la historia de las conferencias de React. Organiza tu flamenco. Déjalo, quiero hablar holandés. Mantenlo bajo control. No quiero ser golpeado en la cara por un flamenco aquí. Mal flamenco. La seguridad primero.

Coolio McSwag pregunta, entonces mencionaste en tu presentación, así es como se sintió JSX hace años. ¿Estás llamando a la audiencia boomers? Me estoy llamando a mí mismo un boomer. Mi primera reacción a React fue, ¿por qué harías esto? Y luego lo intenté y fue como, esto es increíble. También recuerdo mi primera exposición a React. Ya había aceptado el trabajo y no sabía que estaban usando React y yo estaba como, no. Y después de unos días jugando con él, nunca miré atrás. Honestamente, espero que algún día tengamos navegadores con soporte nativo JSX. Algún día. Bueno, acabamos de escuchar de Ken que puedes construir tu propio navegador con Canvas. Uh-huh. Entonces, ¿por qué no haces el tuyo? Sí. Lo intentaré. ¿Qué estás haciendo este fin de semana?

Muy bien. Próxima pregunta de Noah. ¿Por qué el flamenco? Sí, gran pregunta. ¿Por qué el flamenco? Sabes, los flamencos son realmente geniales y si no lo sabías, en realidad no son rosados. Obtienen eso de comer camarones. Uh-huh. Entonces, no comas muchos camarones, supongo que es la lección. A menos que quieras ser rosa.

A menos que quieras ser rosa, sí. Sí. Ella es realmente exitosa. Vende en estadios, así que el rosa es algo bueno. Swag McCoolio.

Otra pregunta. ¿Utilizas alguna herramienta en particular para analizar la complejidad arquitectónica de una característica de React? Entonces, he intentado encontrar tooling para esto. No hay nada realmente bueno por ahí. Lo mejor que he hecho es una herramienta llamada madge que puede visualizar tus importaciones y dependencias de esa manera. Estoy tratando de encontrar algo que pueda hacerlo a nivel de llamadas de funciones, porque eso sería realmente útil. No he encontrado nada. Pero, una vía de investigación interesante, puedes preguntar al chat, puedes dar un volcado JSON de tu gráfico de dependencias, chat-gpt, y preguntarle cuáles son los modules aquí, cuáles son las áreas en las que debería organizar mi código, y él te lo dirá. De hecho, es capaz de encontrar eso. Entonces, una cosa que espero hacer este fin de semana es hacer un complemento de VS Code o algo así, donde podría ser como, hey, mi código parece una porquería, ¿puedes organizarlo?, y hacer que se organice por sí mismo. Creo que eso sería realmente genial. Aún no estamos allí. Sí, probablemente puedes usar una sintaxis abstracta apt-ast. Sí. ¿Qué significa de nuevo? Árbol de sintaxis abstracta. Árbol de sintaxis abstracta. Sí. Para hacer eso. Lo cual es muy divertido. Y Steven de AG grid, que habló antes hoy, sabe mucho sobre eso. Entonces, podemos trabajar juntos con él. Con él, en nuestro navegador de dependencias Canvas AST React. Perfecto. Tenemos el equipo de ensueño. Sí. Todo el conocimiento está aquí.

Muy bien. Una pregunta de Anónimo. ¿Qué opinas sobre el diseño atómico? Diseño atómico. Entonces, me gusta el diseño atómico, si mi entendimiento es correcto, tienes átomos, luego tienes moléculas, y luego tienes organismos, ¿o algo así? Algo así, sí. Entonces, los átomos son como los bloques de construcción. Yo los pondría en una biblioteca o algo así, pero luego las moléculas y los organismos son básicamente de lo que estoy hablando aquí, donde tienes un componente de orden superior, o un componente de nivel superior que puedes usar cuando estás construyendo características, porque no siempre quieres estar ensamblando artesanalmente cada átomo. Vale, eso tiene sentido. Sí.

Muy bien, la siguiente pregunta es de Anónimo, también, dos preguntas de Anónimo. ¿Algún consejo para herramientas para mostrar gráficos de dependencias en aplicaciones React o Next? Sí, yo iría con algo como Madge, o creo que TreeSitter también puede hacer eso. Aún no lo he probado. Pero una cosa que me gusta de Next, especialmente si usas su nuevo paradigma de aplicación slash, es que realmente te promueven a hacer páginas autónomas que lo hacen todo. Así que eso es un poco lo que estaba hablando aquí, donde una vez que tienes una página que sabe cómo cargarse a sí misma, y sabe cómo cargar sus datos, sabe cómo organizarse a sí misma, puedes mover muy fácilmente esa página a cualquier lugar, hacerla una subpágina o lo que sea, porque es autónoma.

Muy bien, entonces tenemos tiempo para una pregunta realmente, realmente rápida. Esa no es una pregunta rápida, pero vamos a hacerla de todos modos. ¿Cómo recomendarías organizar un monorepo grande con alta complejidad arquitectónica? Tienes seis segundos. Buscaría los módulos naturales que ya existen porque están ahí, y luego, espero que estés usando TypeScript, simplemente empieza a mover el código, y el TypeScript, especialmente en VSCode, simplemente toma un archivo, muévelo a una nueva carpeta, corrige todas tus importaciones, y he encontrado que eso generalmente funciona. Consigue un ingeniero, dale una tarde o una semana, y déjale reorganizar tus archivos, y probablemente estará bien. Lo difícil con eso en mi experiencia sería como, si miro el código base del espejo tenemos como 900 ingenieros trabajando a tiempo completo en él, y si vamos a mover cosas, va a ser un infierno, ¿verdad? Porque hay como 200 PRs al día, incluso más, y si vas a reorganizar cosas, eso es realmente doloroso. Así que mientras es posible, como dijiste, tienes que tener un equipo para gestionar también. ¿Algún consejo sobre eso? Empezaría pequeño, lo haría con cosas pequeñas, y luego, una cosa feliz, un accidente feliz que encontré es que un archivo movido y los cambios en ese archivo no causan un conflicto de fusión. Git es lo suficientemente inteligente para averiguarlo y mover tus cambios, así que mientras las personas no estén también reorganizando archivos al mismo tiempo que tú los estás reorganizando, debería estar bien. Entonces deberías estar bien. Lo que también está bien es que nuestro tiempo se ha acabado. Así que todos, si quieren continuar la conversación con Svizzak, pueden unirse a él en la sala de Q&A.