Revisión de código
Que otra persona lea un cambio de código antes de que pase a ser parte del producto.
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.
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)
- Revisión de código en Wikipedia
- Guía de code review de Google (en inglés)