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

This ad is not shown to multipass and full ticket holders
React Summit US
React Summit US 2025
November 18 - 21, 2025
New York, US & Online
The biggest React conference in the US
Learn More
In partnership with Focus Reactive
Upcoming event
React Summit US 2025
React Summit US 2025
November 18 - 21, 2025. New York, US & Online
Learn more
Bookmark
Rate this content

Las reglas de Lint nos permiten mantener la calidad del código y minimizar los errores. Puede impactar positivamente en la productividad y la felicidad del desarrollador, especialmente cuando se trabaja en una aplicación masiva con múltiples equipos trabajando juntos. Pero, ¿qué pasa si tu aplicación a gran escala contiene miles de fallos de Lint a lo largo de los muchos años que ha estado funcionando en producción? Esta charla explorará estrategias accionables para abordar eficazmente los fallos de Lint a gran escala para que podamos volver a confiar en las reglas de Lint para garantizar una calidad de código consistente y agilizar los procesos de desarrollo, lo que lleva a una base de código más robusta y mantenible.

This talk has been presented at React Summit US 2023, check out the latest edition of this React Conference.

FAQ

Las reglas de Lint aseguran la consistencia, la prevención de errores y el mantenimiento en el código. Ayudan a escalar la orientación a todos los equipos dentro de una organización para que sigan los mejores estándares de código y prevenir errores comunes.

En LinkedIn, las reglas de Lint se ejecutan en tres etapas: durante el desarrollo, antes del compromiso y antes de la fusión de código. Esto permite identificar violaciones a las reglas lo más pronto posible.

El desafío principal fue lidiar con una gran cantidad de fallos de Lint ya existentes y la introducción continua de nuevos fallos debido a nuevas reglas de Lint o código nuevo que no corregía los fallos existentes.

Se añadieron reglas para limitar la cantidad de fallos de Lint introducidos, se bloquearon los commits con fallos, se establecieron límites de fallos por equipo, y se implementó un proceso de revisión en dos pasos para hacer cumplir los estándares de código.

LinkedIn cambió su enfoque de castigo a incentivo, proporcionando soporte técnico rápido, reconocimientos y una mejor experiencia de desarrollo. Esto incluyó la implementación de herramientas que facilitaban a los ingenieros identificar y corregir fallos de Lint.

Se creó una herramienta llamada Checkup que ejecuta ESLint en toda la base de código y otra herramienta que desglosa los fallos de Lint por equipo y regla, actualizada diariamente, facilitando la visualización y gestión de fallos.

La iniciativa logró reducir más de 6,000 fallos de Lint, involucró a 55 contribuyentes únicos y mejoró la percepción de la calidad de código en un 30% según las encuestas trimestrales.

Chris Ng
Chris Ng
11 min
15 Nov, 2023

Comments

Sign in or register to post your comment.
Video Summary and Transcription
Esta charla discute el viaje desde miles de fallos de Lint a cero en una base de código en Linton que tiene más de 80 años. El enfoque implicó la implementación de reglas, incentivos y herramientas para abordar el problema. La herramienta llamada Checkup se utilizó para visualizar los fallos de ESLint por equipo y regla de Lint, proporcionando responsabilidad y responsabilidad. Los esfuerzos resultaron en la limpieza de más de 6,000 fallos de Lint, con 55 contribuyentes, y un aumento del 30% en la calidad de código percibida.

1. Introducción a Camino a Cero Fallos de Lint

Short description:

Hoy hablaré sobre nuestro viaje de miles de fallos de Lint a cero. Las reglas de Lint aseguran la consistencia, la prevención de errores y el mantenimiento. Ejecutamos nuestras reglas de Lint en tres etapas: durante el desarrollo, antes del compromiso y antes de la fusión. Para contextualizar, nuestro código base en Linton tiene más de 80 años. 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.

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.

2. Camino a Cero Fallos de Lint: Incentivos y Herramientas

Short description:

Introdujimos reglas para limitar la introducción de fallos de Lint e implementamos un proceso de revisión en dos pasos. Sin embargo, estas medidas no eliminaron completamente los fallos de Lint. Para abordar esto, implementamos una nueva regla donde cada regla de Lint debe corregir todos los errores existentes antes de ser habilitada. También nos enfocamos en proporcionar incentivos para que los desarrolladores corrijan los fallos de Lint, como soporte técnico, reconocimientos y una buena experiencia de desarrollador. Facilitamos a los ingenieros la corrección de fallos de Lint proporcionando herramientas que identificaban los errores y sus propietarios.

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.

3. Herramientas, Visualización y Reducciones

Short description:

Implementamos una herramienta para visualizar los fallos de ESLint por equipo y regla de lint, proporcionando responsabilidad y rendición de cuentas. La herramienta, llamada Checkup, ejecuta tareas nocturnas y genera informes estructurados. Actualizamos nuestras herramientas para mejorar la visualización e introdujimos un sistema de tarjetas de puntuación para monitorear las reducciones de fallos de lint. Llegar a cero fallos de lint fue un desafío, pero centrarse en los individuos, dar reconocimientos y mantener las reducciones al mínimo ayudó. Limpiamos más de 6,000 fallos de lint, con 55 contribuyentes, y vimos un aumento del 30% en la calidad del código percibida.

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

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

