Pixels, Promesas y Pánico: Historias de Pesadillas en Producción

Bienvenidos a la última charla del día. Como Daniel me presentó, mi nombre es Nechu Dan. Normalmente me presento como Dan Nechu, pero fue un error porque en Twitter, se duplicó la N, así que decidí que no se veía bien, así que lo cambié.

Estoy aquí para hablarles sobre cómo cometer errores y salir impunes. Ese es el título de mi charla. Por lo general, en producción tenemos problemas, interrupciones, tiempo de inactividad, fallas del servicio, detenciones técnicas y colapsos del sistema. Todos estos son problemas graves que afectan a millones de desarrolladores en todas partes. Y, en el origen de todo esto, ¿cuál es la causa principal de estos terribles problemas que impiden a los desarrolladores dormir por la noche? Bueno, en realidad son los bugs.

Estos pequeños bribones feroces pasan por alto todas nuestras pruebas y aseguramiento de calidad manual, llegan a producción y causan estragos en nuestros usuarios, provocando pérdida de ingresos, frustrando a los usuarios todos los días. O estos son bugs, pero a los desarrolladores les gusta llamarlos pequeños errores. Pero ¿quién aquí sabe cómo se llaman realmente los bugs? Un par de personas. Supongo que se llaman bugs porque son asquerosos y aterradores, así que ¿por qué no llamarlos arañas o serpientes? Son aterradoras, mortales y más peligrosas que los bugs, o algo realmente, realmente aterrador como payasos.

La razón es que en 1947, en la Universidad de Harvard, un equipo de científicos de la computación vio que su gran computadora no funcionaba correctamente. Después de trastear un poco con el software y no encontrar nada, abrieron la computadora y lo que vieron dentro fue un bug que estaba pegado a la placa base. Esto también se hizo popular por la historia de la Dra. Grace Hopper, una de las inventoras de COBOL. Personalmente, no encuentro a los bugs aterradores porque suelo llamarlos bugs bunny. La razón de esto es, piénsenlo, bugs bunny nunca se rindió. Siempre burlaba a Elmer Fudd y encontraba la manera de conseguir lo que quería. Cambiaba repetidamente la temporada de caza de patos a la temporada de caza de conejos y engañaba a Elmer Fudd para que se disparara a sí mismo en la cara. Es lo mismo con los bugs. No importa cuánto intentes, cuántas personas involucres, cuántas pruebas automatizadas escribas, generalmente encuentran la manera de ser astutos y hacernos a nosotros, los desarrolladores, dispararnos en la cara. Así que bugs bunny es inevitable. Por eso es nuestro trabajo como ingenieros asegurarnos de que no engorde demasiado y rompa en nuestro servicio de producción y se coma todas nuestras zanahorias. Así que por eso estoy aquí hoy. Quiero hablarles sobre todas las veces que bugs bunny me engañó para que me disparara en la cara. Tengo cuatro o cinco historias dependiendo del tiempo. Cada una de estas soluciones tenía una solución obvia a posteriori, pero pensar en ello e implementar algunas de estas prácticas podría ayudarles a no cometer los mismos errores que yo cometí.

Sobre mí, he sido ingeniero de front-end durante 12 años. Nací en Rumania, pero vivo en la hermosa y soleada Barcelona. Me gusta escribir artículos técnicos y he trabajado en los tres grandes frameworks.

Mi primera historia es cuando me uní a la empresa como un novato total en programación, sabía muchas cosas como estructuras de datos, programación dinámica, cómo invertir una lista enlazada y todo tipo de cosas que eran absolutamente inútiles cuando comencé mi primer trabajo. En cuanto al desarrollo web, solo sabía cómo posicionar cosas con position absolute por todos lados, pero la empresa en la que trabajaba tenía muchos proyectos y muy pocos desarrolladores, así que inmediatamente me quedé atrapado construyendo y construyendo, construyendo muchos proyectos, y ensuciándome las manos.

Por lo general, esta empresa era una empresa de externalización y nos gustaba hacer juegos de navegador. Así que allí estábamos construyendo esta fantástica experiencia de juego, un juego de señalar y hacer clic que ayudaba a los niños a aprender sobre los beneficios de la leche. El juego en sí era muy sencillo, incluso para niños de siete u ocho años. Tenías tres pequeños juegos y aparecía un carrito de leche, y si el niño veía la leche, tenía que hacer clic en ella y obtenía puntos. Si hacía clic en varias leches seguidas, obtenía el doble de puntos y podía crear una racha. Estos eran tres mini juegos y afuera teníamos una tabla de clasificación que mostraba los mejores 20 puntajes que los niños podían obtener. Y todos intentaban construirlo.

