La respuesta simple es que “hay mucho código por revisar“, y tiene sentido, pues si estamos liberando funcionalidades, sea diaria, semanal o mensualmente, el equipo está escribiendo tanto código como se necesite. Y si además se respeta un procedimiento de construcción adecuado, así se tengan herramientas y/o automatizaciones, se necesitará una validación adicional, y con esto me refiero a la humana.

Ojo, y esto fue mencionado por Fred Brooks hace casi cincuenta años, así se agreguen más personas al proceso, el tiempo siempre jugará en contra o peor, podría incrementarse, sea – y esta es una opinión personal– porque hay reuniones por atender, dudas que resolver o bueno, cosas para ayer.

Entonces solo queda afinar el proceso, quizá definir periodos, horarios de revisión, reglas y puntos que prefiero mencionar en otra publicación, pero –para no alargar esto– lo mínimo a considerar es el tamaño del bloque o tamaño del código a revisar.

Ahora, si no tenemos idea al respecto, un estudio –que, por cierto, tiene algunos años, pero su base de investigación es muy interesante– recomienda manejar un rango de revisión que va entre las 200 y las 400 líneas de código y que el proceso como tal, no debería tomar más de una hora.

Ahora, algunos se preguntarán ¿cómo se mide esto?, por suerte se tienen herramientas cada vez más sofisticadas –y también podríamos hablar de ello–, pero aquí el problema no es ni será la herramienta, sino el acuerdo que debe tomar el equipo sobre lo que a veces llamo “el tamaño de la propuesta de cambio“, donde propuesta cambio (asociada al concepto de changeset, pero de eso podemos hablar otro día) refiere al bloque de código asociado a la funcionalidad que queremos incluir en el producto que estamos construyendo.

Personalmente creo –y obviamente puedo estar equivocado– que debería ser uno de los primeros acuerdos que se deben manejar dentro del equipo, caso contrario se afectará la calidad del producto, y aquí debemos recordar que productos digitales que funcionan hay muchos, pero que funcionen bien, ese ya es otro tema.

Aquí algunas referencias a tener en cuenta:
– Best practices for code review: https://smartbear.com/learn/code-review/best-practices-for-peer-code-review/
– The largest case study of code reviews, ever:https://www.cmcrossroads.com/article/largest-case-study-code-reviews-ever
– Brook’s law: https://en.wikipedia.org/wiki/Brooks%27s_law
– Changeset: https://en.wikipedia.org/wiki/Changeset

Un abrazo,

JD