Una Breve Historia de Code Review (Y Qué Sigue)

Así que trabajo en una empresa de revisión de código. Sabes, comencé a trabajar para ellos hace cinco meses, Code Rabbit. Y cuando me uní a ellos, pensé, oh, ¿cómo comenzó todo este proceso de revisión de código? Porque mi recuerdo más antiguo no es revisar el código en absoluto. Como, comencé como una persona que trabajaba en una empresa de una sola persona. Yo era el único desarrollador que realmente escribía código, lo construía, lo enviaba, lo desplegaba.

Así que mi primera introducción a la revisión de código fue GitHub. Creo que la mayoría de nosotros, ¿verdad? Creo que ahí es donde empezamos. Comenzamos a ver la interfaz de usuario y ahí es donde comenzamos la colaboración. Así que pensé, ¿por qué no profundizar y ver la historia? Así que eso es lo que voy a compartir con ustedes. Así que veamos.

Entonces, la invención anterior en la revisión de código ocurrió mucho antes del 2000. Así que fue en la década de 1990. ¿Qué piensas que están haciendo estas personas? Perdiendo el tiempo. No, en realidad, están haciendo revisión de código. Así que esta fue la invención más temprana que ocurrió en 1990. Se llama inspección Fagan, nombrada así por el tipo, Fagan, que inventó este proceso. Entonces, lo que solían hacer es, ya sabes, hacen esto, los papeles. Los papeles no son más que la copia de tu código.

Así que varias personas en el equipo solían imprimir el código, revisarlo, como, solían realmente escribirlo con bolígrafo y lápiz, como, dónde esto podría salir mal. Y discutir si este código es algo que se puede enviar a producción. Así que esto es 1990. Así que el proceso era muy, ya sabes, tedioso, que consume mucho tiempo. La gente solía reunirse en persona. Así que es como planificación, visión general, preparación. Luego finalmente reunirse. Si hay un retrabajo, entonces todo el proceso ocurre de nuevo. Alguien toma la impresión, sigue adelante y luego, sí. Si no hay preguntas de seguimiento, la gente piensa que todo está bien. No hay bucle infinito. Vamos a fusionar el PR. Así que esto es lo que sucedió en la década de 1990.

Y luego llegó la era del correo electrónico o Internet en 2000. Creo que me enteré de esto cuando estaba realmente mirando algunos de los correos electrónicos de Daniel Steinberg. Creo que ese tipo es una leyenda. Así que todos saben. Y él realmente mencionó en uno de sus posts. Así que publica todo como una entrada de blog en su sitio web. Y puedes ver que realmente hay mención de correos electrónicos. Yo estaba como, ¿realmente la gente solía hacer esto? Así que en 2000, lo que sucedió es, por supuesto, llegó Internet. Y esta fue la era donde comenzó la colaboración.

Como personas que tienen acceso a Internet sentadas allí en otro país aparte de EE.UU., por supuesto. Y luego realmente pueden enviar un parche a otra persona que está sentada en otro lugar en el mundo. Así que esta es la era donde comenzaron a ocurrir reuniones sincrónicas, no en persona. La gente usa correo y herramientas de diff para compartir el código y decir, oye, esta es la unidad de PR para enviar y fusionar. Y realmente sucedió por correo electrónico. Así que fue como una gran cadena de correos electrónicos. Si ves, creo que Curl es el mejor ejemplo. Creo que todavía puedes encontrar algunas de las cadenas de correos electrónicos allí.

Y estuve en FOSDEM y había tantos proyectos que tienen décadas de antigüedad. Y también tienen esta cadena de correos en algún lugar. En 2010, creo que la mayoría de nosotros comenzamos nuestra carrera. Sí. Ahora somos viejos. Así que esta es la era de los pull requests. GitHub llegó. Ahora realmente puedes ver la diff en la UI. Así que fue el nacimiento de la revisión de código moderna. Y luego comenzó a suceder de manera sincrónica, más colaborativa. Fue una revisión más basada en la web usando GitHub o GitLab. Y nadie necesita realmente esperar hasta que el código sea aprobado, ¿verdad? Necesitas esperar hasta que el código sea aprobado. Así que ahora realmente puedes poner barandillas, que no estaban allí antes. Pero creo que todavía hay muchas revisiones en persona que estaban sucediendo con la introducción de GitHub, porque aún no era la era del trabajo remoto. El trabajo remoto no existía. Tal vez hay algunas empresas que lo han estado haciendo. GitHub lo ha estado haciendo durante años. Y en la década de 2020, el trabajo remoto y CI y CD comenzaron de manera asincrónica, global, eficiente. Todos comenzaron a trabajar desde cualquier lugar. Más verificaciones en CI. Así que ahora, de hecho, la revisión de código se volvió un poco más fácil. Tienes tu linting, tienes tus hooks en CI, CD. Realmente puedes verificar, como, qué puede salir mal. También puedes verificar el estado de la compilación antes de realmente seguir adelante y revisar el PR. Pero todavía faltaba una cosa. Los desarrolladores estaban esperando días para que se revisara su PR. Esto es algo que todavía está sucediendo, porque el número de PRs que un equipo está levantando es exponencial con la introducción de AI. Así que esto es la década de 2020. Muchas nuevas verificaciones comenzaron a llegar a GitHub y la gente comenzó a usarlas para realmente reducir su tiempo. Luego, la revisión de código se convirtió nuevamente en un cuello de botella.

Y este soy yo pidiendo a mi ingeniero senior que revise mi PR nuevamente. Así que, sí. Luego están, que es ahora, 2024, que es aumentada por IA. Ahora es asincrónica y es el futuro de la revisión de código, por el que todos estamos pasando. Así que no hay necesidad de esperar a que tu ingeniero senior revise tu código. Puedes realmente simplemente pedirle al agente de IA y revisa tu código. Te da las señales iniciales si estás, como, si es un buen código o si hay algún error. Todos los agentes de IA pueden realmente darte errores también como parte de tu código. Puedes realmente obtener retroalimentación instantánea en GitHub, IDE, CLI. Hay múltiples canales ahora aparte de solo la UI.

Y ahora más código se envía realmente con confianza. Así que simplemente omitiré esta diapositiva. Pero ¿qué sigue? Así que esto es lo que la gente ya está haciendo. Así que CLI. Así que la gente puede usar CLI para realmente revisar su código. La gente está usando IA agentic para revisar su código, donde realmente el agente puede trabajar en un bucle y revisar toda tu base de código, revisar, corregir y realmente darte el código final que no tiene comentarios. En CodeRabbit, estamos tratando de realmente cambiar cómo se ve la revisión de código. Y puede ser utilizada tanto por agentes como por humanos. Esta es una nueva UI. Estamos realmente experimentando con ella. Así que si tienes un proyecto de código abierto, adelante y pruébalo. Está disponible para todos.

Lo siento. Alguien estaba tomando una foto. Simplemente seguiré adelante y compartiré. Y puedes encontrarme después. Y te lo mostraré. También es gratis para código abierto. Y antes de que decidas no hacer revisión de código, leo mucho este poema. Puedes confiar en un Dios, pero antes de hacer tu revisión de código, no confíes en nadie ciegamente. Así que adelante y ten una herramienta de revisión de código. Así que eso es todo de mi parte. Lo siento. Sí. Eso es todo.