Cómo hacer un buen code review: checklist para senior devs

Un code review no es un examen para demostrar quién sabe más: es un mecanismo de calidad, difusión de conocimiento y alineación con el producto. Como senior, tu rol suele incluir modelar cómo se da feedback — riguroso en lo importante, proporcionado en lo accesorio, y siempre orientado a que el equipo entregue valor con menos sorpresas en producción.

Abajo tienes un repaso pensado para revisores con experiencia, con reglas de oro al final y enlaces a documentación oficial útil.

Antes de mirar el diff: conoce las reglas del juego

Lo primero no es el código: es el contrato implícito de tu equipo sobre cómo se escribe software y cómo se ve el producto.

• Estilo y patrones de código: ¿el equipo prefiere enum, constantes nombradas u objetos literales para representar estados? ¿Hay guías de estructura de carpetas o límites entre módulos? Si el PR contradice esas decisiones sin justificación, es señal de conversación — no de vergüenza para el autor.
• Diseño y UI: si el proyecto usa tokens CSS o un design system, los colores, espaciados y tipografías deben venir de ahí. Si ves un color "suelto" o una fuente que no está en el catálogo, escala la inquietud: a veces basta un comentario sugiriendo el token correcto; otras conviene hablar con diseño antes de bloquear o aprobar a ciegas.
• Accesibilidad e i18n: nombres de componentes, textos visibles y navegación por teclado suelen ser parte del estándar del equipo. Revísalos con la misma seriedad que la lógica de negocio.

Sin este marco, terminas opinando desde preferencias personales. Con él, tus comentarios enseñan el sistema en el que todos trabajan.

Empieza por el contexto (negocio + intención)

Sin contexto, no hay review de verdad. Lee primero la descripción del PR, el ticket o la issue enlazada, y pregúntate si en seis meses el historial de git seguirá contando la historia: el porqué debería quedar en el propio PR, no solo en Jira u otra herramienta externa.

Piensa en el contexto de negocio: muchos cambios afectan procesos o flujos de usuario. El review no es solo "¿compila?", sino "¿tiene sentido este flujo para el negocio y el usuario?". Si el contexto no está claro, tu primer feedback puede ser pedir esa claridad antes de profundizar en líneas sueltas.

Además, reserva tiempo real para revisar. Si el calendario no deja espacio, la org termina con el clásico "LGTM" sin mirar — y eso es un problema de proceso, no solo de individuos.

Cómo recorrer el PR sin ahogarte

La documentación de GitHub sobre revisar cambios recomienda un enfoque sistemático:

• Revisar archivo a archivo, dejar comentarios en línea concretos y marcar archivos como Viewed para no perder el hilo.
• Entender el propósito usando la barra lateral de issues o, si tu equipo lo permite, herramientas de IA para resumir la intención — siempre verificando tú el resultado.
• Si el PR toca dependencias, usar la revisión enriquecida de manifests y lockfiles, sin confiar solo en el diff textual.

Un bloc de notas durante la lectura ayuda: anota dudas del tipo "¿qué pasa si…?" o "¿cómo encaja esto con Y?". Al final, lo que quede sin resolver se convierte en comentarios útiles.

Dónde poner la lupa (especialmente como senior)

Límites del módulo y API pública

Acertar los límites — lo que otros módulos consumen: APIs HTTP, hooks, servicios exportados — suele importar más que pulir cada detalle interno. Pregúntate: ¿es fácil de usar para quien llegue nuevo? ¿El tipado podría reforzarse con el sistema de tipos en lugar de depender de "que nadie se equivoque"?

Cambios difíciles de revertir

Prioriza lo que deja huella: seguridad, permisos, migraciones de datos, contratos de API, semántica de errores. Ahí un "detalle" no es cosmético.

Pruebas

No confundas "hay tests" con "el comportamiento es el correcto". Los tests deben probar el comportamiento deseado, no solo hacer pasar assertions triviales. Revisa nombres de tests, caminos felices y casos críticos de error. Si el PR es grande o mezcla refactors con features, pide dividirlo — el coste de review suele crecer más rápido que el tamaño del cambio.

