Un code review es, en esencia, que otra persona del equipo revise un cambio de código antes de que se integre al proyecto. Suena simple, pero es una de las prácticas de ingeniería de software mejor documentadas que existen —Google mantiene públicamente todo su manual interno al respecto— precisamente porque hacerlo bien no es tan obvio como parece, y hacerlo mal genera fricción sin aportar la mitad del valor que podría.
No es (solo) buscar bugs
La razón más citada para hacer code review es detectar errores antes de que lleguen a producción, y es real, pero no es la única ni siquiera la principal según la documentación de Google al respecto: el objetivo de fondo es que la calidad general del código del equipo mejore con el tiempo, no solo que ese cambio concreto esté libre de bugs. Eso incluye compartir conocimiento del sistema entre quien escribe y quien revisa, y mantener cierta consistencia en cómo se resuelven problemas parecidos en distintas partes del proyecto.
Qué mirar primero (y qué dejar para el final)
Es tentador empezar señalando espacios, comas o el nombre de una variable, pero esos comentarios son los que menos valor aportan por línea de tiempo invertida. La guía de Google propone un orden de prioridad que funciona bien en la práctica: primero el diseño general del cambio —¿tiene sentido esta solución para el problema?—, después si realmente hace lo que dice hacer, después la complejidad —¿alguien que no escribió esto podría entenderlo sin ayuda?—, después si tiene pruebas adecuadas, y solo al final cuestiones de nombres y estilo, que además muchas veces ya resuelve un linter automático sin necesitar ojos humanos.
Cómo dar feedback sin generar fricción
La forma del comentario importa casi tanto como el contenido. Separar explícitamente lo que bloquea la aprobación de lo que es una sugerencia opcional evita que quien recibe la revisión tenga que adivinar qué es obligatorio y qué es gusto personal de quien revisa. Explicar el porqué de un comentario ("esto puede fallar si la lista llega vacía") en vez de solo el qué ("cambia esto") no solo suena mejor: le da a la otra persona la información necesaria para decidir si aplicar el cambio tal cual o resolver el problema de otra forma igual de válida.
Y un matiz que se pasa por alto con frecuencia: no bloquear la aprobación por preferencias personales cuando el código es correcto y sigue las convenciones ya acordadas por el equipo. Hay más de una forma razonable de resolver la mayoría de los problemas, y no todas tienen que coincidir con la que habría elegido quien revisa.
La responsabilidad no es solo de quien revisa
Un cambio (pull request) pequeño y autocontenido —que resuelve una sola cosa, con una descripción clara de qué hace y por qué— se revisa más rápido y con más atención que uno de 800 líneas que mezcla tres cambios distintos. Cuanto más grande el cambio, más probable que la revisión se convierta en un vistazo superficial en vez de una lectura real, precisamente cuando más falta hace lo contrario.
Cuándo aprobar y cuándo no
La pregunta que de verdad ayuda a decidir no es "¿lo habría escrito yo exactamente así?", sino "¿este cambio deja el código del proyecto mejor de lo que estaba, aunque no sea perfecto?". Bloquear solo por problemas reales —de diseño, de pruebas insuficientes, de algo que puede romperse en un caso real— y dejar pasar las diferencias de estilo que no afectan a la calidad evita que el code review se convierta en un cuello de botella que todo el equipo termina evitando.
Fuentes:
Comentarios (0)
Deja un comentario
No hay comentarios aún. ¡Sé el primero en comentar!