El Futuro Stack de la Revisión de Código

Así que, hola, soy Gabriel y hoy quiero presentarte a una persona que todos conocemos porque existen en cualquier equipo, y esta es la persona molesta a la que nadie quiere dejar hacer una revisión de código, ¿verdad? La revisión de código siempre se ve mejor, tienen comentarios como 'No lo haría así', y luego se vuelve más personal, pero está bien porque el jefe les dice que interrumpe el trabajo, y luego se vuelve más largo y tiene todos esos comentarios que no significan nada y solo arruinan tu mundo, ¿verdad? Así es como funcionan las revisiones de código, y luego aprendes a hacer el LGTM. Parece bien para mí, pero el problema siempre es ponerlo como un problema. Así que tienes que lidiar con 20 comentarios como LGTM.

Entiendo tu problema porque también experimenté a una persona así en mi equipo. Y después de seis años conviviendo con esa persona a la que hago todo lo posible para evitar que revise mi código, comencé a reflexionar. Y eché un vistazo a cómo ha cambiado el stack de software a lo largo de los años. Comencé a trabajar en el mismo lugar en 2016. Solíamos tener un servidor monolítico en Java que resolvíamos como una máquina virtual junto con Oracle database. Hacíamos una escala vertical, es decir, instalábamos la misma imagen 50 veces y lanzábamos el software cada seis meses.

Luego nos mudamos a algunos microservicios en 2018. Creamos una puerta de enlace para cargar la pieza de software balanceada en lugar de un balanceador de carga de hardware. Avanzamos aún más en 2020. Teníamos microservicios en varios lenguajes. Estábamos completamente en la cloud. Hacíamos una escala horizontal y así sucesivamente. Ahora gastamos en microservicios cada semana. Enviamos nuestro software en minutos, pero las revisiones de código siguen siendo las mismas. Durante los últimos 20 años, las herramientas han permanecido iguales. Los comentarios siguen siendo los mismos. La forma en que las personas hacen revisiones de código, las técnicas que te dicen que debes hacer en las revisiones de código siguen siendo las mismas.

Y todo eso me parece extraño. Y cada vez que algo me parece extraño, recurro a Twitter. Sé que no es lo correcto, ir a Twitter y pedir opiniones a la gente. Pero así soy yo. Hice esa pregunta y realmente te recomiendo, hay un enlace a continuación para ver el tweet en sí. Realmente te recomiendo que vayas a ver qué respondió la gente, pero también echemos un vistazo aquí y veamos algunas palabras. Así que veamos aquí. Por ejemplo, Karen dijo que se trata de mejorar y eso es correcto. Queremos mejorar como desarrolladores. Queremos que nuestro producto mejore. Y por eso hacemos revisiones de código. Boris habla sobre la mentoría y llegaremos a eso más adelante. Vemos a Lia hablar sobre calidad y así sucesivamente.

Así que recojo todo y luego empiezo a pensar qué podemos hacer para redefinir. Redefinir la revisión de código, encontrar la manera de progresar de la misma forma en que progresamos con el stack de software también en el proceso de revisión de código.

Mi nombre es Gabriel y soy el director de Deverell en Permit.io. Permit.io es una startup que resolvió un problema crítico en el control de acceso. Desarrollamos un sistema que permitía a los desarrolladores implementar autorización en su sistema en poco tiempo. Con solo unas pocas líneas de código puedes obtener todo un sistema de autorización en tu aplicación.

Y como parte de mi trabajo, siempre estoy observando a los desarrolladores, ¿verdad? Estoy viendo cómo trabajan los desarrolladores, estoy desarrollando herramientas para desarrolladores. Y me pregunto, ¿qué ha cambiado? Si miramos el stack de software desde la perspectiva de la revisión de código, ¿qué ha cambiado en todos estos años? Entonces, lo primero es que ahora tenemos mucho más que proteger. Si miramos, por ejemplo, la prevención de errores en 2015, en 2010, necesitábamos prevenir errores en el código de la aplicación. Teníamos una aplicación y esta aplicación podía tener errores potenciales en la lógica del propio código y queríamos protegerla. Pero hoy en día tenemos mucho más que proteger porque también gestionamos la implementación desde el mismo código. También tenemos un problema de performance simplemente porque tenemos dependencias entre servicios. Gestionamos muchas cosas a través del código y tenemos mucho más que proteger cuando inspeccionamos la calidad.