Convenciones y "limpieza"

Las convenciones importan, pero son la capa más superficial si el flujo de negocio o el diseño están mal. Ordena tus comentarios: primero corrección de flujo y diseño, luego nombres y estilo.

Ajusta el nivel de escrutinio

El rigor depende de quién escribe y qué módulo toca. Un mantenedor habitual puede recibir sugerencias en tono diferente al de alguien nuevo en el área. Un módulo crítico merece más tiempo que un experimento que aún va a mutar. También importa si el autor suele cumplir los "lo arreglo en el siguiente PR" — eso cambia cuánto exiges que se resuelva en este.

ROI de cada comentario

Antes de publicar, pregúntate: ¿este cambio que pido vale el coste de redeploy, re-testeo o re-trabajo? Si tu observación dispara una refactorización grande, puede ser mejor un ticket aparte o una conversación sincrónica con el autor o el tech lead, en lugar de una cadena interminable en GitHub.

Tono: claro, útil y respetuoso

El objetivo es ayudar, no exhibir superioridad.

• Habla del código o del diseño, no de la persona: "Aquí se podría..." en lugar de "Tú siempre...".
• Sé específico: qué cambiar, por qué (norma del equipo, riesgo, legibilidad) y, si puedes, un ejemplo o sugerencia concreta.
• Si el PR es muy problemático, a veces una llamada corta ahorra más que veinte comentarios seguidos.
• Aprueba con comentarios ("LGTM con sugerencias") cuando confías en que el autor cerrará los detalles menores sin otra ronda.

IA como copiloto, no como oráculo

Herramientas como GitHub Copilot o similares pueden ayudarte a resumir diffs largos, proponer redacción de comentarios o detectar patrones repetidos — siempre revisando las sugerencias y alineando con las políticas internas de tu empresa. La IA acelera la lectura; la responsabilidad del review sigue siendo tuya.

Etiqueta a quien aporte criterio

Si el debate es de dominio específico — facturación, seguridad, rendimiento de base de datos, accesibilidad avanzada — no tienes que resolverlo solo. Menciona en el PR a alguien con criterio en esa área. Eso reduce cuellos de botella, mejora la calidad del debate y refuerza la idea de que el código es del equipo.

Reglas de oro

1. Contexto antes que líneas: negocio, ticket y descripción claros.
2. Estándares del equipo antes que gustos personales: tokens, tipografía, patrones acordados.
3. Límites y riesgos antes que nitpicks: API, datos, seguridad.
4. ROI consciente: no todo merece bloquear el merge.
5. Comentarios accionables y respetuosos: el tono es parte de la entrega.
6. Divide y vencerás: PRs enormes o mezclados piden split o guía de revisión.
7. Aprueba cuando toca: el review también es desbloquear con confianza informada.

Última pasada antes de publicar

Antes de enviar el review, detente un momento. ¿El qué y el porqué quedan claros en el PR o en el ticket, o todavía merece una ronda de contexto antes de entrar al diff? ¿El flujo de negocio me cierra? Si no, ¿ya dejé dicho qué parte me preocupa y por qué?

En lo técnico, foco en las superficies que otros van a consumir — APIs, contratos, tipos — y en lo que sería caro deshacer. Si los tests no cubren lo que más dolería romper, prefiero decirlo con prioridad explícita. En pantalla: que tokens, tipografía y convenciones del sistema cuadren; si algo desentona con diseño, o lo comento con criterio o escalo con quien corresponda.

Sobre el feedback: cada comentario debe tener un punto claro y, cuando se pueda, una pista de siguiente paso. El tono debe ayudar a quien lo lea. Si el tema escapa de mi área, mejor traer a alguien que lleve horas en ese barro. Y al cerrar, que la decisión — aprobar, sugerencias menores o pedir cambios de verdad — tenga sentido con el riesgo y con cómo suele responder el autor.

---

Documentación y guías de referencia

• Revisar cambios propuestos en un pull request — GitHub Docs
• Code Review — Engineering Practices — Google Engineering