Cómo utilizar la gamificación para mejorar la calidad en tu proyecto

Rate this content
Bookmark

Construir software se trata de encontrar el equilibrio adecuado entre características y calidad. Pero rara vez hablamos de cómo medir la calidad. ¡Veamos cómo un sistema de gamificación (puntos y clasificación) dentro de una acción de GitHub ayudó a los desarrolladores de mi equipo a preocuparse por la calidad!


13 min
20 Jun, 2022

Video Summary and Transcription

Bienvenidos a mi charla sobre cómo utilizar la gamificación para mejorar la calidad. La calidad del código es crucial e implica mantener deuda técnica, garantizar la mantenibilidad y priorizar la entrega y la calidad. Para mejorar la calidad del código, crea un nuevo estándar, automatiza el cumplimiento y motiva a los equipos. Resolver conflictos de fusión eliminando advertencias y automatizando la disminución de advertencias y la reducción de errores puede prevenir problemas futuros. Busca cero errores encontrando un equilibrio, mejorando las herramientas, bloqueando las solicitudes de extracción con errores e incentivando a los desarrolladores.

Available in English

1. Introducción a la Charla

Short description:

Bienvenidos a mi charla sobre el uso de la gamificación para mejorar la calidad. Soy Jonathan Wagner, un gerente de ingeniería en Theda UK. Siempre he tenido dificultades para encontrar el equilibrio adecuado entre la entrega rápida y la calidad del código.

¡Hola a todos! Bienvenidos a mi charla sobre el uso de la gamificación para mejorar la calidad. Para presentarme, soy Jonathan Wagner. Soy un gerente de ingeniería en Theda UK y he estado trabajando como líder técnico durante los últimos cuatro años en más de 10 proyectos en producción. Les puedo decir que siempre he tenido dificultades para encontrar el equilibrio adecuado entre la entrega rápida y tener una buena code quality en mis proyectos. He visto ambos extremos, como proyectos con una cobertura de código del 100% y proyectos que simplemente iban a lanzarse a producción sin testing nada. Así que siempre ha sido una lucha y quiero hablarles sobre todo esto.

2. Comprendiendo la Calidad del Código

Short description:

La calidad del código es un aspecto crucial de la ingeniería de software. Implica mantener la deuda técnica, garantizar la mantenibilidad y priorizar la entrega y la calidad. Es importante abordar tanto las soluciones rápidas como las causas raíz, priorizando primero la solución rápida y luego invirtiendo tiempo en prevenir problemas futuros.

Algo clásico que se dice en la ingeniería de software es que hay tres cosas difíciles. Tienes el almacenamiento en caché validation, dar nombres a las cosas y priorizar la calidad del código. ¿Qué quiero decir con calidad del código? Vamos a profundizar un poco más en esto. Es todo lo que implica la deuda técnica, la mantenibilidad, el factoraje, y así sucesivamente. Por lo tanto, se trata de encontrar el equilibrio adecuado entre la entrega y la calidad. Pero también se trata de decidir cuándo hacer la solución para la causa raíz en lugar de la solución rápida. Idealmente, quieres hacer ambas cosas, pero tal vez en el orden correcto. Así que prioriza la solución rápida y luego invierte tiempo en buscar la causa raíz y prevenir que el problema vuelva a ocurrir. Pero esa es la primera pregunta de priorización.

3. Mejorando la Calidad del Código

Short description:

Para mejorar la calidad del código, comienza por crear un nuevo estándar para el código nuevo, automatizando su cumplimiento mediante herramientas como ESLint. Aborda el código heredado motivando a los equipos a priorizar su mejora. Compartiré una historia sobre cómo abordamos esto, comenzando con un proyecto con 1500 advertencias. Utilizamos la gamificación y CI para incentivar la reducción de advertencias, pero nos encontramos con desafíos con las solicitudes de extracción simultáneas.

¿Cómo puedes mejorarlo? Puede ser bastante complejo. Comencé a desarrollar una teoría al respecto y voy a intentar explicártela. Así que empecemos dividiendo el problema en partes más pequeñas. Digamos que tienes una base de código y quieres mejorarla. Lo primero que puedes intentar es analizar el código nuevo que agregas. Y luego, enfócate en el código heredado.

