# Revisión de código

> Que otra persona lea un cambio de código antes de que pase a ser parte del producto.

- Nivel: Intermedio
- Temas: Software
- URL: https://tidbit.legios.com.ar/es/code-review/
- En inglés: [Code review](https://tidbit.legios.com.ar/code-review/)

La **revisión de código** (code review) es la práctica de que al menos otro developer lea y apruebe un cambio antes de que se integre al código principal. Hoy casi siempre pasa a través de un **pull request** (GitLab lo llama **merge request**): quien escribió el cambio lo sube a una rama aparte, abre una página que muestra exactamente qué líneas se agregaron y cuáles se sacaron, y explica por qué.

Quienes revisan leen el diff y dejan comentarios en líneas puntuales: "esto se rompe si la lista está vacía", "ya hay una función para esto", "¿le ponemos un nombre más claro?". El autor responde o actualiza el cambio, y la charla sigue hasta que alguien lo **aprueba**. Mientras tanto, en el mismo pull request corren chequeos automáticos, desde tests hasta reglas de formato, para que las personas se concentren en lo que las máquinas no pueden juzgar.

Atrapa bugs, pero la investigación y la experiencia sugieren que su valor más grande es repartir conocimiento: más de una persona entiende cada parte del sistema, quien recién llega aprende las convenciones del código y las decisiones quedan escritas al lado del código. Funciona mejor con cambios chicos, que se revisan más rápido y con más cuidado que los enormes, y con un tono amable y concreto, porque se revisa el código, no a la persona. Hoy muchas veces hay herramientas de IA que dejan una primera ronda de comentarios automáticos.

## Una analogía

Como pedirle a un colega que lea un mail importante antes de mandárselo a un cliente. Encuentra errores de tipeo, pero más seguido te dice "esta parte se puede malinterpretar", y la próxima vez lo escribís mejor solo.

## Para quedarse

- Un pull request muestra el cambio exacto y junta toda la discusión sobre él.
- Normalmente hace falta al menos una aprobación antes de integrar.
- Reparte conocimiento tanto como atrapa bugs.
- Los cambios chicos reciben mejores revisiones que los grandes.

## Para seguir leyendo

- [Acerca de las revisiones de pull requests (documentación de GitHub)](https://docs.github.com/es/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/about-pull-request-reviews)
- [Revisión de código en Wikipedia](https://es.wikipedia.org/wiki/Revisi%C3%B3n_de_c%C3%B3digo)
- [Guía de code review de Google (en inglés)](https://google.github.io/eng-practices/review/)

## Términos relacionados

- [Bug](https://tidbit.legios.com.ar/es/bug/): Un error en un software que hace que se comporte distinto de lo que se buscaba.
- [Inteligencia artificial](https://tidbit.legios.com.ar/es/artificial-intelligence/): Lograr que las computadoras hagan cosas que hasta hace poco solo hacía la gente.