En donde trabajo comenzamos hace poco a formalizar las revisiones de código. Esperábamos que fuera algo bastante polémico dentro del grupo de desarrolladores, aunque no resultó así. Antes de comenzar a trabajar en el sistema de revisiones de código, leímos bastante sobre el tema y tomamos los recaudos que nos parecían necesarios.

Por otro lado, en lo que respecta a Programación de a Pares (Pair Programming de XP) nosotros utilizamos esta técnica para desarrollos nuevos (en los primeros pasos de los mismos), en los desarrollos de investigación. Por otro lado, cuando el diseño ya no es un tema a tener tan presente en el desarrollo, sino que hay momentos que es mas repetición que pensar, dejemos la programación por parejas y seguimos un rato cada uno por su lado.

Ahora entrando en el tema, nos hacemos la pregunta. ¿Qué caracteriza a una revisión por pares? En el caso de que un equipo desarrolla sus componentes juntos (o programación de a pares), ¿podemos decir que el componente se ha revisado en su origen?

Según uno de los clásicos en las revisiones por pares (Libro "Peer Reviews in software" de Karl Wiegers), puede considerarse que la programación de a pares como una práctica de revisión por pares, no obstante informal (porque no envuelve la preparación y registro de la información y las métricas).

Se puede considerar como una práctica alternativa que contribuye a alcanzar los "Objetivos Específicos" de la prueba de verificación. Sin embargo, es facil demostrar (inclusive con referencias) que la programación de a pares puede reemplazar la revisión formal o la inspección.

Otra estrategia que se puede utilizar es trabajar con  programción por pares y hacer las revisiones o inspecciones en los artefactos considerados más críticos.

Nosotros, particularmente, consideramos que las revisiones y las inspecciones tienen un retorno de inversión gigante, como se ha más que demostrado en la industria (puede ver estos datos en el material didáctico, la disciplina de las revisiones  e inspecciones).

Incluso, las revisiones e inspeccioes dan más retornos que las pruebas! La realización de revisiones en artefactos, como los requerimientos y los componentes de código más complejos (con el apoyo de herramientas para análisis de código estático), es crucial para mejorar la calidad y aumentar la productividad del equipo (debido a la reducción de re-trabajo).

De acuerdo con los autores clásicos en revisiones e inspecciones, quienes deben hacer la inspección de los artefactos son miembros del equipo que tienen la misma función que el autor del artefacto analizado y también, si es posible, la gente que utiliza el artefacto. Entonces, ¿por qué, en algunos casos, sería difícil pedir a un analista de requerimientos o a un gerente de proyecto que revise el código fuente? A menudo la formación de ellos no es técnica, por lo que daría lugar al descubrimiento de un pequeño número de defectos.

Tal vez no lo parezca, pero las revisiones y las inspecciones son más dinámicas de lo que muchos piensan. Además de generar oportunidades inmensas para la mejora continua de los equipos.

Continuación de Revisiones de código, buenas o malas.
Adaptado libremente de Revisoes e Inspecoes de Software e/ou Pair Programming no CMMI.