Entonces, primero, la parte más sencilla, el código nuevo. Puedes comenzar creando un nuevo estándar, capacitando a tu equipo con este nuevo estándar y luego dificultando que las personas escriban código deficiente. Ese es un paso importante que puedes automatizar. Para automatizarlo, puedes utilizar herramientas como ESLint. No es la única solución, definitivamente no es perfecta, no atrapa todo, pero ayuda a prevenir errores. A menudo, al analizar la causa raíz de un error, puedes identificar que una regla de ESLint podría haberlo evitado. Así que es una buena oportunidad para agregar una nueva regla, capacitar a tu equipo en ella, asegurarte de que sepan cómo solucionarla y poco a poco hacer algo al respecto. Y eso significa que el nuevo código que escribas tenga mejores estándares y, con suerte, también mejore el código heredado.

Pero este código heredado, es difícil decidir cuándo analizarlo o no. Y es aún más difícil motivar a todos en tu equipo o en varios equipos, si es necesario analizarlo. Ahí es cuando se vuelve complicado. ¿Qué haces en ese caso? Permíteme contarte una pequeña historia sobre cómo abordé el problema y explicar algunas otras cosas que he aprendido en el camino. Inicialmente, teníamos un proyecto con alrededor de 1500 advertencias. Bastantes advertencias y este número disminuía muy lentamente. Cada vez que los desarrolladores agregaban funciones, se sabía que no debían agregar nuevas advertencias y Bluecross sería bloqueado por el líder técnico o los desarrolladores en caso de aumento del número. Eso significa que había un límite máximo de advertencias en el código. Y si cambia, debe disminuir, no puede aumentar. Pero en algunos casos, rompimos el flujo de implementación. Eso ocurría cuando dos desarrolladores increíbles querían disminuir el número al mismo tiempo con una solicitud de extracción diferente. Digamos que el primer desarrollador soluciona dos advertencias. El máximo de advertencias ahora es 1498. Y el otro desarrollador soluciona tres advertencias diferentes. Eso significa que su máximo de advertencias baja a 1497.

4. Resolviendo Conflictos de Fusión

Short description:

Nos encontramos con un problema donde fusionar código con un número diferente de advertencias causaba errores inesperados. Para evitar esto, decidimos eliminar las advertencias y solo permitir errores. Modificando el YesLimConfig y utilizando la herramienta Klinter, eliminamos con éxito todos los errores y prevenimos futuros conflictos de fusión.

El primero se fusiona. Todo está en verde, todo bien. El segundo se fusiona. No se reemplazó previamente. Todo estaba en verde sin conflictos de fusión. Y boom. Se rompe. ¿Por qué se rompió? Es porque ahora tenemos menos cinco advertencias en lugar de las menos tres o menos dos que teníamos antes. Y eso significa que todo está roto. Alguien tiene que arreglarlo. Las personas no están seguras de por qué está roto. Es posible que no tengan las alertas. Podría llevar mucho tiempo arreglarlo.

Así que queremos evitar eso a toda costa. Y una forma de hacerlo es básicamente eliminar las advertencias. Digamos que ya no queremos advertencias. Solo queremos errores. Esa es una forma de verlo. Eso es lo que intentamos. Básicamente fui al YesLimConfig. Cambiamos todas las advertencias por errores y sobrescribimos el que estaba predeterminado por los complementos que teníamos. Y pasamos de 1500 advertencias a cero. Pero luego tuvimos la misma cantidad de errores y eso significaba que el RCA estaba roto.

Pero gracias a Dios teníamos una pequeña herramienta que ya existía, que es un generador de LimConfig llamado Klinter. Es de código abierto. También puedes usarlo. Y te ayuda a agregar automáticamente comentarios deshabilitados de YesLim en todas partes donde tienes un error. Y eso significa que no tenemos más errores. El CR estaba limpio nuevamente y nunca tuvimos más conflictos de fusión como este. Así que el primer paso, bastante simple, resuelve todo.

5. Automatización de la Disminución de Advertencias y Reducción de Errores

Short description:

Automaté el proceso de disminución de advertencias creando una acción en GitHub que publica un comentario en las solicitudes de extracción, proporcionando puntos ganados y clasificaciones. Se tarda menos de 10 segundos y hace el trabajo bien. Después de algunos errores iniciales, el sistema funcionó sin problemas durante los siguientes tres meses. Comenzamos con alrededor de 1600 errores y, a pesar de algunas semanas malas, logramos disminuir el número de errores en 235 en tres meses. A un ritmo de aproximadamente 78 errores por mes, nos llevaría 4 años llegar a cero errores.

