Pero aquí tienes una lista. Una lista de cosas que quieres arreglar. Ahora, de nuevo, esto es desagradable para tu code base, por lo que para nuestro producto Spaces estamos utilizando estas listas de permitidos externas que no ensucian tu code base. Básicamente tienes un archivo JSON que dice que hay algunas reglas aquí, y en este archivo está bien violar las reglas.
Ahora, volviendo al tema de mejorar y no empeorar, lo que realmente quieres ver para la code base de tu equipo es un gráfico como este. Estas son las violaciones con el tiempo. Quieres que esto disminuya con el tiempo y luego ves estos escalones hacia arriba. Eso en realidad no está mal, eso es cuando introduces una nueva regla. Permites todas las violaciones existentes y luego, a medida que este code realmente se toca, mejora con el tiempo. Quiero animar a todos a permitir esto. No es realmente importante migrar todo y ponerlo en el nuevo estado. La razón es que, y esto es algo que no me resultaba obvio al principio de mi career en absoluto, que si tienes algo como una regla sobre tu aplicación, el valor marginal de esa regla es drásticamente mayor en el nuevo code que en el antiguo code, porque tu antiguo code ha sido probado en batalla. Pasó por QA, pasó por interrupciones de producción, pasó por usuarios teniendo ideas creativas sobre qué es un nombre. Ya arreglaste todas estas cosas, ¿verdad? Y por lo tanto, es probable que en realidad no encuentres nada interesante. La razón por la que existen estas reglas es que cuando escribes algo nuevo, en ese momento te dice de inmediato, hey, estás cometiendo un error, ve a arreglarlo ahora, ¿verdad? Donde también es realmente barato hacerlo. Y por eso es tan importante incorporar rápidamente estas opiniones en tu code base para el futuro code, y no es importante ahora tomar un mes de tu vida para migrar todo lo que ya tienes a un nuevo estado.
Así que hablé un poco en términos abstractos sobre reglas como esta, y di este ejemplo de regla de lint, pero en realidad creo que quiero hablar de algo un poco más alto nivel que una regla de lint, que está asociada con el estilo de code y cosas así. Llegando al principio, ya sabes, acepta la falta de conocimiento. De nuevo, eres el líder de este equipo más grande, va a haber personas que son nuevas en tu equipo, va a haber personas que son más junior, van a tener algún contexto sobre esa code base que les falta, que no pueden saber o que perdieron, ya sabes, o donde no leyeron el memo, ¿verdad? Todo esto sucede. Y nosotros, como líderes de ese equipo, tenemos que aceptar que es posible que no tengan ese contexto. Y por eso es importante intentar codificar tantas de estas cosas que sabes sobre tu code base de alguna manera legible por máquina. Tengo un ejemplo aquí de lo que eso significa. Y de nuevo, esto va más allá del linting pero más hacia las opiniones de diseño de aplicación. Esta regla, de nuevo, tomada de nuestra code base interna. Y así usamos el middleware de Next.js que es una herramienta muy poderosa, ¿verdad? Se ejecuta en casi todas las solicitudes que estamos sirviendo. Y eso significa que si nuestro middleware es lento, nuestro sitio va a ser muy lento, ¿verdad? Y una forma de hacer que tu middleware sea realmente lento es obteniendo algo de algún otro servicio, ¿verdad? Por otro lado, obtener algo de algún otro servicio podría ser exactamente lo que quieres hacer, ¿verdad? Porque así es como haces cosas interesantes, como llamar a servicios. Ahora, lo que significa que, sí, a veces tienes que llamar a un servicio, pero no, a veces no es la idea correcta, ¿verdad? Y así, con un mecanismo de lista de permitidos como este, lo que puedes hacer es decir, por defecto, hacer este cambio requiere la aprobación de alguien que realmente tiene el contexto para tomar la decisión de si en este contexto esta es la idea correcta. Y esto combina la idea de una lista de permitidos externa al code junto con el mecanismo de propietarios que tenemos, donde el propietario de la lista de permitidos no es el mismo persona que está escribiendo el code, y respectivamente, puedes hacer cumplir fácilmente que tu arquitecto o, ya sabes, líder del equipo de plataforma tipo de persona para echar un segundo vistazo y validar que en este caso sí, es un uso OK. Y luego, de nuevo, esto no es como la regla de lint donde eventualmente probablemente quieres tener una code base y una code base uniforme. Aquí, simplemente te aseguras de que, sí, echamos un vistazo y esto es realmente lo que queremos hacer.
Comments