cantidad de código en la revisión de código

En mi experiencia, la mayoría de los equipos de la compañía revisan el código del miembro del equipo con una pequeña cantidad de código, siempre menos de cientos de líneas. ¿Es apropiado revisar una gran cantidad de código, por ejemplo, un módulo, cuando el código está completo y listo para ser revisado de una vez por todas?

La razón de las revisiones de código pequeño es para maximizar la efectividad.

Los estudios que involucran el Proceso de software personal han encontrado que los revisores son más efectivos, con respecto a maximizar los defectos identificados en la revisión, cuando revisan no más de 150-200 líneas de código fuente por hora. Teniendo en cuenta los datos empíricos, se trata de determinar cuánto tiempo las personas pueden permanecer atentas. No tengo ningún dato empírico, pero sé que mi mente comienza a divagar después de aproximadamente 1 hora de leer algo. Para mí, eso indica que las revisiones de código deben revisar menos de 150 líneas de código a la vez.

Es apropiado si ayuda a su equipo a crear un mejor producto.

Algunas razones por las que las revisiones de código a menudo se centran en fragmentos más pequeños:

• Revisar adecuadamente una gran cantidad de código requiere que cada participante pase mucho tiempo preparándose, y eso puede ser costoso.

• Cuanto más dura una reunión de revisión (cualquier reunión, en realidad), menos personas prestan atención. Dos horas es casi lo mismo que la mayoría de las personas pueden soportar, y mantener reuniones más cortas que eso (digamos, una hora o 90 minutos como máximo) contribuye en gran medida a garantizar que todos estén en su mejor momento.

• A menudo no es necesario revisar cada línea. Una razón para revisar el código es asegurarse de que todos cumplan básicamente con el mismo conjunto de pautas de codificación. Una revisión detallada de una cantidad menor de código funciona mejor para ese propósito que una revisión menos detallada de más código.

Dicho esto, si encuentra que revisar más código es útil, y si su equipo puede soportarlo, entonces intente por todos los medios. Ayudará a asegurarse de que haya algunas reglas básicas y que alguien actúe como facilitador para mantener la reunión en marcha. Además, considere que los revisores envíen sus comentarios de antemano para que pase menos tiempo en cosas puntuales como el uso inadecuado del espacio en blanco y más tiempo para discutir temas importantes e interesantes.

Si revisa una gran cantidad de código una vez que ya está completo (y presumiblemente funcional), esto se convertirá más en una sesión de "deberíamos haber hecho ..." que "arreglemos / cambiemos esto para hacer ..."

Entonces, si el propósito principal de la actividad es como un ejercicio de aprendizaje post mortem, entonces la revisión de código grande tiene sentido. Si es para tratar de detectar defectos, probablemente no funcionará muy bien. Es probable que se pierdan pequeños defectos, ya que todos en la revisión se aburren y se cansan, y es probable que se omitan los grandes defectos estructurales ya que, bueno, "demasiado tarde ahora: el código está escrito y el cliente lo quiere ayer".