Pero luego tenemos el problema de disminuir nuestras advertencias. Así que eso fue cuando comencé a pensar en, OK, intentemos automatizar esto. Intentemos poner un pequeño incentivo en su lugar. Intentemos convertirlo en un juego con una tabla de clasificación. Así que me puse manos a la obra, codifiqué rápidamente y esto es lo que se me ocurrió.

Es una acción de GitHub. Se puede adaptar a SQL CI, GitLab o cualquier otra herramienta de CI que utilices. Es bastante simple. Básicamente, publica un comentario en tu solicitud de extracción y te dice cuántos puntos has ganado en la solicitud de extracción. Cuántos puntos has ganado desde el comienzo de la semana y tu clasificación actual para esta semana. Y puedes ver el podio, la tabla de clasificación completa y la explicación de cómo ganar puntos. Básicamente, lo que sucede es, toma la diferencia de git en la solicitud de extracción y luego cuenta cuántas líneas agregaste que contenían una negación anidada y cuántas líneas eliminaste que contenían una negación anidada. Luego, en base a esto, obtenemos la puntuación. Calculamos la puntuación para todos e imprimimos la tabla de clasificación. No es necesario almacenar nada en ningún lugar, se calcula allí cada vez que abres una solicitud de extracción. Se tarda menos de 10 segundos y hace el trabajo muy bien.

Así que implementé eso, estaba muy orgulloso de mí mismo. Lo lanzamos, la primera semana, muchos errores. Muchas solicitudes de extracción tenían cero puntos cuando las personas deberían haber tenido puntos. La gente se quejó, la gente estaba descontenta, trabajé un poco en eso. Y después de eso, fue un viaje tranquilo durante los siguientes tres meses.

Entonces aquí está la data de los tres meses en el proyecto. Comenzamos con alrededor de 1600 y luego puedes ver algunas nuevas reglas de destinatario agregadas. Y en general, parece que ha aumentado bastante. Pero acerquémonos un poco más y veamos qué sucede. Así que primero, acercándonos a los 3000 y luego agregando algunas líneas de base, podemos ver que aparte de un par de semanas en abril que fueron un poco malas al principio y al final, tuvimos buenos momentos. Y hay un poco más de cálculos sobre eso. Si olvidamos todas las reglas que hemos agregado, en realidad disminuimos nuestro número de errores en 235 en aproximadamente tres meses. Eso es un ritmo de aproximadamente 78 al mes. Y suponiendo que comenzamos, ahora comenzamos en 3500, nos llevaría 4 años llegar a cero.

6. Striving for Zero Errors and Ensuring Code Quality

Short description:

Podemos aspirar a cero errores en el código, pero al tratar con código heredado, corregir todo puede introducir nuevos errores. Es importante encontrar un equilibrio y priorizar las mejoras. Para garantizar la calidad del código, podemos mejorar la herramienta, bloquear las solicitudes de extracción con errores, mostrar puntos potenciales y realizar un seguimiento de la disminución semanal de errores. Explorar alternativas como las pruebas e incentivar a los desarrolladores también puede ser beneficioso. En última instancia, el objetivo es hacer que la programación sea divertida y fomentar las contribuciones para mejorar la calidad.

Podemos hacer un poco más de matemáticas y pensar, bueno, 78 por mes. Si tenemos un equipo de, digamos, 35 desarrolladores, eso significa que cada desarrollador soluciona un error cada dos semanas. Definitivamente no es mucho. Probablemente puedas esperar que solucionen alrededor de dos errores en una semana. Eso significa dividir ese número entre cuatro, lo que significa que en un año podríamos llegar a cero. Entonces, ¿es bueno? ¿Es malo? ¿Qué opinan ustedes? Ese es el tipo de pregunta que nos estábamos haciendo y que puedo explicar lo que he aprendido.

En primer lugar, ¿deberíamos aspirar a no tener errores? ¿Es algo que deberíamos... ¿Deberíamos corregir todo? ¿Deberíamos llegar a cero? Mi opinión es que al tocar código heredado, es posible que introduzcamos nuevos errores porque el código ya está funcionando. Es posible que no esté bien probado y al tocarlo, aumentamos las posibilidades de introducir nuevas regresiones. Aspirar a no tener errores probablemente signifique insertar nuevos errores en la base de código. Es como lo opuesto completo a lo que queremos hacer en primer lugar. Entonces, tal vez ese no sea realmente el objetivo. Tal vez simplemente sea normal tener una pendiente que es bastante buena al principio y luego después de un tiempo se estabiliza y es normal porque el nuevo código cumple con los estándares y no necesitas corregir nada más.

