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

Rate this content
Bookmark

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.

27 min
07 Dec, 2023

AI Generated Video Summary

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.

1. Introducción al Proceso de Revisión de Código

Short description:

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.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

TestJS Summit 2021TestJS Summit 2021
33 min
Network Requests with Cypress
Whether you're testing your UI or API, Cypress gives you all the tools needed to work with and manage network requests. This intermediate-level task demonstrates how to use the cy.request and cy.intercept commands to execute, spy on, and stub network requests while testing your application in the browser. Learn how the commands work as well as use cases for each, including best practices for testing and mocking your network requests.
TestJS Summit 2021TestJS Summit 2021
38 min
Testing Pyramid Makes Little Sense, What We Can Use Instead
Featured Video
The testing pyramid - the canonical shape of tests that defined what types of tests we need to write to make sure the app works - is ... obsolete. In this presentation, Roman Sandler and Gleb Bahmutov argue what the testing shape works better for today's web applications.
TechLead Conference 2023TechLead Conference 2023
35 min
A Framework for Managing Technical Debt
Let’s face it: technical debt is inevitable and rewriting your code every 6 months is not an option. Refactoring is a complex topic that doesn't have a one-size-fits-all solution. Frontend applications are particularly sensitive because of frequent requirements and user flows changes. New abstractions, updated patterns and cleaning up those old functions - it all sounds great on paper, but it often fails in practice: todos accumulate, tickets end up rotting in the backlog and legacy code crops up in every corner of your codebase. So a process of continuous refactoring is the only weapon you have against tech debt.In the past three years, I’ve been exploring different strategies and processes for refactoring code. In this talk I will describe the key components of a framework for tackling refactoring and I will share some of the learnings accumulated along the way. Hopefully, this will help you in your quest of improving the code quality of your codebases.

React Summit 2023React Summit 2023
24 min
Debugging JS
As developers, we spend much of our time debugging apps - often code we didn't even write. Sadly, few developers have ever been taught how to approach debugging - it's something most of us learn through painful experience.  The good news is you _can_ learn how to debug effectively, and there's several key techniques and tools you can use for debugging JS and React apps.
TestJS Summit 2022TestJS Summit 2022
27 min
Full-Circle Testing With Cypress
Cypress has taken the world by storm by brining an easy to use tool for end to end testing. It’s capabilities have proven to be be useful for creating stable tests for frontend applications. But end to end testing is just a small part of testing efforts. What about your API? What about your components? Well, in my talk I would like to show you how we can start with end-to-end tests, go deeper with component testing and then move up to testing our API, circ
TestJS Summit 2021TestJS Summit 2021
31 min
Test Effective Development
Developers want to sleep tight knowing they didn't break production. Companies want to be efficient in order to meet their customer needs faster and to gain competitive advantage sooner. We ALL want to be cost effective... or shall I say... TEST EFFECTIVE!But how do we do that?Are the "unit" and "integration" terminology serves us right?Or is it time for a change? When should we use either strategy to maximize our "test effectiveness"?In this talk I'll show you a brand new way to think about cost effective testing with new strategies and new testing terms!It’s time to go DEEPER!

Workshops on related topic