Principios para Escalar el Desarrollo de Aplicaciones Frontend
React Summit 2023React Summit 2023
25 min
Principios para Escalar el Desarrollo de Aplicaciones Frontend
Top Content
This Talk discusses scaling front-end applications through principles such as tearing down barriers, sharing code in a monorepo, and making it easy to delete code. It also emphasizes incremental migration, embracing lack of knowledge, and eliminating systematic complexity. The Talk highlights the use of automation in code migration and the importance of removing barriers to enable smoother code migration.
IA y Desarrollo Web: ¿Exageración o Realidad?
JSNation 2023JSNation 2023
24 min
IA y Desarrollo Web: ¿Exageración o Realidad?
Top Content
This talk explores the use of AI in web development, including tools like GitHub Copilot and Fig for CLI commands. AI can generate boilerplate code, provide context-aware solutions, and generate dummy data. It can also assist with CSS selectors and regexes, and be integrated into applications. AI is used to enhance the podcast experience by transcribing episodes and providing JSON data. The talk also discusses formatting AI output, crafting requests, and analyzing embeddings for similarity.
Construyendo una Aplicación Web: El Camino Fácil y el Camino de Alto Rendimiento. ¿Por qué no son lo mismo?
JSNation 2023JSNation 2023
31 min
Construyendo una Aplicación Web: El Camino Fácil y el Camino de Alto Rendimiento. ¿Por qué no son lo mismo?
Misko Havry introduces himself and discusses the impact of JavaScript on performance. The concepts of reconciliation, hydration, and resumability are explored, along with the importance of clean code and compiler optimization. The Talk includes demos of application components and showcases the power of code extraction. The QUIC framework is highlighted for its ability to optimize code loading and prioritize interactions. The service worker is used to selectively download components for improved performance. SEO and debugging in QUIC are also discussed, along with comparisons to other frameworks.
Una Saga de Problemas de Renderizado Web
Vue.js London 2023Vue.js London 2023
28 min
Una Saga de Problemas de Renderizado Web
This Talk discusses the problems faced in building and rendering web applications, different rendering methods and strategies, and the benefits of the Yamstack architecture. It covers server-side rendering, static site generation, incremental static regeneration, and edge rendering. The speaker demonstrates how to build a static site using a Hello CMS and the JAMstack architecture. Other topics include connecting Storyboard with a Nuxt application, mock data, hybrid rendering, and handling I18N with a static site generator.
Olvida el mal código, concéntrate en el sistema
React Summit US 2023React Summit US 2023
27 min
Olvida el mal código, concéntrate en el sistema
Top ContentPremium
Setting up the system and separating concerns are important in software development. Modular construction and prefab units are a new trend that makes construction quicker and easier. Architectural complexity can lead to a drop in productivity and an increase in defects. Measuring architectural complexity can help identify natural modules in the code. Best practices for avoiding architectural complexity include organizing code by business domain and using prop drilling. Atomic design and organizing a monorepo are recommended approaches for managing architectural complexity.
Potenciando Tu Experiencia de Desarrollo Con Turborepo
React Day Berlin 2022React Day Berlin 2022
26 min
Potenciando Tu Experiencia de Desarrollo Con Turborepo
Top Content
This Talk explores the benefits of using TuberApple, a tool for supercharging the development experience. It highlights the advantages of monorepos, such as code reuse, shared standards, improved team collaboration, and atomic changes. TuberApple, specifically Tuburepo, offers efficient task execution through caching and optimized scheduling. It simplifies monorepo development by allowing parallel execution of tasks and seamless coordination of changes. Tubo, another tool within TuberApple, enables smart task execution, declaring task dependencies, and efficient caching in monorepos.

Workshops on related topic