Algo más en lo que puedes pensar entonces es cómo asegurarte de llegar a esa situación de la mejor manera posible y cómo detectar cuando llegas allí. Tal vez puedas mejorar la herramienta. Tal vez podamos tener nuevas funciones como asegurarnos de bloquear la solicitud de extracción para evitar que las personas agreguen nuevos errores. Podríamos mostrar puntos potenciales al observar los archivos que se han modificado. Entonces, si miramos cada archivo y cuántas advertencias tiene podemos decir, si hubieras corregido todo en ese archivo habrías ganado 20 puntos en lugar de solo tres. También podemos mostrar la diferencia semanal total para que cada semana puedas asegurarte de que el número esté disminuyendo y no se mantenga igual como en abril. Y tal vez haya otras alternativas. Tal vez no deberíamos limitarnos solo a eslint. Tal vez podríamos considerar las pruebas y asegurarnos de que cuando probemos archivos también ganemos puntos. Tal vez también podríamos incentivar más a las personas como darles un premio cuando obtengan el primer lugar o también podrías mostrar la tabla de clasificación en la televisión para que todos la vean en todo momento y asegurarnos de que esté presente en la mente de todos como una prioridad. Pero eso depende de si realmente es una prioridad. Pero lo más importante, ¿fue divertido programar? Definitivamente. Me divertí mucho programando esto y realmente espero que ustedes comiencen a probarlo, contribuyan y sí, lo implementen en su proyecto jueguen con él, abran solicitudes de extracción y mejoren la calidad en todas partes. Eso es todo. Gracias y no duden en comunicarse si tienen alguna dificultad, alguna pregunta y adiós.

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

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 Day Berlin 2022React Day Berlin 2022
29 min
Fighting Technical Debt With Continuous Refactoring
Top Content
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
26 min
Principles for Scaling Frontend Application Development
After spending over a decade at Google, and now as the CTO of Vercel, Malte Ubl is no stranger to being responsible for a team’s software infrastructure. However, being in charge of defining how people write software, and in turn, building the infrastructure that they’re using to write said software, presents significant challenges. This presentation by Malte Ubl will uncover the guiding principles to leading a large software infrastructure.
React Day Berlin 2022React Day Berlin 2022
25 min
Building High-Performing Cross-Cultural Teams
Everything we do, from the way in which we write our emails, to the method in which we provide negative feedback and evaluate performance, governs the performance of our teams. And understanding how culture impacts our efficacy as a team can drastically improve our day-to-day collaboration. In this session you'll learn: How different cultures communicate, How different cultures evaluate performance and give constructive criticism, How different cultures make decisions, How different cultures trust, How different cultures perceive time.
React Summit 2022React Summit 2022
21 min
Scale Your React App without Micro-frontends
As your team grows and becomes multiple teams, the size of your codebase follows. You get to 100k lines of code and your build time dangerously approaches the 10min mark 😱 But that’s not all, your static CI checks (linting, type coverage, dead code) and tests are also taking longer and longer...How do you keep your teams moving fast and shipping features to users regularly if your PRs take forever to be tested and deployed?After exploring a few options we decided to go down the Nx route. Let’s look at how to migrate a large codebase to Nx and take advantage of its incremental builds!
Node Congress 2023Node Congress 2023
30 min
Next Generation Code Architecture for Building Maintainable Node Applications
In today's fast-paced software development landscape, it's essential to have tools that allow us to build, test, and deploy our applications quickly and efficiently. Being able to ship features fast implies having a healthy and maintainable codebase, which can be tricky and daunting, especially in the long-run.In this talk, we'll explore strategies for building maintainable Node backends by leveraging tooling that Nx provides. This includes how to modularize a codebase, using code generators for consistency, establish code boundaries, and how to keep CI fast as your codebase grows.

Workshops on related topic

DevOps.js Conf 2022DevOps.js Conf 2022
76 min
Bring Code Quality and Security to your CI/CD pipeline
WorkshopFree
In this workshop we will go through all the aspects and stages when integrating your project into Code Quality and Security Ecosystem. We will take a simple web-application as a starting point and create a CI pipeline triggering code quality monitoring for it. We will do a full development cycle starting from coding in the IDE and opening a Pull Request and I will show you how you can control the quality at those stages. At the end of the workshop you will be ready to enable such integration for your own projects.