React Summit 2023React Summit 2023
151 min
Designing Effective Tests With React Testing Library
Featured Workshop
React Testing Library is a great framework for React component tests because there are a lot of questions it answers for you, so you don’t need to worry about those questions. But that doesn’t mean testing is easy. There are still a lot of questions you have to figure out for yourself: How many component tests should you write vs end-to-end tests or lower-level unit tests? How can you test a certain line of code that is tricky to test? And what in the world are you supposed to do about that persistent act() warning?
In this three-hour workshop we’ll introduce React Testing Library along with a mental model for how to think about designing your component tests. This mental model will help you see how to test each bit of logic, whether or not to mock dependencies, and will help improve the design of your components. You’ll walk away with the tools, techniques, and principles you need to implement low-cost, high-value component tests.
Table of contents- The different kinds of React application tests, and where component tests fit in- A mental model for thinking about the inputs and outputs of the components you test- Options for selecting DOM elements to verify and interact with them- The value of mocks and why they shouldn’t be avoided- The challenges with asynchrony in RTL tests and how to handle them
Prerequisites- Familiarity with building applications with React- Basic experience writing automated tests with Jest or another unit testing framework- You do not need any experience with React Testing Library- Machine setup: Node LTS, Yarn
TestJS Summit 2022TestJS Summit 2022
146 min
How to Start With Cypress
Featured WorkshopFree
The web has evolved. Finally, testing has also. Cypress is a modern testing tool that answers the testing needs of modern web applications. It has been gaining a lot of traction in the last couple of years, gaining worldwide popularity. If you have been waiting to learn Cypress, wait no more! Filip Hric will guide you through the first steps on how to start using Cypress and set up a project on your own. The good news is, learning Cypress is incredibly easy. You'll write your first test in no time, and then you'll discover how to write a full end-to-end test for a modern web application. You'll learn the core concepts like retry-ability. Discover how to work and interact with your application and learn how to combine API and UI tests. Throughout this whole workshop, we will write code and do practical exercises. You will leave with a hands-on experience that you can translate to your own project.
React Summit 2022React Summit 2022
117 min
Detox 101: How to write stable end-to-end tests for your React Native application
WorkshopFree
Compared to unit testing, end-to-end testing aims to interact with your application just like a real user. And as we all know it can be pretty challenging. Especially when we talk about Mobile applications.
Tests rely on many conditions and are considered to be slow and flaky. On the other hand - end-to-end tests can give the greatest confidence that your app is working. And if done right - can become an amazing tool for boosting developer velocity.
Detox is a gray-box end-to-end testing framework for mobile apps. Developed by Wix to solve the problem of slowness and flakiness and used by React Native itself as its E2E testing tool.
Join me on this workshop to learn how to make your mobile end-to-end tests with Detox rock.
Prerequisites- iOS/Android: MacOS Catalina or newer- Android only: Linux- Install before the workshop
TestJS Summit 2023TestJS Summit 2023
48 min
API Testing with Postman Workshop
WorkshopFree
In the ever-evolving landscape of software development, ensuring the reliability and functionality of APIs has become paramount. "API Testing with Postman" is a comprehensive workshop designed to equip participants with the knowledge and skills needed to excel in API testing using Postman, a powerful tool widely adopted by professionals in the field. This workshop delves into the fundamentals of API testing, progresses to advanced testing techniques, and explores automation, performance testing, and multi-protocol support, providing attendees with a holistic understanding of API testing with Postman.
1. Welcome to Postman- Explaining the Postman User Interface (UI)2. Workspace and Collections Collaboration- Understanding Workspaces and their role in collaboration- Exploring the concept of Collections for organizing and executing API requests3. Introduction to API Testing- Covering the basics of API testing and its significance4. Variable Management- Managing environment, global, and collection variables- Utilizing scripting snippets for dynamic data5. Building Testing Workflows- Creating effective testing workflows for comprehensive testing- Utilizing the Collection Runner for test execution- Introduction to Postbot for automated testing6. Advanced Testing- Contract Testing for ensuring API contracts- Using Mock Servers for effective testing- Maximizing productivity with Collection/Workspace templates- Integration Testing and Regression Testing strategies7. Automation with Postman- Leveraging the Postman CLI for automation- Scheduled Runs for regular testing- Integrating Postman into CI/CD pipelines8. Performance Testing- Demonstrating performance testing capabilities (showing the desktop client)- Synchronizing tests with VS Code for streamlined development9. Exploring Advanced Features - Working with Multiple Protocols: GraphQL, gRPC, and more
Join us for this workshop to unlock the full potential of Postman for API testing, streamline your testing processes, and enhance the quality and reliability of your software. Whether you're a beginner or an experienced tester, this workshop will equip you with the skills needed to excel in API testing with Postman.
React Summit Remote Edition 2021React Summit Remote Edition 2021
87 min
Building a Shopify App with React & Node
WorkshopFree
Shopify merchants have a diverse set of needs, and developers have a unique opportunity to meet those needs building apps. Building an app can be tough work but Shopify has created a set of tools and resources to help you build out a seamless app experience as quickly as possible. Get hands on experience building an embedded Shopify app using the Shopify App CLI, Polaris and Shopify App Bridge.We’ll show you how to create an app that accesses information from a development store and can run in your local environment.
TestJS Summit - January, 2021TestJS Summit - January, 2021
173 min
Testing Web Applications Using Cypress
WorkshopFree
This workshop will teach you the basics of writing useful end-to-end tests using Cypress Test Runner.
We will cover writing tests, covering every application feature, structuring tests, intercepting network requests, and setting up the backend data.
Anyone who knows JavaScript programming language and has NPM installed would be able to follow along.