Lo que aprendí sobre la calidad del software de los 10 proyectos de Javascript más populares en Github

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,

¿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

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.

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.

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

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