Y otra cosa que también ha cambiado. Ahora somos políglotas. Ya no soy un desarrollador de JavaScript. Soy un desarrollador full stack. Así es. Mi lenguaje materno es JavaScript, pero programo para Node.js. Programo para D-Nodes. También puedo programar para web assembly, para navegadores, para aplicaciones nativas, para aplicaciones de escritorio. Ya no programamos en un solo lenguaje. Desarrollamos software. Y cuanto más avanzamos, y otro cambio, ahora la IA nos va a reemplazar, ¿verdad? Como desarrolladores, nuestro trabajo hoy en día es simplemente comprender la plataforma, comprender la aplicación, los dominios para los que estamos desarrollando software. Programo con Copilot. Ya no necesito ser experto en JavaScript. Debo ser experto en el software que estoy tratando de entregar. De esta manera puedo obtener aplicaciones mucho mejores. Y además, si observamos el ciclo de vida del desarrollo de software, todo está automatizado. Hoy, cuando quiero implementar una nueva característica en producción, no hago nada más que abrir una solicitud de extracción.

Después de eso, tengo flujos de GitOps, tengo CI y CD automatizados. Todo sucedió de alguna manera y mi software acaba de ser desplegado. Debemos tener en cuenta todos estos cambios en la revisión de código, ¿verdad? Pero también hay cosas que no cambian. Por ejemplo, la necesidad de la sabiduría humana. Todavía necesitamos el pensamiento único del cerebro humano sobre cómo entregamos la aplicación. Es cierto que las computadoras están ejecutando nuestras aplicaciones, pero otras personas necesitarán leerlo, otras personas necesitarán gestionarlo, otras personas necesitarán tomar decisiones comerciales. Y esta sabiduría humana, esta conexión entre las personas no ha cambiado. Este es un principio fundamental que queremos mantener en el futuro stack de revisión de código. Y otra cosa que nunca cambió es que las revisiones de código son enemigas de la velocidad. Si queremos ver, si echamos un vistazo a cualquier tablero Kanban o de cualquier manera en que gestionemos nuestro mundo, siempre veremos que el obstáculo más grande que detiene nuestro software del progreso es la forma en que hacemos las revisiones. Tenemos una tarea manual que se interpone en medio de todas las tareas automatizadas y ralentiza nuestra velocidad.

Entonces ahora necesitamos definir cuál es el nuevo stack de revisión de código. Veamos las revisiones de código y construyamos juntos un nuevo stack. He creado una lista aquí, pero creo que el aspecto más importante de esta lista es el número ocho, lo que aportas como el nuevo stack de revisión de código, porque cada equipo hoy en día piensa diferente, cada equipo funciona en diferentes entornos, cada equipo gestiona los despliegues de manera diferente, cada equipo escribe en múltiples lenguajes para múltiples plataformas. Así que solo puse mi stack principal de equipo, pero tú también puedes agregar tu stack. Y ese es el punto de la charla. Quiero que comencemos en el nuevo código, el nuevo stack de revisión de código como algo que implementamos en nuestras necesidades de software. No solo un estándar general que necesitamos para entregar software, sino un estándar que se ajuste a nuestro software.

Entonces veamos lo que he enumerado aquí. Quiero aumentar la velocidad utilizando la revisión de código. No quiero que me frene. Quiero que me ayude a mejorar la velocidad. Quiero que el código sea más legible porque los humanos leen el código, aunque las máquinas lo ejecuten. Quiero obtener una mejor seguridad. Ese es un aspecto crítico que se puede lograr a través de la revisión de código. Y también quiero obtener un mejor rendimiento. Y quiero mantener un código limpio, pero el significado general de código limpio. Por ejemplo, quiero mantener los principios sólidos en mi código, y quiero fomentar la colaboración con mi equipo. Y quiero asegurarme de que el código, tanto en los aspectos micro como macro, sea realmente escalable.

