¿Cómo se combate esta situación en la que de repente hay tanto código que hay que revisar y hacerle Review?
Traducción automática del post original, sin revisión de un traductor humano. Las afirmaciones históricas pueden haber cambiado.
¿Cómo se combate esta situación en la que de repente hay tanto código que hay que revisar y hacerle Review?
El cuello de botella ha pasado de escribir el código a revisarlo, y gran parte del trabajo del equipo de desarrollo consiste en juzgar lo que se desarrolló y cómo se desarrolló.
Una de las formas que encontré que nos facilita las cosas a mí y al equipo es añadir instrucciones al agente que escribe la PR Description (ya sea un command en Cursor o a través de GitStream de LinearB) siguiendo una metodología de 4 pasos:
1. Qué problema veníamos a resolver
2. Qué cambió y dónde (qué archivos)
3. Cómo funciona en la práctica (el flujo)
4. Cuáles son los riesgos
Una vez que se detalla el PR de forma tan granular ya en la etapa de Description, el camino para entender el código se vuelve mucho más corto y fácil: ya sé qué espero ver en el propio código, y a veces incluso detecto aspectos de arquitectura o riesgos que el propio agente planteó antes de que yo mirara una sola línea de código
Esto nos funcionó tan bien que, cuando se lo compartí a los demás líderes de equipo, decidieron adoptarlo en todo R&D para cada PR que se abre 😇
