Camino a Cero Fallos de Lint: Abordando Desafíos de Calidad de Código a Gran Escala

Hola, y bienvenidos a Camino a Cero Fallos de Lint, soy Chris Ng y soy un Ingeniero de Software Senior en LinkedIn. Hoy hablaré sobre nuestro viaje de miles de fallos de Lint a cero. ¿Por qué las reglas de Lint? Las reglas de Lint aseguran la consistencia, la prevención de errores y el mantenimiento. Nos permite escalar la orientación a todos los demás equipos dentro de LinkedIn para asegurar que todos estén cubiertos con los últimos y mejores standards de código, y también casos límite para prevenir errores comunes, y asegurar que la base de código sea consistente y determinista cuando estamos haciendo migraciones.

Ejecutamos nuestras reglas de Lint en tres etapas: durante el desarrollo, antes del compromiso y antes de la fusión. De esta manera se te alerta cuando estás violando una regla de Lint lo antes posible antes de involucrar a otros ingenieros. Entonces, ¿cuál es el problema, verdad? Añadamos todas las reglas de Lint. Creo que esta es una concepción común, desafortunadamente en la vida real enfrentamos problemas de escalabilidad.

Entonces, code quality y escala. Para contextualizar, nuestro código base en Linton tiene más de 80 años. React era la versión 0.13 en el momento en que se creó este repositorio. Tenemos más de 24,000 archivos y más de 100k compromisos. Esto se ve agravado por la existencia de muchos fallos de Lint ya existentes en el código base mientras comenzamos este proceso. Creo que había más de 7,000 fallos de Lint cuando comenzamos el camino a 0. Esto también se ve agravado por un número cada vez mayor de fallos de Lint que se introducen en la base de código debido a la introducción de nuevas reglas de Lint o la introducción de nuevo código que no corrige los fallos de Lint existentes.

Entonces, idealmente, llegas a un campamento y lo dejas mejor de lo que lo encontraste. Esa es una especie de analogía del campamento. El problema es ¿qué pasa si llegas al campamento cuando ya se ve así, bastante sucio, con muchos fallos de Lint? ¿Estás muy incentivado para limpiar esto? Entonces, lo que descubrimos fue que a muchas personas no les incentiva mucho limpiar esto.

Así que empezamos a añadir algunas reglas para limitar la cantidad de fallos de Lint que se introducen en la base de código. Empezamos a bloquear los commits cuando hay fallos de Lint y los archivos han cambiado. Establecimos límites para ciertos equipos, digamos que puedes tener 10 fallos de Lint para tu equipo en particular. Hicimos un proceso de revisión en dos pasos donde había un grupo de personas que estaban haciendo cumplir, por falta de un término mejor, los standards en la base de código. Algunas de estas cosas funcionaron y otras no, pero no nos llevaron a cero fallos de Lint.

Entonces, volvamos a la analogía, ¿verdad? ¿Cómo falla nuestra analogía? Entonces, si bloqueamos los commits, tenemos este sistema de revisión en dos pasos, pero ahora tu jefe te dice que necesitas aterrizar algo muy, muy rápido. ¿Qué crees que va a pasar, verdad? Lo que vimos que sucede es que las personas codifican alrededor del problema ya sea pidiendo a alguien una exención o realmente codificando físicamente alrededor del problema introduciendo una nueva clase o algo así, y luego lo envían, evitan todos los problemas, lo llevan a producción, lo llevan a los miembros lo más rápido posible, y obtienen el impacto que quieren. Esto realmente arruina la analogía del campamento. Por eso introdujimos una nueva regla donde cada regla de Lint que se introduce debe corregir todos los errores existentes antes de que podamos habilitarla como una regla de Lint de severidad de error. Eso significa que detenemos la hemorragia. No se están añadiendo nuevas reglas de Lint que hagan que los archivos existentes sean difíciles de mantener. Pero entonces, como autor de Lint, te preguntas, ¿qué pasa si hay 1,000 errores? ¿Tengo que corregir todos los 1,000 errores? No sé cómo corregir todos estos errores existentes. No tengo tiempo para hacer esto. ¿Y si rompo algo, causo un problema de producto? Lo que descubrimos fue que estos son problemas existentes con los que las personas que trabajan en la base de código data tienen que lidiar cuando ven un fallo de Lint, y no están incentivados para corregirlo. Y así, el autor de Lint necesita estar en la misma página que las personas que están siendo Linteadas. Entonces, el camino a cero fallos de Lint, se trata todo de incentivos. Esa es una especie de historia aquí. La forma en que lo llevamos a cabo fue más de incentivo que de castigo. Proporcionamos a las personas mucho soporte técnico. Cada pregunta obtendría una respuesta lo más pronto posible, la mayoría dentro de la misma hora, pero intentamos mantenerlo dentro del mismo día. Proporcionamos reconocimientos cuando alguien limpiaba un fallo de Lint. Proporcionamos una muy buena developer experience. Realmente nos enfocamos en el desarrollador que está corrigiendo sus fallos de Lint, así como en darles visibilidad una vez que han corregido algunos fallos de Lint en la base de código, así como reconocimiento. La forma en que facilitamos a los ingenieros la corrección de fallos de Lint fue proporcionando tooling. Identificamos los errores, identificamos a los propietarios, mantuvimos esta lista actualizada y la hicimos muy simple de usar, no una nueva herramienta para que un ingeniero aprenda. Simplemente una lista para que vean cuáles son los fallos y quiénes son los propietarios.

