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.
1. Introducción a la Charla
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
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
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
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
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
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.
Comments