Ahora, una mecánica complicada de estos juegos es que, a medida que te movías, mantenía el mismo puntaje, y si pausabas, podías reiniciarlo en otro juego. Lo que no tenía en cuenta era lo motivados que estarían los niños de siete años por estar en la cima de la tabla de clasificación, especialmente considerando que no había premios, esto era solo un juego divertido y era un juego antes de que supiéramos sobre la gamificación, como los hábitos de duolingo y todas las cosas sofisticadas que conocemos ahora. En ese entonces, agregamos la tabla de clasificación solo por diversión. Probamos el juego durante meses, pero una semana después de su lanzamiento, volvimos al trabajo y nos sorprendimos al ver la tabla de clasificación así. Los puntajes estaban en miles de millones.

Inmediatamente pensamos, está bien, es una persona que creó 20 cuentas y hizo trampa. Encontró una forma de enviar los resultados con Postman o algo así, el puntaje y actualizar los valores en nuestra database. Así que asumimos lo peor y lo discutimos con nuestro cliente y prohibimos a las 20 personas en la tabla de clasificación, o como consideramos a una sola persona. Todo estaba bien durante un par de días, la calma antes de la tormenta, y luego nos bombardearon con correos electrónicos y llamadas de clientes, de las noticias, porque todos nos culpaban por hacer llorar a 20 niños de la misma clase, porque cuando los prohibimos, obviamente toda la escuela vio que ya no estaban en la tabla de clasificación, y luego comenzaron a llamarlos tramposos, y luego comenzaron a llorar y se lo contaron a sus padres, y lo único más aterrador en este mundo que una madre enfadada con un niño llorando es en realidad 20 madres enfadadas con niños llorando.

Así que se unieron, llamaron a la empresa, llamaron a las noticias y fueron tras nosotros, y llevó algún tiempo para que la tormenta, digamos, nos alcanzara, a la pequeña empresa que construyó el juego. Cuando lo hizo, descubrimos lo que había sucedido. Un niño de 7 años descubrió que si pausaba el juego mientras tenía la racha en marcha y luego lo reiniciaba y pausaba y reiniciaba, su puntaje se duplicaría. Y lo primero que hizo, por supuesto, fue convertirse en el primero de la tabla de clasificación, luego fue a sus amigos y se jactó de ello, y luego sus amigos comenzaron a hacer lo mismo y se convirtió en una competencia para ver quién podía obtener el mejor puntaje haciendo este truco que descubrieron. Y en realidad pensamos que eran hackers, pero en realidad solo estaban aprovechando el sistema. Y, por supuesto, una vez que encontré el bug, arreglarlo fue solo una línea de code, un if mal colocado que verificaba el puntaje local con el puntaje de la database. Así que una línea de code hizo llorar a 20 niños. Ese code estaba escrito en PHP. Así que podemos decir que PHP hace llorar incluso a los niños pequeños, no solo a los adultos. Al final lo arreglamos, nos disculpamos, restauramos las cuentas de los 20 mejores niños, pero les dimos puntajes adecuados y dejamos que la competencia amistosa continuara. ¿Qué aprendí de todo esto? En primer lugar, debes probar y estresar todo. Podríamos haberlo evitado fácilmente si tuviéramos un sistema de alerta que nos avisara si un puntaje era un valor atípico por encima de la mediana.

Y también no tomes decisiones precipitadas con las cuentas de tus usuarios. Explica y educa y sé más amable en general, especialmente con los niños.

Ahora la siguiente parte en realidad me da pesadillas hasta el día de hoy. Es una historia que es muy popular en la actualidad, pero me enorgullezco del hecho de que no tengo notificaciones push en mi teléfono, solo para cosas importantes como pager duty, algunos canales de Slack y alertas. Una mañana me desperté con una notificación push de mi banco que me decía que alguien acababa de intentar extraer $50,000 de mi cuenta bancaria, y pensaron que era fraude, y lo bloquearon . Estaba súper feliz, bloqueé la tarjeta solo para asegurarme de que no lo intentaran de nuevo, volví a dormir.