Éramos algo así como beneficiarios de una iniciativa diferente donde teníamos un único propietario por archivo. Esto garantiza la responsabilidad y rendición de cuentas para cada archivo en nuestra base de código. Así que nuestra primera versión MVP de nuestra herramienta fue literalmente solo una página web muy, digamos, del año 2000 donde desglosamos todos los fallos de ESLint por equipo, por regla de lint, y también por equipo y regla de lint. De modo que puedes visualizar para tu equipo cuántos eres responsable y dónde están en tu base de código, estos fallos de lint. Se actualizaba cada noche. Se ejecutaba desde la máquina de alguien, en realidad, en su escritorio, lo cual fue desafortunadamente, en realidad, una vez se apagó durante la COVID y tuvimos que conseguir que alguien lo volviera a encender.

Teníamos advertencias, errores y desactivaciones contados en cada contrato. Así que esta es una especie de vista del desglose por regla de lint donde te mostramos el nombre del archivo, si haces clic en este nombre de archivo, te llevará a la página de GitHub. Así de fácil es averiguar cuáles son los fallos de lint de tu equipo y dónde están. De esta manera entiendes cuánto te estás comprometiendo cuando estás tratando de arreglar algo. Usamos una herramienta llamada Checkup, que es esencialmente como un ejecutor de notas, donde cada noche ejecutaría estas tareas. Viene con algunas tareas incorporadas para JavaScript, ESLint, donde podemos ejecutar un plugin y este ejecutará ESLint en toda tu base de código y luego te dará un formato estructurado. Este es un ejemplo de ejecución de Checkup. Te dará un archivo Sarah, que es un formato estructurado. Este es un ejemplo del archivo Sarah, que analizamos en nuestra herramienta para mostrarte ese bonito diagrama. Oh, sí, y luego actualizamos nuestras herramientas al estándar de la empresa de interfaces de usuario. Creo que esto es DocuSource, solo para que sea más fácil de visualizar. Y cada semana damos a cada equipo una tarjeta de puntuación roja, verde o amarilla. Verde si has disminuido tus fallos de lint o si estás en cero. Amarillo si no hay disminución ni aumento y rojo si hay un aumento en los fallos de lint. Esto es muy importante porque lo que hemos visto es que mucha gente retrocede, no por su culpa o por algún tipo de medio nefasto, sino que simplemente suceden cosas y es fácil para nosotros ver estas regresiones e intentar arreglar inmediatamente. Este es un ejemplo de una tarjeta de puntuación que enviaríamos, es un correo electrónico manual, destacamos a dos o tres ingenieros por correo electrónico, intentamos realmente darles reconocimiento. Cuando arreglan algunos fallos de lint, pero realmente el tipo de aprendizaje que hemos encontrado fue que llegar a cero fue muy, muy difícil. Este es el tipo de gráfico que teníamos, a lo largo del viaje, donde puedes ver que la última milla fue muy, muy difícil de alcanzar, tomó casi la mitad del tiempo solo para terminar los últimos cientos. Pero la sostenibilidad importa, ¿verdad?, esa última milla realmente importa. Este es un ejemplo de un archivo con muchos fallos de lint. No es realmente agradable trabajar en este archivo, ¿verdad?, en comparación con un archivo sin fallos de lint. Es mucho más fácil entender un archivo, no hay trabajo oculto para que lo hagas. Todo está claro y cortado. Y así es como aprendimos, centrarse en el individuo realmente ayudó, dar reconocimientos personales, y realmente intentar mantener las reducciones al mínimo. Limpiamos más de 6,000 fallos de lint, tomó un poco más de un año y contribuyó a la toda la comunidad. Tuvimos 55 contribuyentes únicos a este esfuerzo. Al final de esto en nuestras encuestas trimestrales, hemos visto un aumento del 30% en cómo las personas perciben su calidad de código después de esta iniciativa. Y todavía añadimos nuevas reglas de lint mientras estábamos ejecutando esta iniciativa con más de 80 reglas de lint añadidas a nuestra configuración, con más de 45 contribuyentes añadiendo estos cambios de lint. Y eso es todo. Muchas gracias por asistir a mi charla.