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

¡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.

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.

¿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.

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.

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.

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.