Definición
La revisión de código consiste en que otra persona lea un cambio antes de que se integre en el proyecto.
Se justifica normalmente como caza de errores, y ese es su beneficio menor. Los tres que de verdad la sostienen:
Reparte el conocimiento. Al menos dos personas entienden cada parte del sistema. Es la mejor defensa contra el «esto solo lo sabe fulano».
Mantiene un estilo común. Sin revisión, cada persona escribe a su manera y el código acaba pareciendo cinco proyectos distintos.
Obliga a explicarse. Escribir por qué has hecho algo hace que a veces descubras, solo, que no era buena idea.
Y sí, además encuentra errores — sobre todo los que las pruebas automáticas no ven: un caso límite no contemplado, una decisión que va a doler en seis meses.
Qué mira una persona y qué mira una máquina
La distinción es la que separa una revisión útil de una discusión estéril:
Lo que debe automatizarse: formato, estilo, convenciones de nombres, errores de sintaxis, pruebas que fallan. Todo eso lo comprueba una herramienta en el CI/CD. Discutir espacios en una revisión es tiempo perdido.
Lo que solo ve una persona:
- ¿Resuelve realmente el problema planteado?
- ¿Hay casos límite sin cubrir?
- ¿Se entenderá dentro de un año?
- ¿Introduce un riesgo de seguridad o de rendimiento?
- ¿Hay algo que ya existía y se está duplicando?
Ejemplo práctico
En equipos pequeños —o de una persona con ayuda externa— la revisión suele descartarse por «no da tiempo».
Lo que aprendí: lo que realmente hunde una revisión no es la falta de tiempo, es el tamaño del cambio. Un cambio de 50 líneas se revisa con atención y produce comentarios concretos. Uno de 2.000 líneas recibe un «me parece bien» y no lo ha leído nadie. La calidad de la revisión cae en picado con el tamaño, y muy rápido.
De ahí que el mayor cambio para que la revisión funcione no sea sobre la revisión: es partir el trabajo en cambios pequeños. Ver rama.
El segundo aprendizaje, sobre el tono: la revisión toca algo que la gente siente como propio, y por eso la forma importa tanto como el fondo. Tres hábitos que la vuelven llevadera:
Preguntar en vez de sentenciar. «¿Qué pasa aquí si la lista viene vacía?» funciona mucho mejor que «esto está mal».
Separar lo obligatorio de la preferencia. Marcar explícitamente qué es un problema y qué es una opinión evita discusiones interminables sobre cosas que dan igual.
Decir también lo que está bien. Una revisión que solo señala defectos desgasta.
Y una advertencia sobre convertirla en trámite: si aprobar es automático, la revisión no aporta nada y sí cuesta tiempo. Y si bloquea durante días, la gente empieza a esquivarla. El equilibrio real está en cambios pequeños revisados rápido: eso hace que sea barata de hacer y valga la pena mantenerla.
Errores comunes
- Cambios enormes que nadie lee de verdad.
- Discutir formato en vez de automatizarlo.
- Aprobar sin mirar.
- Revisiones que tardan días y bloquean el trabajo.
- Tono seco que convierte el código en algo personal.
- Revisar solo el código nuevo sin preguntarse si ya existía algo igual.
- Saltársela para lo urgente, que es justo cuando más errores se cometen.
Cuándo aplicarlo
En todo equipo de dos o más personas, y con especial cuidado en cambios que tocan dinero, permisos o datos personales.
Trabajando en solitario funciona una versión reducida y sorprendentemente eficaz: revisar tu propio cambio antes de integrarlo, leyendo el listado de diferencias completo como si lo hubiera escrito otro. Aparecen restos de depuración, cambios que sobran y decisiones que ya no recuerdas por qué tomaste.