Mientras dormía, pensé, wow, qué buen banco, realmente me ayudaron esta vez. Pero mi segundo pensamiento fue, ¿qué hacker es lo suficientemente estúpido como para intentar $50,000 en el primer intento? ¿Por qué no intentar con $500? ¿Por qué no intentar con $800? Intentar obtener poco a poco. Y luego me di cuenta de que lo único que podría hacer que intentaran $50,000 si es una facturación legítima. Y luego salté de la cama, agarré mi teléfono y verifiqué el nombre del proveedor, y por supuesto que era Google. Así que no podía ser un falso como un príncipe nigeriano, o como mis amigos de la infancia de Rumania tratando de estafarme.

Ahora obviamente estaba horrorizado, mi mente ya estaba pensando en soluciones. Porque esto era bastante popular ahora, como tienes historias de que la cuenta de Netlify recibió una factura de $100,000, o la aplicación Kara que hace portafolios para diseñadores recibió una factura de $100,000 por tres días. Y por supuesto, hace siete años hubo una historia muy relacionada con Firebase donde alguien recibió una factura de un millón de dólares porque no cambiaron su estrategia de lectura. Pero yo no sabía todo esto, así que estaba contemplando soluciones. Así que tuve que ver qué recursos tenía en Google Cloud y moverlos, luego tuve que detener el proyecto que me estaba sangrando dinero porque no sabía dónde estaba, y finalmente, y lo más importante, tuve que mudarme al bosque y vivir una vida como un pastor, como el Bigfoot.

Mientras buscaba en todos mis proyectos y me golpeaba la cabeza, no podía encontrar de dónde venía la factura. Así que revisé nuevamente los correos electrónicos, comencé a llamar a la empresa en la que trabajaba, y ellos me informaron que alguien creó un proyecto de BigQuery y en lugar de poner la cuenta de facturación de la empresa, pusieron la mía. Así que la factura de $50,000 era una factura legítima para la empresa y se tardó alrededor de dos semanas en asegurarse de que la cuenta correcta fuera facturada, y para mí, esto fue como el mayor alivio en mi vida. Así que juro que nunca sentí un peso levantarse de mis hombros en ese momento. Pasé de tener una deuda de 50K a ser un hombre libre.

Entonces, ¿qué aprendí? Ten límites y monitorea el tráfico. Nunca tengas eventos o llamadas que se activen al cargar la página. Esto me sucedió nuevamente. Recibí otra factura de 10K debido a Mixpanel porque tenía un use effect para rastrear la página en cada página a la que vas, y un usuario quedó atrapado en un bucle. De todos modos, otra historia para otro momento.

Ahora, las cosas realmente aterradoras ya pasaron. Hablemos de algunas cosas menos importantes, como CSS. Normalmente con CSS, no crees que puedan causar muchos problemas, pero en realidad, wow. Entonces, si eres un diseñador o un desarrollador front-end, es posible que hayas escuchado esta expresión, como, haz que resalte, haz que sea atractivo, haz que esa página se vea bien, y en realidad, tendemos a complicar las cosas mientras que la simplicidad básica hace el truco.

Esto realmente me sucedió cuando estaba construyendo un botón, la idea era hacer que la página fuera más dinámica. Entonces, cuando algo se está cargando, necesitamos mostrarlo en el botón, así que agregamos un estado de carga cuando la página estaba obteniendo algunos data, para que el usuario supiera que estábamos haciendo algo por él. Por supuesto, también teníamos este botón en el formulario de compra, así que cuando teníamos esto y el usuario cambiaba los métodos de pago, verificábamos si el método de pago era válido, y aparecía el botón de carga, pero como el proceso de compra se construyó en un framework diferente al framework que estábamos usando, teníamos React en nuestra aplicación principal y el proceso de compra se construyó en Angular 1, un antiguo sistema heredado. La reactividad en el botón era diferente y aplicaba la carga, pero nunca la quitaba después de que fuera válida. Entonces, los usuarios cambiaban el método de pago y veían la carga, pero nunca desaparecía. El botón funcionaba, pero veían la carga y simplemente no hacían clic en él. El problema con esto fue, por supuesto, que solo se tomaban pequeñas cantidades de dinero de los ingresos, porque algunas personas hacían clic en él y continuaban, y otras personas nunca cambiaron el método de pago, por lo que fue un porcentaje muy, muy bajo que nos costó alrededor de 20,000 al día, y no fue hasta que llegamos al final del mes y comparamos nuestros pedidos mensuales con los del mes anterior, y pensamos, bueno, algo está mal, ¿qué está pasando? Luego revisamos los eventos y vimos que las personas agregaban cosas al carrito pero nunca completaban la compra. ¿Qué está mal? Nos llevó tres o cuatro días descubrir que teníamos un problema con el botón CSS. Entonces, ¿qué aprendí de esto? Lo simple siempre es mejor. Hay una razón por la cual Amazon tiene el mismo proceso de compra desde 1990. Ahora puedes usar pruebas visuales que toman capturas de tu implementación de componentes y verificarlo con tu canal de integración y entrega continua (CI/CD) para asegurarte de que lo que estás enviando a producción sea bueno o no. De esta manera, tienes un método para declarar cada vez que envías un code a producción, se compara con lo que había antes, la imagen que había antes, y se compara el resultado. Si hay cambios, te pregunta, ¿está bien? ¿Quieres esto en producción? Sí o no? Y una parte realmente importante es monitorear los eventos de finalización del proceso de compra y recibir alertas si algo está fuera de lo común.