Al observar esta lista, he creado una lista de las mejores prácticas que podemos obtener para la revisión de código. La primera es comprender las responsabilidades de la revisión de código. Tenemos tres puntos cuando analizamos cada pieza de software. Primero está el código. Esta es la parte micro de nuestro software. El código en sí se puede verificar con LinkedIn. Se puede verificar con análisis estático. Todos ellos verificarán que cada función, cada fragmento de código, cada pequeño fragmento de código que escribimos cumpla con los estándares. También tenemos las pruebas en nuestra aplicación. El aspecto más amplio de nuestro software. Y luego la plataforma en la que lo ejecutamos. Y luego podemos utilizar herramientas para prevenir errores. Todas estas responsabilidades juntas son la razón de la revisión de código.

Para cada uno de ellos por separado, podemos utilizar herramientas automáticas. Puedo usar ESLint para mantener todo limpio en mi código. Pero cuando el código en sí se superpone con nuestra arquitectura de aplicación y la plataforma en la que se ejecuta, es ahí donde necesitamos un ojo humano. Un ojo humano que comprenda el panorama general y piense en las cosas importantes.

Entonces, la primera mejor práctica cuando hago una revisión de código es conocer las responsabilidades. Y luego, como líder técnico, quiero que solo el 20% de la responsabilidad humana recaiga en la revisión de código. Piénsalo como un principio de Pareto. Las consecuencias de los errores que encontraré provendrán principalmente de la revisión automática, ¿verdad? De las pruebas, de todo eso. Pero el humano encontrará cosas importantes, pero solo el 20% del esfuerzo. Quiero que el humano invierta su tiempo en escribir código. La revisión es importante, pero solo en el 20% que realmente importa.

También quiero obtener una mejor línea de tiempo para la revisión de código. No quiero que las personas comiencen a revisar el código en el momento en que se publique. Una de las razones de esto es el cambio de contexto. Cuando estoy revisando código, no estoy escribiendo código. Eso me desconecta de la tarea en la que estoy trabajando actualmente. Quiero establecer un flujo de trabajo en el que las personas ingresen a la fase de revisión solo después de asegurarme de que la solicitud de extracción cumpla con todos los estándares. Primero quiero priorizar la solicitud de extracción. Tal vez sea solo una pequeña corrección de CSS. Y pronto hablaremos sobre herramientas que pueden indicarte si es solo una pequeña corrección de CSS, si no, tal vez no necesite una revisión de código. Quiero hacer el linting correcto y luego el análisis estático desde la perspectiva de seguridad y también desde la perspectiva del código. Y solo después de una prueba unitaria, quiero que los ojos humanos lo revisen porque ahora puedo asegurarme de que el código sea confiable para llegar a producción. Luego me ocuparé de las pruebas de extremo a extremo, que llevan tiempo. Pero lo que sé ahora es que una persona está perdiendo su tiempo en una revisión solo después de asegurarse de que sea confiable.

Luego está una mentalidad que queremos fomentar. La pregunta es, ¿puedo automatizarlo? Esta es una pregunta que me hago por cada comentario que hago en una revisión de código. ¿Puedo automatizarlo para que la próxima vez el desarrollador lo encuentre antes que yo? No es difícil lograrlo porque tenemos una herramienta muy cómoda para el linting de JavaScript, ESLint. Podemos escribir reglas personalizadas para ESLint. Esto es en realidad una cultura que queremos implementar en la organización. Queremos que las personas entiendan que ESLint debe funcionar para ellos.

Si ven que se atasca en el trabajo o que algunos comentarios repetitivos vuelven una y otra vez en las revisiones de código, deberíamos escribir una regla automatizada que lo encuentre la próxima vez. Y esto en realidad no es tan difícil. Veamos qué tan fácil puedo escribir un fragmento de código que verifique problemas en mi código.