Desarrollando Aplicaciones Listas para Producción en Colaboración con Agentes de AI
React Summit 2025React Summit 2025
102 min
Desarrollando Aplicaciones Listas para Producción en Colaboración con Agentes de AI
Featured Workshop
Alex Shershebnev
Alex Shershebnev
Los asistentes de codificación ya están cambiando la forma en que desarrollamos código, y en varios años se espera que cambien completamente cómo los desarrolladores interactúan con el código y lo escriben. En esta masterclass, compartiré consejos y mejores prácticas sobre el uso de tales herramientas mientras desarrollamos la aplicación lista para producción con Zencoder.
React a Escala con Nx
React Summit 2023React Summit 2023
145 min
React a Escala con Nx
Top Content
WorkshopFree
Isaac Mann
Isaac Mann
Vamos a utilizar Nx y algunos de sus plugins para acelerar el desarrollo de esta aplicación.
Algunas de las cosas que aprenderás:- Generar un espacio de trabajo Nx prístino- Generar aplicaciones frontend React y APIs backend dentro de tu espacio de trabajo, con proxies preconfigurados- Crear librerías compartidas para reutilizar código- Generar nuevos componentes enrutados con todas las rutas preconfiguradas por Nx y listas para usar- Cómo organizar el código en un monorepositorio- Mover fácilmente las librerías alrededor de tu estructura de carpetas- Crear historias de Storybook y pruebas e2e de Cypress para tus componentes
Tabla de contenidos: - Lab 1 - Generar un espacio de trabajo vacío- Lab 2 - Generar una aplicación React- Lab 3 - Ejecutores- Lab 3.1 - Migraciones- Lab 4 - Generar una librería de componentes- Lab 5 - Generar una librería de utilidades- Lab 6 - Generar una librería de rutas- Lab 7 - Añadir una API de Express- Lab 8 - Mostrar un juego completo en el componente de detalle de juego enrutado- Lab 9 - Generar una librería de tipos que la API y el frontend pueden compartir- Lab 10 - Generar historias de Storybook para el componente de interfaz de usuario compartido- Lab 11 - Prueba E2E del componente compartido
Problemas difíciles de GraphQL en Shopify
GraphQL Galaxy 2021GraphQL Galaxy 2021
164 min
Problemas difíciles de GraphQL en Shopify
Workshop
Rebecca Friedman
Jonathan Baker
Alex Ackerman
Théo Ben Hassen
 Greg MacWilliam
5 authors
En Shopify a gran escala, resolvemos algunos problemas bastante difíciles. En este masterclass, cinco oradores diferentes describirán algunos de los desafíos que hemos enfrentado y cómo los hemos superado.

Tabla de contenidos:
1 - El infame problema "N+1": Jonathan Baker - Vamos a hablar sobre qué es, por qué es un problema y cómo Shopify lo maneja a gran escala en varios APIs de GraphQL.
2 - Contextualizando APIs de GraphQL: Alex Ackerman - Cómo y por qué decidimos usar directivas. Compartiré qué son las directivas, qué directivas están disponibles de forma predeterminada y cómo crear directivas personalizadas.
3 - Consultas de GraphQL más rápidas para clientes móviles: Theo Ben Hassen - A medida que tu aplicación móvil crece, también lo harán tus consultas de GraphQL. En esta charla, repasaré diversas estrategias para hacer que tus consultas sean más rápidas y efectivas.
4 - Construyendo el producto del futuro hoy: Greg MacWilliam - Cómo Shopify adopta las características futuras en el código actual.
5 - Gestión efectiva de APIs grandes: Rebecca Friedman - Tenemos miles de desarrolladores en Shopify. Veamos cómo estamos asegurando la calidad y consistencia de nuestras APIs de GraphQL con tantos colaboradores.
Cómo Crear una Aplicación Web de Manera (Casi) Autónoma Usando Clean Coder
Productivity Conf for Devs and Tech LeadersProductivity Conf for Devs and Tech Leaders
95 min
Cómo Crear una Aplicación Web de Manera (Casi) Autónoma Usando Clean Coder
Workshop
Grigorij Dudnik
Grigorij Dudnik
Imagina reemplazarte a ti mismo con un programador de IA multi-agente para desarrollar tu aplicación web de producción. Eso es exactamente lo que hicimos en mi startup takzyli.pl. Para lograr esto, diseñamos y utilizamos el Clean Coder - marco de agentes de IA para la escritura autónoma de código (https://github.com/GregorD1A1/Clean-Coder-AI), que es un proyecto de código abierto, con suerte. Si funcionó para nosotros, ¿por qué no debería funcionar para ti?En esta masterclass, te mostraré cómo crear una aplicación web completa de manera (casi) autónoma y reducir drásticamente el tiempo que tú o tus empleados pasan escribiendo código.
Aporta Calidad y Seguridad al pipeline de CI/CD
DevOps.js Conf 2022DevOps.js Conf 2022
76 min
Aporta Calidad y Seguridad al pipeline de CI/CD
Workshop
Elena Vilchik
Elena Vilchik
En esta masterclass repasaremos todos los aspectos y etapas al integrar tu proyecto en el ecosistema de Calidad y Seguridad del Código. Tomaremos una aplicación web simple como punto de partida y crearemos un pipeline de CI que active el monitoreo de calidad del código. Realizaremos un ciclo completo de desarrollo, comenzando desde la codificación en el IDE y abriendo una Pull Request, y te mostraré cómo puedes controlar la calidad en esas etapas. Al final de la masterclass, estarás listo para habilitar esta integración en tus propios proyectos.
Test, Code, Repeat: Dominando el Desarrollo Asistido por AI
Productivity Conf for Devs and Tech LeadersProductivity Conf for Devs and Tech Leaders
53 min
Test, Code, Repeat: Dominando el Desarrollo Asistido por AI
Workshop
Marco Pierobon
Marco Pierobon
"Test, Code, Repeat: Dominando el Desarrollo Asistido por AI" introduce a los desarrolladores a una forma transformadora de codificación con AI como un socio colaborativo. Esta masterclass se centra en cómo los flujos de trabajo iterativos, como la técnica de emparejamiento ping pong, permiten una interacción mejorada entre la creatividad humana y la eficiencia de AI.