Oh, sí. Esto. Simple es mejor. Utiliza pruebas visuales y monitorea los eventos de finalización del proceso de compra.

Ahora, llegamos a una sección, mi última historia, donde todo se trata del refactoring. Cada vez que hacemos refactoring, el 60 por ciento de las veces, funciona cada vez. Así que este debería ser como un lema general para los ingenieros de software en todas partes. Bromas aparte, hay un par de lugares donde nunca querría hacer refactoring, como el proceso de compra o la autenticación. Así que dejaré estas historias para otra ocasión. Puedes encontrarme en la sección de preguntas y respuestas. Podemos discutir algunas historias realmente interesantes.

Mi última historia, se trata de los hackers. Mi última empresa, muy grande, en 26 países, 13 idiomas, así que debido a que era una empresa tan grande y conocida, era atacada por hackers todos los días. Por lo general, intentaban obtener códigos promocionales o crear cuentas falsas, intentaban desestabilizar la aplicación o cualquier otro niño que intentara hackearla y hacer que cosas divertidas sucedieran. Así que teníamos un buen servicio de firewall y también teníamos un equipo de guardia que, si algo salía mal, recibíamos la notificación en nuestros teléfonos. Teníamos que ir a la computadora portátil, reunirnos y discutir qué estaba mal. Esto sucedió mientras estábamos almorzando un día. Las alarmas comenzaron a sonar en la habitación. Todos miraron sus teléfonos. Vale, algunos hackers están intentando desestabilizar la aplicación. Está bien. El Amazon WAF se encargará de ello. Silenciamos la alarma, volvimos a nuestra comida y luego volvió a sonar, esta vez más fuerte y más fuerte, así que corrimos hacia nuestras computadoras portátiles y el sitio web estaba completamente caído. Así que nos reunimos. Teníamos ingenieros de personal, ingenieros principales, infraestructura, seguridad, 30 o 40 ingenieros allí tratando de descubrir cómo estos hackers podían evadir todas nuestras medidas de seguridad , evadir el firewall, evadir todo y desestabilizar la aplicación. Y luego, nos llevó alrededor de 30 o 40 minutos, pero descubrimos que el culpable era en realidad nosotros. Nos lo hicimos a nosotros mismos. Lo que sucedió es que teníamos muchas rutas antiguas que redirigían a los bots desde rutas heredadas a las nuevas rutas, y pusimos algo en producción que cambió un parámetro que hacía que todos los usuarios pasaran por este proceso de redirección que estábamos haciendo para los bots. Y cuando un usuario iba a la página, en realidad era redirigido a través de siete páginas. Y debido a que todas estas redirecciones eran del lado del servidor, también aumentaba el número de llamadas a la API que estábamos realizando.

