Esa práctica en particular parece ineficiente y es probable que sea vergonzosa: quién quiere que sus errores apunten a todo un grupo de personas. Entonces, si no pueden elegir lo que se va a revisar y el código aún no está en producción, es probable que esto incomode a las personas.
Dependiendo de cuándo se revise el código puede hacer una gran diferencia en si los comentarios de revisión del código entran o no en el código. Si el desarrollador puede elegir y elegir solo el código de producción, es poco probable que los comentarios de revisión se implementen. Es agradable tener reuniones donde los desarrolladores pueden mostrar alguna técnica ingeniosa que aprendieron que otras personas estarían interesadas, pero eso no es una revisión de código. Eso es entrenamiento.
Hacemos una revisión de código de cada fragmento de código antes de que se mueva a QA. Cada pieza. Generalmente involucra solo al revisor de código y al desarrollador. No pasa al control de calidad hasta que el revisor del código lo apruebe formalmente. Entonces el desarrollador tiene que hacer los cambios. Hemos encontrado y solucionado rápidamente muchos problemas que QA podría no haber encontrado (también encuentran cosas que no vemos en la revisión de código). Además, reduce la codificación del vaquero e identifica rápidamente a las personas que no están funcionando bien para que podamos solucionar sus problemas y entrenarlos o deshacernos de ellos antes de que dañen nuestra aplicación. El tiempo de revisión del código es parte de nuestro tiempo estimado cuando planificamos el trabajo, por lo que no afecta en absoluto la fecha límite. Y en realidad, ahorra tiempo a largo plazo porque cuanto antes se encuentre un problema, más fácil será solucionarlo.
Personalmente, he enseñado a los desarrolladores menos experimentados muchas técnicas mejores a través de la revisión de código y he aprendido algunas técnicas mejores al revisar el código de otras personas, así como sus comentarios sobre mi código. La revisión adicional del código asegura que alguien más comprenda el código, lo que contribuye en gran medida a que sea más fácil de mantener. A veces, el código funciona, pero las preguntas de la revisión dejan en claro que habrá problemas de mantenimiento porque el código es difícil de entender. Es mejor refactorizar en esos casos mientras todo está fresco en su mente que un año después, cuando incluso el autor del código se rasca la cabeza y se pregunta por qué el código hace tal o cual cosa.