1. Introducción al Proceso de Revisión de Código
Estoy aquí hoy para compartir lo que he aprendido de investigar las bibliotecas de JavaScript más utilizadas en GitHub. Vamos a entender las mejores prácticas para la revisión de código. El proceso de revisión de código implica crear código, abrir una solicitud de extracción y tener compañeros de equipo que revisen y proporcionen perspectivas. Los desarrolladores revisan el código basándose en estándares, legibilidad y si funciona correctamente. Las ideas para la revisión de código provienen de la experiencia y pueden ser empíricas. Las pruebas de software utilizan el estándar ISO 25010.
Entonces, estoy muy... Es un placer estar aquí hoy con ustedes. Gracias a toda la organización que hace esto posible y, definitivamente, es un honor estar aquí hoy. Esta es mi primera vez hablando aquí en Europa, así que, es otro recuerdo, momento en mi vida y mi carrera. Y espero que ustedes también puedan disfrutar de esta charla. Así que, ya me presentaron, así que voy a ahorrarles de escuchar esto de nuevo. La idea aquí en esta charla es compartir con ustedes lo que he aprendido después de hacer una investigación sobre las diez bibliotecas de JavaScript más utilizadas en GitHub. Y trato de estructurar esto de una manera que podamos entender un poco más sobre las mejores prácticas que estos chicos han estado utilizando al revisar el código. Y ese es el enfoque. La idea hoy no es hablar de las características que tienen las bibliotecas, sino aprender más sobre cómo están revisando el código que se envía a estos repositorios. Así que, vamos a avanzar y pensar un poco más sobre el proceso de revisión de código, ¿verdad? El proceso de revisión de código es básicamente una forma sencilla para las personas que están codificando todos los días, ¿verdad? Es algo que es bastante sencillo, pero para las personas que están en el lado de las pruebas, a veces no saben exactamente cómo funciona. Así que, primero, tenemos el código que se crea. Entonces, el desarrollador va allí y crea un fragmento de código, o incluso los probadores, dependiendo de cómo ustedes están estructurando la forma en que producen su código de automatización de pruebas, ¿verdad? Pero esta es la primera parte para crear un código. Luego la persona que creó este código abre un PR. Y después de abrir un PR, básicamente tenemos a nuestros compañeros de equipo yendo allí y revisando esto y proporcionándonos algunas perspectivas, las visiones que tienen. Y luego de eso, podemos, si tenemos la aprobación, podemos seguir adelante y fusionar el código. Si no, necesitamos trabajar en esta solicitud de extracción, o en este fragmento de código que estamos produciendo, ¿verdad? Lo cierto es que hay una actividad muy, cómo decirlo, muy importante que ocurre durante este proceso que es básicamente tener a estos compañeros de equipo mirando el código y revisándolo. La pregunta es, ¿cómo lo hacen los desarrolladores? Y la respuesta es magia, ¿verdad? En realidad, déjenme preguntarles a ustedes que son desarrolladores. Díganme, ¿qué tienen en mente cuando están revisando un código? Es tu turno. Sí, estamos haciendo estándares, ¿verdad? ¿Qué más? Esa es una muy buena pregunta. Esa es una muy buena respuesta también. Legibilidad. ¿Qué más? Sí, si el código hace lo que debería hacer, ¿verdad? Sin embargo, ¿de dónde vienen estas ideas? Sí, de la experiencia, ¿verdad? La forma en que lo haces. No estoy diciendo que todos lo hagan de esta manera, ¿verdad? Pero a veces lo hacemos de una manera empírica, ¿verdad? Basado en nuestra experiencia. Entonces, nos hace ser, cómo dicen, empíricos, ¿verdad? Así que, si todos aquí levantaran la mano y compartieran un pensamiento sobre cómo revisar, seríamos la persona más sabia en toda esta conferencia, ¿verdad? Hay otra forma de hacerlo. En las pruebas de software, utilizamos un estándar llamado ISO 25010. ¿Han oído hablar de él? ¿Sí? Levanten la mano. Okay,
2. Calidad del Software y Revisión de Código
Existen ocho características de calidad del software, incluyendo la idoneidad funcional y la mantenibilidad. La mantenibilidad se centra en hacer el código legible, testeable y mejor. En un estudio de investigación, el 75% de los comentarios en las solicitudes de extracción estaban relacionados con la mantenibilidad. Para entender cómo los repositorios de pruebas de software manejan las revisiones de código, analicé las solicitudes de extracción cerradas. Te animo a que pruebes este método de investigación en tu empresa para obtener información sobre la calidad.
bien. Hagan un saludo. Tenemos pulgares arriba. Bien. Entonces, básicamente hay ocho características de calidad del software. Si el software funciona como se espera, se clasifica como idoneidad funcional. Si el código es legible, se llama ¿dónde está? Bien, mantenibilidad. ¿De acuerdo? Hay grupos de cosas. Y lo que sucede es que cada vez que le pregunto a un desarrollador qué piensa que debería hacer durante la revisión, lo que escuché más comúnmente, más frecuentemente es relacionado con la mantenibilidad. ¿De acuerdo? Se trata de hacer el código legible. Se trata de hacer el código testeable. Se trata de hacer el código mejor. Eso es todo acerca de la mantenibilidad. Hice una rápida investigación en uno de los equipos con los que estaba trabajando. Y revisé 52 solicitudes de extracción y más de 300 comentarios en las solicitudes de extracción. ¿Qué aprendí? El 75% de los comentarios estaban relacionados con la mantenibilidad.
¿De acuerdo? La cuestión es, cómo los repositorios de software de testing más utilizados, las bibliotecas de software de testing, cómo dicen, hacen cuando las personas que contribuyen a este proyecto están revisando las solicitudes de extracción. Esta es la pregunta que tenía. Y entonces empecé a encontrar las respuestas. Y lo que hice fue básicamente ir uno por uno a estos repositorios y luego filtrar sólo las solicitudes de extracción cerradas. ¿De acuerdo? Porque ya están, cómo dicen, establecidas. Todo lo que debería tomar como una decisión ya se hizo. ¿Correcto? Eso es lo que hice. Y les recomiendo que recuerden esta diapositiva. Porque realmente me gustaría que ustedes intentaran hacer esto en sus empresas. Al menos para un repositorio. Y les prometo, aprenderán mucho sobre cómo ustedes entienden la calidad en ese repositorio específico. ¿De acuerdo? Así que, intenten reproducir este método de investigación. Así que, el segundo fue abrir la solicitud de extracción que tiene comentarios. ¿De acuerdo? Porque a veces tenemos solicitudes de extracción que son simplemente aprobadas. Mágicamente. ¿De acuerdo? Simplemente son aprobadas. Y luego ignorar las solicitudes de extracción que sólo tienen interacciones de bots o las
3. Monólogos de Pull Request e Insights de Repositorios
A veces los autores abren solicitudes de pull y tienen monólogos internos antes de encontrar una forma más legible. Ignora esto y busca perspectivas de otros. Lee los comentarios y clasifícalos según la ISO 25010. Al analizar diez solicitudes de pull, encontré algunos repositorios interesantes: Jest, Storybook, Mocha, Cypress, Puppeteer, Selenium, Jasmine, Vitest y WebDriver.io.
propio autor. Porque también sucede. Es algo que, como dicen, es muy divertido. Y solo descubrí eso después de hacer esta investigación. A veces el autor va allí y abre la solicitud de pull y comienza a hablar consigo mismo. ¿Sabes? Como, oh, lo hice porque encontré esto muy interesante. Y luego, dos minutos después, dice: oh, encontré una forma más legible de hacerlo. Es como un monólogo. ¿Verdad? Es muy interesante. Entonces, necesitas ignorar esto. Porque luego quieres tener la perspectiva de otros. ¿Verdad? Esa es la magia alrededor de la solicitud de pull. Y luego el cuarto es leer los comentarios e intentar clasificar este comentario contra la ISO 25010. Solo para entender cómo ustedes están entendiendo la calidad relacionada con la solicitud de pull. Esto es lo que hice con estas diez solicitudes de pull. Y lo que descubrí en los diez proyectos que creo que fui muy rápido aquí. Solo volviendo para darles a ustedes la oportunidad de entender cuáles eran los repositorios. Entonces, Jest,
Storybook, Mocha,
Cypress, Puppeteer, Selenium, Jasmine, Vitest, te prometo, vine a decir Vitest. Y luego estaba como, está bien. La charla anterior dijo que no es Vitest. Es Vitest. Está bien. Aprendido. Y WebDriver.io. ¿Hay alguno de estos repositorios que es muy nuevo para ti? Levanta la mano. ¿Cuál? WebDriver. Oh, Dios. ¿Es real o es una broma? ¿No? Es real. Entonces, WebDriver es uno de los precursores para la prueba web de
automation. La prueba web de
frontend automation. Por eso estoy
4. Mantenibilidad y Directrices en la Revisión de Código
WebDriver, Cypress y Playwright son las bibliotecas de JavaScript más utilizadas. La mantenibilidad es crucial en la revisión de código. Establezca directrices adaptadas a su equipo, no solo a los estándares de la industria. Utilice bots para comprobar la calidad del código, incluyendo el tamaño del archivo, las pruebas y los committers.
convirtiendo esto en una broma. Básicamente, cuando empecé, WebDriver era el
Cypress que tenemos hoy, o Playwright, ya sabes. Bien. Y luego si ustedes quieren saber más acerca de cómo fueron elegidos como los diez más utilizados, pueden visitar 22.stateofjs.com. Y luego tienen más información sobre ellos. Bien. Así que, estas son las características de calidad de software más utilizadas de la ISO 25010, basadas en el análisis que hice en este repositorio. Hablemos de mantenibilidad. Que básicamente es la capacidad que tenemos para evolucionar o mantener el código. ¿De acuerdo? Eso es, de nuevo, lo que más utilizan los desarrolladores cuando están revisando código. Así que, encontré muchas lecciones aprendidas sobre mantenibilidad revisando esta solicitud de pull en este repositorio. Sin embargo, estas son las tres que decidí traerles que me parecieron muy interesantes, muy importantes para tener en sus proyectos también. ¿De acuerdo? Así que, primero es establecer directrices. Lo que encontré en estos repositorios fue que cada vez las personas estaban peleando para que se aplicaran las directrices. Y es importante recordar que las directrices no son solo las
best practices generales, ¿verdad? Por ejemplo, si ves ahora que tienes una persona en tu equipo que está intentando modificar, por ejemplo, una secuencia de código y cambiar y reemplazar esto por un mapa futuro y cosas así. Tal vez no se aplica al código que ustedes están haciendo en su equipo. Así que, establezcan sus directrices, no solo lo que el mercado está impulsando. Esto es lo que aprendí sobre mantenibilidad en estos repositorios. Ellos realmente insisten en seguir sus directrices. Y algunos de los repositorios también tienen una página de directrices donde puedes aprender más al respecto. ¿De acuerdo? Así que, necesitas pensar ahora cómo hacemos esto en nuestra empresa. Porque tal vez estas directrices solo están en tu cerebro y luego estás rechazando muchas solicitudes de pull de tus amigos porque no están obedeciendo tus directrices. Así que, haz compartidas las directrices y también será muy útil para ti. Así que, segundo, utiliza bots y linkers para comprobar tu código. Chicos, necesito deciros esto. Nunca vi tantos bots como vi durante esta investigación. Ya sabes, es mucho. Son bots para verificar el tamaño de los archivos, el tamaño de la producción de una biblioteca que será entregada. Es un bot para verificar si hay pruebas flake.
5. Consejos para la Revisión de Código y Adecuación Funcional
Por lo tanto, utilice estos bots para ayudar con las solicitudes de pull. Es importante compartir conocimientos y ayudar a los nuevos miembros del equipo. La adecuación funcional es una característica clave de la calidad del software. Escriba pruebas valiosas e involucre a los QA para una mejor cobertura. Verifique la lógica para evitar errores de implementación.
Es un bot para verificar si el committer es John. Porque no nos gusta John. Así que, vamos a rechazar todas las solicitudes de pull que vengan de John. Eso es una broma. No es cierto. Pero entendiste mi punto, ¿verdad? Así que, utiliza estos bots, chicos. Están ahí y pueden ayudaros a hacer esto de una manera muy útil, ¿vale? Ten un equipo profundamente técnico. Bueno, vi muchos comentarios donde los chicos decían, oye, no uses este método porque este método hará dos solicitudes, dos renders de esta pantalla, ¿sabes? O no uses este método porque hará tres solicitudes a este endpoint que no quieres hacer. Y yo estaba como, oh, Dios, si yo fuera un desarrollador aquí, ¿cómo entendería esto para obtener este conocimiento profundo sobre ello, ¿sabes? Y tal vez como desarrollador junior, no sabría de ello. Entonces, ¿cómo podemos como equipo ayudar a las personas que están llegando a nuestro equipo a ser mejores en ello, ¿sabes? Tal vez tienes al chico senior compartiendo este tipo de conocimientos con los demás o dedicando algo de tiempo para estudiar. No lo sé. Pero esto es algo que encontré muy útil y ayudó mucho en esto.
Segundo, la adecuación funcional. Esta fue la segunda característica de calidad del software que se utilizó más en este repositorio. Así que, traje estos tres elementos aquí para discutir con ustedes. Primero, escriba pruebas valiosas. Valioso en este caso significa prueba que realmente tiene sentido para esa pieza de código que escribiste. Porque a veces estamos simplemente tratando de hacer cobertura, para aumentar la cobertura, y no es suficiente, ¿verdad? Muchas veces vi a gente diciendo, oye, olvidaste cubrir este caso ad o ese caso ad. Así que, es importante no ir y simplemente hacer el camino feliz, sino también pensar en estos otros escenarios, ¿verdad? Y aquí está mi consejo para ti. Si tienes un QA a tu alrededor, ¿vale? ¿Hay QAs aquí, verdad? Oh, bien, bien. Así que, toma a estos chicos. Acércalos a ti y di, oye, amigo, ¿ves otras cosas que necesito probar aquí? ¿Ves? O también, pídeles que te enseñen técnicas de design de pruebas. Las técnicas de design de pruebas son como algoritmos sobre cómo leer una pieza de código fuente y definir qué probar. Eso es increíble, ¿vale? Así que, técnicas de design de pruebas. Segundo, verifica la lógica. Porque si no compruebas la lógica, tal vez estás implementando esto de la manera equivocada. Encontré muchos comentarios diciendo, oye, implementaste esta lógica de la manera equivocada. Y a veces también vi comentarios diciendo, oye, implementaste esto de la manera correcta. Sin embargo, lo implementaste en el archivo equivocado.
6. Desafíos de la Revisión de Código y Rendimiento
En los proyectos de código abierto, muchas personas envían solicitudes de pull, causando varios problemas. Ejecutar pruebas es crucial para evitar solicitudes de pull rotas. Las mejoras de rendimiento incluyen el uso de caché, la mejora de la carga y la eliminación de solicitudes innecesarias. Los comentarios de seguridad se relacionan con bibliotecas con vulnerabilidades. La usabilidad, fiabilidad, compatibilidad y portabilidad a menudo se pasan por alto en las revisiones de código.
Sí. No es una broma. Es cierto. Realmente vi esto suceder. Pero en un proyecto de código abierto puede suceder mucho. Porque, ¿sabes? Así que, recuerdo que estaba hablando con un amigo y él dijo, oh, envié un PR a ese proyecto especial y aprobaron mi PR. Sí, mírame. ¿Quieres tomar una foto de mí? Cosas así. ¿Sabes? Así que, sí. Hay muchas personas tratando de enviar cosas y luego causan muchos otros problemas, ¿verdad? Así que, tercero, ejecuta las pruebas. Y de nuevo, puede sonar cliché, pero necesitas ejecutar las pruebas que ya tienes. A veces vi solicitudes de pull siendo rechazadas porque las pruebas estaban rotas. ¿Cómo abriste una solicitud de pull sin ejecutar la prueba? ¿Sabes a qué me refiero? También es muy importante.
Performance. Lo primero que se menciona con más frecuencia por los desarrolladores es, tal vez puedes usar caché aquí. Porque estás solicitando este archivo muchas veces y no están cambiando tanto. Así que, puedes usar esto y definitivamente ayudará al performance. Así que, segundo, mejora la carga. Está más relacionado con paquetes que realmente son, cómo decir, proporcionando una herramienta detrás del código, ¿verdad? Quiero decir, como Cypress, por ejemplo. Tienes la interfaz de usuario gráfica. Y si hay una posibilidad de mejorar la velocidad de renderizado, tal vez puedes invertir tu tiempo allí también. Vi algunos comentarios relacionados con esto. Y el último aquí en performance es eliminar lo innecesario. A veces estamos solicitando cosas muchas veces y solo necesitamos hacer esto una vez. Así que, esto es algo que es realmente común, muy frecuente en los comentarios que vi también. Vale. Y luego security. No pude encontrar algunos, cómo decir, algunos comentarios más de security, pero los que encontré estaban relacionados con eso. Básicamente, bibliotecas que tienen algunas vulnerabilidades y luego el equipo necesita hablar entre sí y ver cómo van a lidiar con eso. Las últimas características de calidad del usuario fueron estas. Usabilidad, fiabilidad, compatibilidad, y portabilidad. Y qué significa esto. Esto significa que a veces nos olvidamos de abordar este tipo de cosas durante las revisiones de código y luego alguien está testing esto para nosotros.
7. Lecciones de la Revisión de Código
Desplace las características de calidad a la izquierda durante las revisiones de código para encontrar más calidad en su proyecto. Investigue sus PRs para crear listas de verificación y anticipar errores, ahorrando tiempo y esfuerzo. Tenga una estrategia de prueba compartida en todo el equipo para distribuir pruebas y ahorrar tiempo y esfuerzo.
Si tuvieras el equipo de QA y el equipo de QA tiene suficiente tiempo para ir allí y probarlo, sería muy bueno. Pero si no lo están, ¿quién probará esto por ti? Es tu cliente, ¿verdad? Entonces, ese es el punto aquí. Algunas conclusiones para ustedes. La primera, desplaza las características de calidad a la izquierda, ¿vale? Probablemente ustedes hayan oído mucho sobre desplazar a la izquierda testing, ¿verdad? Pero desplaza las características de calidad del software a la izquierda. ¿Y cómo haces eso? Empiezas a, como dicen, a propósito, durante tus revisiones de código, pregúntate sobre estas ocho características de calidad del software. Vale. Y si tienes preguntas, habla con tu QA. Si no tienes un QA, busca en Google y encuentra información sobre cómo hacerlo. Pero si eres capaz de hacerlo, de desplazar esto a la izquierda, serás capaz de encontrar más calidad en tu proyecto.
Segundo, investiga tus PRs. Es básicamente para realizar esta investigación en tu empresa. Aprende más sobre cómo piensan tus desarrolladores y luego intenta crear algunas listas de verificación al respecto. Porque entonces si tienes esta lista de verificación, serás capaz de anticipar estos errores. Cada vez que enviamos el PR, hay muchas personas trabajando en él, el tiempo corre, ¿verdad? Entonces, si eres capaz de enviar el APR que es más, como dicen, apropiado, ahorrarás mucho tiempo y mucho esfuerzo. Vale. Y el tercero es tener una estrategia de prueba compartida en todo el equipo. Entonces, si los QAs crearon una estrategia de prueba, están cubriendo muchas pruebas. A veces tenemos, por ejemplo, una estrategia de prueba que tiene 50 pruebas. Pero los QAs, a veces no tienen este conocimiento técnico profundo para entender que el 25% de esas 50 pruebas se pueden hacer en la capa unitaria. Y están haciendo eso en la capa de UI, perdiendo mucho tiempo. Saben que están perdiendo mucho tiempo. Si hablan juntos, pueden distribuir estas pruebas. Y entonces ustedes serán capaces de ahorrar mucho tiempo y mucho esfuerzo. ¿Vale? Entonces, déjame volver solo un segundo. Casi allí. Vale. Ahora es el momento de decir muito obrigado. Eso significa muchas gracias, chicos. Fue un placer estar aquí hoy. Y
Automatización de la Revisión de Código y Equilibrio de Hotfix
El uso de análisis de código estático y pruebas automatizadas antes de solicitar revisiones de código es importante y valioso. Automatizar este proceso a través de CI ahorra tiempo y asegura el máximo valor. Al equilibrar los hotfixes con la calidad del software, un análisis basado en riesgos puede ayudar a determinar qué procesos se pueden omitir sin comprometer la entrega. Fomentar que los mantenedores sigan los ocho principios de calidad del código requiere un estudio adicional.
Espero que hayan disfrutado de mi charla. Gracias. Hemos tenido, honestamente, más preguntas de las que tendremos tiempo para responder. Pero tengo algunas para ti. En primer lugar, ¿qué piensas sobre el uso de análisis de código estático y pruebas automatizadas y luego sólo pedir una revisión de código una vez que pasen? Sí. Creo que esto es definitivamente algo que es importante y valioso. Lo recomiendo mucho. Y esto es algo que vi en los comentarios también. Pero lo que sucede es que si eres capaz de poner este análisis de código estático en el
CI, entonces es más fácil y ahorrará tiempo a tu equipo, ¿verdad? Cada vez que delegas algo a un ser humano para que lo haga manualmente, quiero decir, ir allí y ejecutar manualmente el análisis estático, puede ser omitido, olvidado. Y ustedes no van a extraer el máximo valor de ello. Absolutamente. Creo que mucha
automation se trata de ser más eficaz con el tiempo y la experiencia que tienes como individuo en un equipo.
Otra pregunta es, y esta tiene un montón de votos positivos, supongo, likes. ¿Cómo recomiendas o cómo has visto a los equipos seguir las directrices para los hotfixes, donde realmente tienen que ir en vivo lo más rápido posible y luego tienes que equilibrar todas estas ocho cualidades versus simplemente arreglar cualquiera que sea el problema? Sí, esto es difícil. Lo que recomiendo, chicos, es que cada vez que tienes un... No voy a hablar sólo de hotfixes. Voy a hablar de todo lo que tienes cuando estás codificando, ¿verdad? Intenta usar el análisis basado en riesgos. Eso es básicamente decir, hey, ¿cuáles son los riesgos que tenemos de no entregar esto ahora o de entregar esto tal como está? Porque si haces este análisis de riesgos, serás capaz de decir, hey, ¿podemos saltarnos ese proceso específico ahora para la entrega? ¿Es esto suficientemente bueno para entregar ahora o necesitaremos literalmente esperar un poco más antes de entregar? ¿Sabes a qué me refiero? Así que este análisis basado en riesgos es algo que me ha estado ayudando y a los proyectos en los que trabajo también. De esta manera, podemos seleccionar cuál de esas ocho características de calidad del software son las mejores para la entrega que necesitamos hacer en este hotfix o lo que sea. Excelente. Gracias. Y eso tiene sentido. Oh, hay tantas. Están llegando más rápido de lo que podemos responder. Esto es genial, aunque, y un gran momento para recordarte que cada orador al final de nuestro Q&A se dirigirá al cuestionario del orador cerca de la entrada. Así que tendremos más tiempo para responder preguntas entonces. Así que, oh, tantas para elegir. Así que tu estudio mira lo que la gente actualmente hace en las revisiones de código para mantener estos ocho principios de code quality. ¿Has mirado lo que sería lo correcto para los mantenedores para fomentar esas ocho propiedades? Así que creo que no entendí... Así que echaste un vistazo a los 10 proyectos principales y miraste lo que la gente hacía. ¿Tienes, o tienes algún pensamiento en torno a lo que la gente hizo y lo que la gente podría hacer
Reflexiones sobre la Revisión de Código y Documentación
Para aplicar eficazmente las revisiones de código, es importante considerar las habilidades de las personas involucradas, no sólo el código en sí. Realiza investigaciones en tu propia empresa para identificar áreas de mejora en seguridad, rendimiento y fiabilidad. Si se descuidan estos aspectos, puede llevar a problemas cuando el código ya está en producción. Al documentar las directrices de codificación, aprende de proyectos con muchos colaboradores y bibliotecas populares. Esto proporcionará valiosas plantillas e ideas para apoyar tu trabajo.
¿o deberían hacer para mejorar la calidad son diferentes? Sí, te entiendo. Sí, creo que para tener esta respuesta, necesitaría hablar con las personas en los proyectos, ya sabes, porque no se trata sólo del código, también se trata de las habilidades que estas personas tienen. Por ejemplo, si les pido que levanten la mano ahora, las personas que saben mucho sobre
security, por ejemplo, levanten la mano sólo para tener una mejor noción. Una persona, ¿sabes? Así que si no tenemos este tipo de conocimiento, es difícil aplicarlo en las revisiones de código. Por eso les animo a hacer el mismo experimento, esta investigación en sus empresas. Y si ustedes detectan que no están invirtiendo mucho tiempo en
security, en
performance, en fiabilidad, entonces tienen un camino de qué estudiar en los próximos días para traer esto de vuelta. Porque, de nuevo, si ustedes no lo hacen, alguien lo hará. Y si es su cliente, no será bueno, ¿verdad? Porque ya estará en producción. Ese es el punto. Excelente. Y sé que mi trabajo es mantener esto a tiempo y el tiempo acaba de golpear, voy a apretar una muy rápida. Pero si puedo, ¿tienes alguna recomendación sobre cómo documentar entonces las directrices de codificación para apoyar a los colaboradores? Sí. Lo que haría si necesito escribir una directriz ahora es ir a estos principales proyectos que tienen muchos colaboradores y ver cómo lo están haciendo. Así que definitivamente recomiendo que ustedes echen un vistazo a los tres primeros de la lista porque son los más utilizados, ¿saben? Y entonces verán muchas buenas plantillas y buenas formas de hacerlo. Así que serán capaces de también tener una forma de basar el trabajo que van a hacer. Excelente. Muchas gracias. Una vez más, área de preguntas del orador cerca del frente. Pero, ¿podemos tener un gran aplauso por lo que fue una charla realmente interesante? Gracias.
TestJS Summit 2021
