Cómo dar y recibir code reviews sin dramas
Las code reviews son una herramienta clave para mejorar la calidad del código y fomentar el aprendizaje colectivo. Sin embargo, si no se gestionan bien pueden convertirse en una fuente de tensiones. En este artículo te propongo una serie de buenas prácticas que te ayudarán a dar y recibir feedback sin dramas, tanto si eres senior como si estás dando tus primeros pasos como desarrollador.
1. Prepara el contexto antes de abrir el PR
Antes de lanzar un pull request, dedica unos minutos a describir el objetivo del cambio, los tickets relacionados y cualquier decisión de arquitectura que hayas tomado. Un buen README del PR puede ser tan breve como:
## Qué hace este PR
- Implementa la nueva barra de búsqueda.
- Resuelve el bug #1234 (cierre de modal).
## Cambios principales
- Nuevo componente useDebounce.
- Tests unitarios añadidos.
## Qué revisar
- Lógica de debounce.
- Accesibilidad del input.
Con esta información, el revisor sabe qué buscar y no pierde tiempo adivinando la intención.
2. Sé específico y objetivo al comentar
Los comentarios genéricos como "no me gusta" o "mejorar esto" no aportan valor. Mejor sigue la regla de "qué, por qué y cómo":
- Qué: señala la línea o fragmento concreto.
- Por qué: explica la razón (rendimiento, legibilidad, consistencia).
- Cómo: sugiere una solución o referencia a una guía interna.
Ejemplo:
// Comentario poco útil
// TODO: mejorar esto
// Comentario útil
// La condición `if (items.length)` puede ser confusa cuando `items` es undefined.
// Propongo usar `Array.isArray(items) && items.length > 0` para evitar errores en tiempo de ejecución.
3. Limita el número de comentarios por PR
Un PR con demasiados apuntes puede resultar abrumador. Agrupa observaciones similares y prioriza los bloques críticos (bugs, seguridad, rendimiento). Si algo es "cosmético" o "estilo", puedes moverlo a una tarea de refactorización futura.
4. Usa la herramienta a tu favor
La mayoría de los sistemas (GitHub, GitLab, Bitbucket) permiten suggested changes. En lugar de escribir un comentario largo, sugiere el cambio directamente:
// Comentario
// Cambia la variable a `const`.
// Sugerencia
@@
- let total = 0;
+ const total = 0;
Esto acelera la iteración y evita malentendidos.
5. Recibe feedback con mentalidad de aprendizaje
Cuando te lleguen comentarios, evita la reacción defensiva. Pregunta si algo no queda claro y agradece la ayuda. Si el comentario es ambiguo, responde con una pregunta como "¿Podrías explicar por qué prefieres X en lugar de Y?". De esta forma conviertes una posible crítica en una conversación constructiva.
6. Cierra el ciclo: merge y seguimiento
Una vez aprobados los cambios, haz el merge siguiendo la estrategia del proyecto (squash, rebase, merge commit). Después, monitoriza si el código introduce errores en producción. Si surge algún problema, abre un nuevo PR explicando la causa y la solución; el proceso de revisión se vuelve iterativo y mejora continuamente.
7. Cultura de equipo
Fomenta una cultura donde el code review se vea como una oportunidad de crecimiento, no como una auditoría. Algunas ideas:
- Organiza sesiones de "review rotativo" para que todos revisen diferentes áreas.
- Define una guía de estilo y un checklist de revisión compartido.
- Celebrar los PRs que introducen buenas prácticas o refactorizaciones importantes.
Con estos hábitos, las revisiones dejan de ser un obstáculo y pasan a ser un motor de calidad y aprendizaje.
En resumen, la clave está en la claridad, la especificidad y la empatía. Si todos los involucrados adoptan estas pequeñas normas, el proceso de revisión será rápido, efectivo y, sobre todo, libre de dramas.