Code Review como Ingeniero Senior: Mas Alla de Encontrar Bugs

Antes pensaba que un buen revisor de codigo era alguien que atrapaba la mayor cantidad de bugs. Despues de varios anos revisando codigo a diario en equipos distribuidos, he llegado a pensar que ese enfoque subestima para que sirve realmente una revision: los bugs que atrapa una revision son lo menos valioso que produce, porque los bugs tambien los atrapan las pruebas, los ambientes de staging y el monitoreo. Lo que una revision aporta de forma unica es feedback de diseno y contexto compartido, y ninguno de los dos existe en ninguna otra parte del proceso de desarrollo.

Una revision que empieza con preguntas de diseno - pertenece este cambio a este modulo, introduce un acoplamiento del que el equipo se arrepentira en seis meses, deja el codigo mas facil o mas dificil de cambiar la proxima vez - atrapa problemas que ninguna suite de pruebas puede atrapar, porque las pruebas verifican comportamiento, no arquitectura. Trato de separar explicitamente el feedback entre lo que debe cambiar antes de mergear y lo que es una sugerencia para despues, porque el feedback sin etiquetar crea exactamente el tipo de ambiguedad que convierte una revision de quince minutos en un ida y vuelta de dos dias.

Las herramientas deberian absorber todo lo que no requiere juicio humano. Los linters, formatters y verificaciones automaticas de estilo corriendo en CI significan que un revisor humano nunca tiene que comentar sobre un punto y coma faltante o un orden de imports inconsistente, lo que libera todo el tiempo de revision para las cosas que realmente requieren una persona: arquitectura, correccion de la logica de negocio, y si el cambio coincide con la intencion detras del ticket.

La velocidad y la reciprocidad son las practicas culturales que hacen que la revision sea sostenible a nivel de equipo. Un pull request que queda parado dos dias no solo bloquea a un ingeniero, invita conflictos de merge y anima a la gente a acumular todavia mas cambios en el siguiente PR para evitar pasar por revision de nuevo, que es exactamente la direccion equivocada. Las revisiones tambien deberian ser reciprocas - juniors revisando a seniors, no solo al reves - porque eso es lo que realmente distribuye la propiedad de los estandares de calidad de la base de codigo entre todo el equipo en lugar de concentrarla en unos pocos ingenieros senior.

La dinamica de equipo a la que apunto es una donde el conocimiento circula mas rapido de lo que cualquier individuo podria documentarlo, y donde ninguna persona es un cuello de botella o un punto unico de falla para entender cualquier parte del sistema. El code review, bien hecho, es el mecanismo que te lleva ahi.

Puntos Clave

• Revisa el diseno primero: pertenece este cambio aqui y facilita cambios futuros?
• Separa explicitamente lo que 'debe cambiar' de lo que 'podria mejorar' para eliminar la ambiguedad.
• Deja que los linters y CI absorban el feedback de estilo para que el tiempo humano vaya a la arquitectura.
• Las revisiones rapidas protegen el flujo del equipo; un PR estancado invita conflictos.
• Las revisiones reciprocas - juniors revisando a seniors tambien - distribuyen la propiedad en el equipo.