Así que comenzamos a hacer 100 llamadas más a la aplicación de lo normal, y el firewall realmente vio esto y pensó, hmm, este servicio está haciendo demasiadas llamadas a la aplicación, y luego nos bloqueó. Así que al menos el firewall estaba funcionando correctamente. Esto también pasó nuestra prueba de extremo a extremo porque teníamos, como, la prueba de extremo a extremo verificaba que pasaste de la página A a la página B. Nunca verificamos el flujo completo en una sola prueba. Por supuesto, pasamos de la página A a la página B, pero también fuimos a C, D, A y F y tres veces a G antes de llegar a la página B. La prueba pasó y el code se fue a producción. En siete, en realidad ocho minutos, la aplicación se cayó durante la hora del almuerzo. Sí, básicamente esto. Creamos una recursión que creó demasiadas solicitudes. Entonces, ¿qué aprendí? No ataques tu propia aplicación, eso es realmente, realmente malo. Trata de no usar el patrón de modelo de objeto de página para tus pruebas de extremo a extremo si tienes una lógica de redirección compleja oculta en middlewares, y siempre sé rápido al responder a las alertas. Ahí lo tienes. Cuatro historias de fracaso que sucedieron en mi career. Tuvimos cómo hacer llorar a los niños y salir impunes, cómo evitar una factura de 50K, cómo estilizar tus botones de CSS y cómo hacer que tu aplicación se caiga con solicitudes adicionales. Pero en serio, aprendí muchas cosas geniales que me hicieron un mejor desarrollador, como empatizar con tus usuarios y no tomar decisiones precipitadas, la importancia de tener alertas en su lugar para cosas que son excepcionales, y cada fracaso debe ser analizado críticamente, y es muy bueno escribir un análisis posterior al incidente después de que un problema haga que tu sitio web se caiga, porque aquí puedes escribir un documento en el que analices la causa raíz, escribas cómo podemos prevenir esto en el futuro y cómo podemos mitigarlo para asegurarnos de que esto nunca vuelva a suceder, y luego compartes este documento con toda tu organización, para crear conciencia y compartir conocimientos. Finalmente, esto pasará. Puedes pensar que es el fin del mundo y que hiciste algo realmente, realmente malo, pero aprendemos a no ser enemigos mortales de Bugs Bunny y realmente apreciarlo por hacer que nuestra aplicación sea más fuerte y mejor con cada túnel que construye. Así que gracias. APLAUSOS.

Bien, entonces, ¿quién debería ser responsable de escribir los análisis posteriores al incidente? Bueno, obviamente, la persona que creó el problema en primer lugar. Si fueron dos o tres personas del equipo, o si fueron varios equipos los que crearon un problema, generalmente se asigna una persona dedicada de cada equipo. Sí, y ellos lo analizan y escriben el documento. Por lo general, también requieren revisiones de otras personas que estuvieron involucradas, como security, infraestructura, y demás.

Bien, y acabas de terminar esa parte, y la siguiente pregunta se relaciona directamente con eso, porque un problema que la gente tiene con los análisis posteriores al incidente es que los escribimos, pero no todos los leen. Entonces, ¿cómo pasamos de esta etapa, donde está escrito, por favor lean mi análisis posterior al incidente? Quiero decir, una cosa que hicimos es tener un grupo de correo electrónico, como ingeniería, y enviamos ese análisis posterior al incidente a todos en ingeniería, y tenían que leerlo. Era opcional, por supuesto, pero creamos una cultura de hacer preguntas y participar en el documento, y utilizamos Google Docs, por lo que era fácil y muy intuitivo para que todos lo lean y colaboren en el documento, básicamente. Bien, sí, eso tiene mucho sentido. Veamos dónde estamos. Oh, alguien está preguntando acerca del segundo punto en la diapositiva anterior, ¿qué patrón puedo usar en lugar del modelo de objeto de página? ¿Cómo lo manejaron ustedes? ¡En realidad no lo cambiamos! Pero es muy bueno tener un proyecto separado que no verifique a nivel de CI/CD, sino que verifique la producción después de cada implementación. Así que tienes, como, escribes, pero esto no puede funcionar para cada historia de usuario o todo lo que tienes. Tiene que ser específico para tu negocio. Entonces, si tienes un sitio web de comercio electrónico, básicamente es agregar un producto a tu carrito, ir al pago y poder ingresar el dinero, y que diga pedido completado. Así que la prueba de extremo a extremo más simple, pero se ejecuta en producción después de cada implementación, para asegurarte de que al menos el flujo principal funcione el 100 por ciento del tiempo. Tiene sentido. Definitivamente. Déjame ver esto. Oh, alguien está diciendo, hay una pregunta, pero al final de la pregunta, dicen, ¡buen peinado! Pero la pregunta, vamos a ello. Entonces, lo que están preguntando es cuáles dirías que son los errores más comunes que cometen los ingenieros junior o de nivel de entrada en las aplicaciones? Bueno, creo que para no ser considerado un ingeniero junior, debes al menos borrar la base de datos de producción una vez en tu vida. Tienes que hacer eso, de lo contrario no eres parte de la pandilla. Pero los errores más comunes que veo son, quiero decir, ahora es más difícil debido a TypeScript, cometer errores. TypeScript realmente te ayuda a mantener todo en línea. Los errores más comunes que cometí fue no verificar si mi code funciona. Básicamente, confiar en mis pruebas, confiar en mi, o no verificar fuera de la funcionalidad que estoy construyendo. Estoy construyendo una funcionalidad, verifico que si presiono este botón, funciona, perfecto, pero luego se implementa en producción y rompe algo más en la otra parte de la aplicación. Así que no entrar y verificar y al menos asegurarme de que no estoy rompiendo otras cosas, ese es uno de los errores más grandes que cometen los desarrolladores junior.

