Una Breve Historia de la Revisión de Código (Y Qué Sigue)

Entonces, comencemos. Entonces, 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 comenzamos. 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 de Fagin, nombrada así por el tipo, Fagin, que inventó este proceso. Entonces, lo que solían hacer es, ya sabes, hacían esto en papel. 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 donde esto podría salir mal, reunirse juntos 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 consumía mucho tiempo.

La gente solía reunirse en persona. Así que es como planificación, visión general, preparación. Luego finalmente se reúnen. 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 un bucle infinito. Vamos a fusionar el PR. Así que esto es lo que sucedió en la década de 1990.

Y luego vino la era del correo electrónico o Internet, en 2000. Creo que me enteré de esto cuando realmente estaba mirando algunos de los correos electrónicos de Daniel Steinberg. Creo que ese tipo es una leyenda. Así que todos conocen a Carl. 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 una mención de correos electrónicos.

Yo estaba como, ¿en serio? ¿La gente solía hacer esto? Así que en 2000, lo que sucedió es que, 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.

Las personas usaban correo y herramientas de diff para compartir el código y decir, hey, esta es la unidad de PR para push y merge. Y realmente sucedía por correo electrónico. Así que era como un gran rastro de correos. Si ves, creo que Carl es el mejor ejemplo. Creo que aún puedes encontrar algunos de los rastros de correos allí.

Y yo estaba en FOSDEM. Y había tantos proyectos que tienen como décadas de antigüedad. Y también tienen este rastro de correos en algún lugar. Luego en 2010, aquí es donde 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 el diff en la UI. Así que fue el nacimiento de la revisión de código moderna.

Y luego comenzó a suceder de manera asincró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. Lo siento, necesitas esperar hasta que el código sea aprobado. Así que ahora realmente puedes poner guardrails, que no estaban 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 estaba allí. Tal vez hay algunas empresas que lo han estado haciendo.

GitHub has been doing it for years. Y luego en 2020, el trabajo remoto y CICD, ahora realmente comenzó asincrónico, global, eficiente. Todos comenzaron a trabajar desde cualquier lugar. Más chequeos en CI. Así que ahora realmente 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 qué puede salir mal. También puedes verificar el estado de la build antes de que realmente procedas a revisar el PR. Pero todavía faltaba una cosa. Los desarrolladores estaban esperando días para que sus PR fueran revisados. Esto es algo que todavía está sucediendo. Porque el número de PRs que un equipo está generando es exponencial, con la introducción de AI. Así que esto es la década de 2020, muchos nuevos chequeos comenzaron a llegar a GitHub, y la gente comenzó a usarlos para realmente reducir su tiempo.

Luego la revisión de código se convirtió en un cuello de botella nuevamente. Esto soy yo pidiendo a mi ingeniero senior que revise mi PR nuevamente. Así que sí. Luego la era que es ahora, 2024, que es aumentada por AI, 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. Realmente puedes simplemente pedirle a un agente 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 realmente pueden darte errores así como parte de tu código. Realmente puedes obtener retroalimentación instantánea en GitHub, ID, CLI, ahora hay múltiples canales aparte de solo la UI. Y ahora más código realmente se envía con confianza.

Así que simplemente omitiré la diapositiva, pero ¿qué sigue? Así que esto es lo que la gente ya está haciendo. Así que CLI, así que la gente puede ir y usar CLI para realmente revisar su código. La gente está usando AI agentic para revisar su código donde, realmente, el agente puede trabajar en un bucle y revisar todo tu código base, 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 usado tanto por agentes como por humanos. Esta es nuestra nueva UI. Realmente estamos 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. Te lo mostraré. También es gratuito para código abierto.

Y antes de que decidas no hacer revisión de código, leo mucho este poema. Puedes confiar en 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. Gracias.