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

Rate this content
Bookmark

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.

11 min
15 Nov, 2023

AI Generated Video Summary

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

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.
JSNation 2023JSNation 2023
24 min
AI and Web Development: Hype or Reality
In this talk, we'll take a look at the growing intersection of AI and web development. There's a lot of buzz around the potential uses of AI in writing, understanding, and debugging code, and integrating it into our applications is becoming easier and more affordable. But there are also questions about the future of AI in app development, and whether it will make us more productive or take our jobs.
There's a lot of excitement, skepticism, and concern about the rise of AI in web development. We'll explore the real potential for AI in creating new web development frameworks, and separate fact from fiction.
So if you're interested in the future of web development and the role of AI in it, this talk is for you. Oh, and this talk abstract was written by AI after I gave it several of my unstructured thoughts.
JSNation 2023JSNation 2023
31 min
Building a Web-App: The Easy Path and the Performant Path. Why Are They Not the Same?
We use frameworks to make building our applications easier. Yet as the application scales, its performance suffers. There is no one thing, but rather a death by thousand cuts. Developers are under pressure, and they often choose the easy and quick path to deliver a feature rather than the performant path. The performant path is usually more work. So let's look at these two paths and imagine a world where the performant path is the quick and easy path.
Vue.js London 2023Vue.js London 2023
28 min
A Saga of Web Rendering Woes
This talk will look at the evolution of web rendering modes and what the Jamstack movement is all about. We will build a demo project to show how a static site generator and a Headless CMS can be combined to create dynamic and engaging stories while maintaining a static site's performance and scalability benefits.You will learn about the advantages and limitations of each rendering mode and gain a deeper understanding of how to use Jamstack to build powerful and dynamic storytelling experiences.
JSNation 2022JSNation 2022
46 min
Confessions from an Impostor
You know what impostor syndrome is, right!? Most all of us have felt that nagging feeling that we're faking it and that we're sure to be found out by all the experts around us at any moment.But before you go assuming this talk is the same ol' song and dance full of platitudes that encourage you to ignore that syndrome, let me clue you in on a little secret: there's no experts around you. Impostorism is not a syndrome at all, it's a pragmatic mindset and perspective, one we should all embrace and be proud of. In fact, it's vital to us getting our jobs done.

Workshops on related topic

React Summit 2023React Summit 2023
145 min
React at Scale with Nx
Featured WorkshopFree
We're going to be using Nx and some its plugins to accelerate the development of this app.
Some of the things you'll learn:- Generating a pristine Nx workspace- Generating frontend React apps and backend APIs inside your workspace, with pre-configured proxies- Creating shared libs for re-using code- Generating new routed components with all the routes pre-configured by Nx and ready to go- How to organize code in a monorepo- Easily move libs around your folder structure- Creating Storybook stories and e2e Cypress tests for your components
Table of contents: - Lab 1 - Generate an empty workspace- Lab 2 - Generate a React app- Lab 3 - Executors- Lab 3.1 - Migrations- Lab 4 - Generate a component lib- Lab 5 - Generate a utility lib- Lab 6 - Generate a route lib- Lab 7 - Add an Express API- Lab 8 - Displaying a full game in the routed game-detail component- Lab 9 - Generate a type lib that the API and frontend can share- Lab 10 - Generate Storybook stories for the shared ui component- Lab 11 - E2E test the shared component
GraphQL Galaxy 2021GraphQL Galaxy 2021
164 min
Hard GraphQL Problems at Shopify
WorkshopFree
At Shopify scale, we solve some pretty hard problems. In this workshop, five different speakers will outline some of the challenges we’ve faced, and how we’ve overcome them.

Table of contents:
1 - The infamous "N+1" problem: Jonathan Baker - Let's talk about what it is, why it is a problem, and how Shopify handles it at scale across several GraphQL APIs.
2 - Contextualizing GraphQL APIs: Alex Ackerman - How and why we decided to use directives. I’ll share what directives are, which directives are available out of the box, and how to create custom directives.
3 - Faster GraphQL queries for mobile clients: Theo Ben Hassen - As your mobile app grows, so will your GraphQL queries. In this talk, I will go over diverse strategies to make your queries faster and more effective.
4 - Building tomorrow’s product today: Greg MacWilliam - How Shopify adopts future features in today’s code.
5 - Managing large APIs effectively: Rebecca Friedman - We have thousands of developers at Shopify. Let’s take a look at how we’re ensuring the quality and consistency of our GraphQL APIs with so many contributors.
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.