En el desarrollo de software, la revisión por pares es un tipo de revisión de software en la que un producto de trabajo (documento, código u otro) es examinado por colegas del autor para evaluar el contenido técnico y la calidad del producto de trabajo.
El propósito de una revisión por pares es proporcionar "una práctica de ingeniería disciplinada para detectar y corregir defectos en los artefactos de software y prevenir su fuga a las operaciones de campo" según el Modelo de Madurez de Capacidades .
Cuando se realizan como parte de cada actividad del proceso de desarrollo de software , las revisiones por pares identifican problemas que se pueden solucionar en las primeras etapas del ciclo de vida. [1] Es decir, una revisión por pares que identifica un problema de requisitos durante la actividad de análisis de requisitos es más barata y más fácil de solucionar que durante las actividades de arquitectura de software o de prueba de software .
El National Software Quality Experiment [2] , que evalúa la eficacia de las revisiones por pares, concluye que "las inspecciones de software ofrecen un rendimiento favorable de la inversión; los ahorros superan los costes en una proporción de 4 a 1". Dicho de otro modo, resulta cuatro veces más costoso, en promedio, identificar y solucionar posteriormente un problema de software.
Las revisiones por pares son distintas de las revisiones de gestión , que son realizadas por representantes de la dirección en lugar de por colegas, y con fines de gestión y control en lugar de evaluación técnica. También son distintas de las revisiones de auditoría de software , que son realizadas por personal externo al proyecto para evaluar el cumplimiento de especificaciones, estándares, acuerdos contractuales u otros criterios.
Los procesos de revisión por pares existen en un espectro de formalidad, con actividades relativamente no estructuradas como la "verificación por pares" en un extremo del espectro, y enfoques más informales como los recorridos , las revisiones técnicas por pares y las inspecciones de software , en el otro. El IEEE define estructuras, roles y procesos formales para cada uno de los últimos tres. [3]
Los representantes de la dirección no suelen participar en la realización de una revisión por pares, salvo cuando se los incluye por tener conocimientos técnicos específicos o cuando el producto del trabajo que se está revisando es un documento de nivel gerencial. Esto es especialmente cierto en el caso de los gerentes de línea de otros participantes en la revisión.
Los procesos para revisiones formales por pares, como las inspecciones de software , definen roles específicos para cada participante, cuantifican etapas con criterios de entrada/salida y capturan métricas de software en el proceso de revisión por pares.
En la comunidad de código abierto/libre , algo parecido a la revisión por pares ha tenido lugar en la ingeniería y evaluación de software informático . En este contexto, la lógica de la revisión por pares tiene su equivalente en la ley de Linus , que suele expresarse así: "Si hay suficientes revisores, todos los errores son superficiales", es decir, "si hay suficientes revisores, todos los problemas son fáciles de resolver". Eric S. Raymond ha escrito de manera influyente sobre la revisión por pares en el desarrollo de software . [4]