Es muy común que los equipos tengan procesos de revisión de código y esto suele suceder a través de las solicitudes de extracción. Cada comentario representa un paso hacia la mejora de la calidad del software, sin embargo, existe una amplia variedad de puntos de vista. La antigüedad del equipo, el propio equipo, la empresa, el tiempo restante, la mentalidad, los acuerdos internos, todo esto impacta la forma de revisar el código.
Como probador, necesito entender qué sucede en el código y al revisarlo, para identificar fallas en el proceso de desarrollo y mejorar mi estrategia de prueba.
En esta charla, traeré los resultados de la investigación que realicé analizando los comentarios contenidos en las solicitudes de extracción de los 10 proyectos de Github más populares creados en Javascript y aportaré algunas ideas relacionadas con lo que descubrí. Entre ellos: cuáles son las características de calidad del software que más ejercen los Devs, cuáles son los puntos débiles en su proceso de desarrollo, dónde podemos mejorar nuestras pruebas para anticipar fallas y herramientas que se pueden utilizar para probar de manera más completa, entre otros.
This talk has been presented at TestJS Summit 2023, check out the latest edition of this JavaScript Conference.
FAQ
El propósito principal de la charla es compartir aprendizajes obtenidos tras una investigación sobre las prácticas de revisión de código en las diez bibliotecas de JavaScript más utilizadas en GitHub.
El proceso de revisión de código es una práctica en la cual los compañeros de equipo revisan el código propuesto en un Pull Request (PR) para proporcionar comentarios y perspectivas, lo cual puede llevar a la aprobación y fusión del código o a requerir más trabajo en él.
Las características de calidad del software según la ISO 25010 incluyen idoneidad funcional, mantenibilidad, performance, seguridad, usabilidad, fiabilidad, compatibilidad y portabilidad.
El descubrimiento clave fue que el 75% de los comentarios en las solicitudes de extracción estaban relacionados con la mantenibilidad, enfocándose en la legibilidad y testeabilidad del código.
Se sugiere utilizar bots para realizar comprobaciones automáticas durante la revisión de código, como verificar el tamaño de los archivos o la presencia de pruebas flake, lo que ayuda a mejorar la eficiencia del proceso.
Se recomienda establecer y compartir directrices claras de codificación, utilizar herramientas automatizadas como bots y linkers, y fomentar un conocimiento técnico profundo dentro del equipo.
Se aprendió que es importante escribir pruebas valiosas, verificar la lógica de implementación y asegurarse de que las pruebas existentes se ejecuten correctamente antes de considerar una solicitud de extracción.
Se aconseja realizar un análisis de riesgos para decidir qué características de calidad del software pueden ser comprometidas temporalmente para acelerar un hotfix, asegurando que los riesgos son conocidos y controlados.
La charla discute el proceso de revisión de código y la importancia de la calidad del software. Enfatiza la necesidad de mantenibilidad en el código y el uso de directrices adaptadas al equipo. La charla también destaca la importancia de la idoneidad funcional y los desafíos de la revisión de código. Se recomienda la automatización y la documentación para mejorar las revisiones de código y garantizar la calidad del software.
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
Short description:
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
Short description:
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
Short description:
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
Short description:
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
Short description:
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
Short description:
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
QnA
Automatización de la Revisión de Código y Equilibrio de Hotfix
Short description:
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
Short description:
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.
Cecilia Martinez, a technical account manager at Cypress, discusses network requests in Cypress and demonstrates commands like cydot request and SCI.INTERCEPT. She also explains dynamic matching and aliasing, network stubbing, and the pros and cons of using real server responses versus stubbing. The talk covers logging request responses, testing front-end and backend API, handling list length and DOM traversal, lazy loading, and provides resources for beginners to learn Cypress.
Today's Talk discusses the importance of managing technical debt through refactoring practices, prioritization, and planning. Successful refactoring requires establishing guidelines, maintaining an inventory, and implementing a process. Celebrating success and ensuring resilience are key to building a strong refactoring culture. Visibility, support, and transparent communication are crucial for addressing technical debt effectively. The team's responsibilities, operating style, and availability should be transparent to product managers.
Debugging JavaScript is a crucial skill that is often overlooked in the industry. It is important to understand the problem, reproduce the issue, and identify the root cause. Having a variety of debugging tools and techniques, such as console methods and graphical debuggers, is beneficial. Replay is a time-traveling debugger for JavaScript that allows users to record and inspect bugs. It works with Redux, plain React, and even minified code with the help of source maps.
This Talk discusses building a voice-activated AI assistant using web APIs and JavaScript. It covers using the Web Speech API for speech recognition and the speech synthesis API for text to speech. The speaker demonstrates how to communicate with the Open AI API and handle the response. The Talk also explores enabling speech recognition and addressing the user. The speaker concludes by mentioning the possibility of creating a product out of the project and using Tauri for native desktop-like experiences.
Cypress is a powerful tool for end-to-end testing and API testing. It provides instant feedback on test errors and allows tests to be run inside the browser. Cypress enables testing at both the application and network layers, making it easier to reach different edge cases. With features like AppActions and component testing, Cypress allows for comprehensive testing of individual components and the entire application. Join the workshops to learn more about full circle testing with Cypress.
La Biblioteca de Pruebas de React es un gran marco para las pruebas de componentes de React porque responde muchas preguntas por ti, por lo que no necesitas preocuparte por esas preguntas. Pero eso no significa que las pruebas sean fáciles. Todavía hay muchas preguntas que tienes que resolver por ti mismo: ¿Cuántas pruebas de componentes debes escribir vs pruebas de extremo a extremo o pruebas de unidad de nivel inferior? ¿Cómo puedes probar una cierta línea de código que es difícil de probar? ¿Y qué se supone que debes hacer con esa persistente advertencia de act()? En esta masterclass de tres horas, presentaremos la Biblioteca de Pruebas de React junto con un modelo mental de cómo pensar en el diseño de tus pruebas de componentes. Este modelo mental te ayudará a ver cómo probar cada bit de lógica, si debes o no simular dependencias, y ayudará a mejorar el diseño de tus componentes. Te irás con las herramientas, técnicas y principios que necesitas para implementar pruebas de componentes de bajo costo y alto valor. Tabla de contenidos- Los diferentes tipos de pruebas de aplicaciones de React, y dónde encajan las pruebas de componentes- Un modelo mental para pensar en las entradas y salidas de los componentes que pruebas- Opciones para seleccionar elementos DOM para verificar e interactuar con ellos- El valor de los mocks y por qué no deben evitarse- Los desafíos con la asincronía en las pruebas de RTL y cómo manejarlos Requisitos previos- Familiaridad con la construcción de aplicaciones con React- Experiencia básica escribiendo pruebas automatizadas con Jest u otro marco de pruebas unitarias- No necesitas ninguna experiencia con la Biblioteca de Pruebas de React- Configuración de la máquina: Node LTS, Yarn
La web ha evolucionado. Finalmente, también lo ha hecho el testing. Cypress es una herramienta de testing moderna que responde a las necesidades de testing de las aplicaciones web modernas. Ha ganado mucha popularidad en los últimos años, obteniendo reconocimiento a nivel mundial. Si has estado esperando aprender Cypress, ¡no esperes más! Filip Hric te guiará a través de los primeros pasos sobre cómo empezar a usar Cypress y configurar tu propio proyecto. La buena noticia es que aprender Cypress es increíblemente fácil. Escribirás tu primer test en poco tiempo y luego descubrirás cómo escribir un test de extremo a extremo completo para una aplicación web moderna. Aprenderás conceptos fundamentales como la capacidad de reintentar. Descubre cómo trabajar e interactuar con tu aplicación y aprende cómo combinar pruebas de API y de UI. A lo largo de todo este masterclass, escribiremos código y realizaremos ejercicios prácticos. Saldrás con una experiencia práctica que podrás aplicar a tu propio proyecto.
Construye Aplicaciones Modernas Utilizando GraphQL y Javascript
Featured Workshop
2 authors
Ven y aprende cómo puedes potenciar tus aplicaciones modernas y seguras utilizando GraphQL y Javascript. En este masterclass construiremos una API de GraphQL y demostraremos los beneficios del lenguaje de consulta para APIs y los casos de uso para los que es adecuado. Se requiere conocimiento básico de Javascript.
A diferencia de las pruebas unitarias, las pruebas de extremo a extremo buscan interactuar con su aplicación tal como lo haría un usuario real. Y como todos sabemos, puede ser bastante desafiante. Especialmente cuando hablamos de aplicaciones móviles. Las pruebas dependen de muchas condiciones y se consideran lentas e inestables. Por otro lado, las pruebas de extremo a extremo pueden dar la mayor confianza de que su aplicación está funcionando. Y si se hace correctamente, puede convertirse en una herramienta increíble para aumentar la velocidad del desarrollador. Detox es un marco de pruebas de extremo a extremo en caja gris para aplicaciones móviles. Desarrollado por Wix para resolver el problema de la lentitud e inestabilidad y utilizado por React Native en sí como su herramienta de pruebas E2E. Únete a mí en esta masterclass para aprender cómo hacer que tus pruebas de extremo a extremo móviles con Detox sean excelentes. Prerrequisitos- iOS/Android: MacOS Catalina o más reciente- Solo Android: Linux- Instalar antes de la masterclass
En el panorama siempre en evolución del desarrollo de software, garantizar la fiabilidad y funcionalidad de las API se ha vuelto primordial. "Pruebas de API con Postman" es una masterclass completa diseñada para equipar a los participantes con los conocimientos y habilidades necesarios para sobresalir en las pruebas de API utilizando Postman, una herramienta poderosa ampliamente adoptada por profesionales en el campo. Esta masterclass profundiza en los fundamentos de las pruebas de API, avanza a técnicas de prueba avanzadas y explora la automatización, las pruebas de rendimiento y el soporte multiprotocolo, proporcionando a los asistentes una comprensión holística de las pruebas de API con Postman. Únete a nosotros para esta masterclass para desbloquear todo el potencial de Postman para las pruebas de API, agilizar tus procesos de prueba y mejorar la calidad y fiabilidad de tu software. Ya seas un principiante o un probador experimentado, esta masterclass te equipará con las habilidades necesarias para sobresalir en las pruebas de API con Postman.
Si encontrar errores en tu proyecto frontend es como buscar una aguja en un pajar de código, entonces el monitoreo de errores de Sentry puede ser tu detector de metales. Aprende los conceptos básicos del monitoreo de errores con Sentry. Ya sea que estés ejecutando un proyecto de React, Angular, Vue, o simplemente JavaScript “vainilla”, mira cómo Sentry puede ayudarte a encontrar el quién, qué, cuándo y dónde detrás de los errores en tu proyecto frontend. Nivel de la masterclass: Intermedio
Comments