Entonces, aquí, por ejemplo, creé un complemento personalizado de ESLint. Y mi problema aquí es esta función. Alejémonos por un momento de las mejores prácticas y entendamos qué está sucediendo aquí. New permit es en realidad nuestro SDK. Y aquí hay alguna configuración para el SDK. Uno de ellos es el punto de decisión, un servidor al que el software debe ir. Y aquí podemos ver un local host. Pero las mejores prácticas indican que no se debe poner local host aquí. Después de que me di cuenta de que estaba comentando a alguien que no deberíamos entregar código con local host, puedo automatizarlo. Puedo crear un complemento de ESLint aquí que diga que no se permite usar local host. Y eso es bastante fácil porque lo que necesitas es comprender cómo se ve el código. Y puedes leer las instrucciones, no estamos aquí para aprender cómo escribir reglas de ESLint. Pero puedes ver aquí que si el valor de PDP es local host, estoy devolviendo un error y podemos ver que funciona aquí. Entonces, si vas, por ejemplo, a la terminal y ejecuto ESLint en mi programa, puedo ver que obtengo un error. Y, por supuesto, si tus usuarios trabajan con el IDE correcto, lo recibirán justo a tiempo. Y esta es una mentalidad que debemos fomentar. Si tienes un comentario que no se puede automatizar, piénsalo de nuevo. Tal vez sea solo tu opinión. Tal vez sea algo que no debas incluir. Nuestro código ahora es diverso. La legibilidad se basa en sentimientos subjetivos. Tenemos principios que seguir, pero nadie debe rastrear tus preferencias personales. Continúa con las mejores prácticas. Queremos ser un equipo. Queremos ser buenas personas cuando hacemos revisiones de código.

Entonces, primero quiero tener una conversación en lugar de dar instrucciones. En lugar de decirles a las personas que no deben hacerlo de esta manera, tal vez pregúntales por qué.

O, creo que debería hacerse mejor, pero estaré encantado de recibir una explicación de por qué lo hiciste. Porque probablemente si lo hiciste, hiciste algo bien. Tal vez al final no esté de acuerdo con eso, pero así es como nosotros, como personas, nos comunicamos. Y queremos pensar en equipo en lugar de individualmente. No pienses en alguien del equipo que está haciendo el trabajo solo y que necesitamos afectarlos de alguna manera. Somos un equipo, estamos trabajando juntos. Todos somos responsables de nuestro software. Y queremos fomentar la colaboración en lugar de la competencia. No competimos entre nosotros, somos miembros del equipo que debemos trabajar juntos para hacer lo mejor y simplemente crear un mejor software.

Y queremos evitar ser minuciosos. Si veo un comentario minucioso en una revisión de código, eso significa que alguien está tratando de perder mi tiempo. No me importa ser minucioso, podrías iniciar una conversación sobre tu minuciosidad y luego puedo responder y tal vez al final esté de acuerdo contigo. Y también mantengámoslo simple. Una de las cosas que veo en las revisiones de código e incluso puedes verlo en un proyecto de código abierto grande es que las personas intentan complicar las cosas, las personas intentan hacer el mensaje complicado, las personas intentan hacer complicada la revisión de código. Seamos personas decentes cuando hagamos una revisión de código, seamos mejores personas.

Y también queremos tratar la revisión de código como una característica del producto, es decir, queremos analizarlas. Cuando hacemos una retrospectiva de nuestro sprint y vemos por qué una tarea tardó tanto, veamos también cuánto tiempo la revisión de código estuvo atascada en una fase de revisión. Es fácil obtener esa información de la API de GitHub y en realidad es una métrica muy importante. Si podemos ver un patrón en las revisiones de código que se atascan una y otra vez, tal vez eso signifique que no tenemos suficiente experiencia en el equipo, tal vez signifique que algunas personas deberían hacer otras tareas. Podríamos utilizar la información y las métricas que obtenemos de, digamos, las herramientas de revisión de código de GitHub y obtener un mejor producto para ellos. Y por último pero no menos importante está la gestión de prioridades. Hoy en día existen herramientas que pueden ayudarte a gestionar la prioridad de la revisión de código. Como mencioné, por ejemplo, GitStream analiza las revisiones de código en sí mismas y determina si una revisión de código es algo que realmente debería tener prioridad sobre otras tareas o si puede ir directamente a la integración y despliegue continuos y pasar a producción. A veces sí, a veces sin la intervención de los ojos humanos, los ojos humanos, como dijimos, son importantes, pero debemos usarlos sabiamente. Estoy seguro de que también tienes best practices para tus revisiones de código. Pero recordemos, estamos construyendo nuestro software. Estamos creando el nuevo proceso de revisión de código. Descubre cuál es tu proceso para la revisión de código. Construye tus best practices, crea un mejor producto y desarrolladores más felices. Muchas gracias.