De acuerdo, veamos en qué punto estamos con las preguntas. Todavía nos quedan cuatro minutos. Sigan adelante, todos. Sé que esta es la última, pero todavía nos quedan cuatro minutos.

Mientras esperamos que aparezcan más preguntas, porque todavía nos quedan cuatro minutos y no hay nada aquí en este momento, les voy a preguntar, ¿podrían aclarar un poco uno de los puntos que dejaron de lado? Porque mencionaron que, bueno, obviamente tendremos la sesión de preguntas y respuestas después, pero ¿pueden adelantar cuál sería el otro punto que dejaron de lado? En realidad, trabajamos en mi empresa anterior en una migración de authentication. Estábamos pasando de un servicio a otro. Y todo iba muy bien, lo probamos, fue un proyecto de seis meses, y luego, cuando lo lanzamos, tuvimos que migrar las contraseñas de los usuarios porque estaban utilizando un método de criptología diferente. Así que cuando hicimos esto, no sé qué salió mal en el backend o en el frontend, pero los usuarios en realidad veían las cuentas de otros usuarios cuando ingresaban a la aplicación. Y se convirtió en un espectáculo lamentable, la gente canceló sus cuentas y tuvimos que disculparnos. Fue un gran problema.

Cuando mencionaste criptología, alguien empezó a reírse. No sé si fue porque estaban relacionados con ese problema o si fue por la pregunta que acaba de aparecer. Preguntaron si había algún error notable y divertido que recordaran debido a algunas malas elecciones de design. Hmm. Bueno, hay algunas cosas en las que los diseñadores no piensan, como la complejidad. Hacen algo que creen que es muy fácil de implementar, y como lo implementamos, tampoco pensamos en las implicaciones. Por ejemplo, teníamos algunas migas de pan. Y ellos design las migas de pan de tal manera que cuando haces clic en el segundo nivel, aparece un modelo y puedes moverte por la aplicación de diferentes formas. Y tenía sentido de alguna manera. Y lo implementamos, pero debido a esto, teníamos, digamos, una página de perfil de alguien, como una aplicación de redes sociales. Y porque ahora puedes moverte, antes no podías, pero con estas migas de pan, podías moverte de una página de perfil a otra página de perfil, los defectos de uso nuevamente no tenían una comprobación para la ID de perfil. Así que las personas se movían de perfil en perfil y veían algunos data del antiguo perfil, y luego se asustaban de nuevo. Así que, sí. Obviamente fue un error del desarrollador, pero se produjo en producción debido a una idea del diseñador, digamos. Wow. Todavía estoy tratando de procesar eso. Verifiquemos nuevamente en qué punto estamos con las preguntas. De acuerdo. Solo cargando. ¿Alguien está preguntando en el ínterin si podrías compartir algunos tips para desarrolladores junior? Bueno, creo que tener y trabajar en un sistema de diseño es una práctica muy buena, y tener componentes realmente simples que se reutilicen en todas partes de la aplicación es muy fácil y asegúrate de no cometer tantos errores porque no estás reinventando la rueda. Así que diría que sí, para los desarrolladores junior, tener un sistema de diseño y una biblioteca de componentes realmente podría ayudarles. Y también escribir pruebas. Comienza a escribir pruebas. Es realmente, realmente útil. Oh, sí. Estoy completamente de acuerdo con eso. La cantidad de veces, si no hubiera tenido pruebas, creo que todos estamos de acuerdo con eso. No vamos al grano. Creo que no tenemos más preguntas en este momento.