View source for Revisión por pares

__NOTOC__
{{Meta-bok|min=5}}
La '''revisión por pares''' (''peer review'', ''code review'' o ''revisión de código'' en inglés) es la práctica de que el código desarrollado por un miembro del equipo sea revisado por otro o por varios antes de integrarse en la rama principal. Su objetivo principal es la búsqueda temprana de defectos y la propuesta de soluciones alternativas o mejoras en el diseño y los algoritmos.

Además, la revisión por pares '''sirve como facilitador para la difusión del conocimiento''' a través del equipo: quien revisa aprende sobre partes del sistema que quizás no conocía, y quien recibe la revisión aprende sobre alternativas y buenas prácticas.
== Origen ==
Esta técnica, aunque proviene del ámbito de la publicación de trabajos científicos donde desde mediados del siglo XX forma parte integral del proceso de publicación, ha calado en el ámbito del desarrollo de software. Pueden verse referencias a ella en guías de [[CMMI]] (en el Área de Proceso de Verificación) o en el libro ''La Catedral y el Bazar'' de Eric S. Raymond.
== Consideraciones básicas ==
Es aconsejable tener en cuenta las siguientes consideraciones básicas a la hora de implantar esta técnica en un equipo de desarrollo:
* Las revisiones por pares buscan la '''identificación temprana de errores''', por lo que se deben realizar de forma incremental según se van completando etapas en el desarrollo: mejor varias revisiones pequeñas que una única revisión al finalizar el desarrollo.
* '''El foco de las revisiones por pares debe ser siempre el código, no la persona que lo ha desarrollado.'''

A partir de estos principios, es posible construir sistemas más o menos complejos de revisión entre pares:


{| class="wikitable"
! width="100 px" style="background:Lavender; color:Black"|Tipo
! width="250 px" style="background:Lavender; color:Black"|Ventajas
! width="300 px" style="background:Lavender; color:Black"|Inconvenientes
|-
|'''Individual'''||Muy sencilla de implementar||Puede producir pactos tácitos de no agresión. Puede provocar conflictos entre autor y revisor.
|-
|'''Grupal'''||Son más efectivos que los sistemas de revisión individual. Se fomenta la colectivización del código.||Puede surgir la figura de líder que reste efectividad al método. Algunos autores se sienten incómodos ante este tipo de  revisión. 
|}

== Centrarse en lo importante ==
Para que la revisión sea eficaz, conviene centrarse en los aspectos de mayor impacto:
* '''Lógica de negocio:''' ¿la implementación cumple lo que la historia de usuario o la spec pedían?
* '''Casos extremos:''' ¿el código maneja correctamente los casos límite y los errores?
* '''Legibilidad:''' ¿el código es comprensible para cualquier miembro del equipo?
* '''Seguridad:''' ¿hay vulnerabilidades evidentes?
* '''Duplicación:''' ¿se repite código que podría abstraerse?

Las herramientas de análisis estático automatizado pueden encargarse de los aspectos más mecánicos (formato, estilo, métricas de complejidad), liberando al revisor para centrarse en los aspectos que requieren juicio.

== Preparar la revisión ==
La efectividad de la revisión depende en parte de la preparación:
* El autor debe asegurarse de que el código compila, pasa los tests y tiene comentarios suficientes antes de solicitar la revisión.
* El revisor debe tener acceso al contexto (la historia de usuario, la spec o los criterios de aceptación) para poder juzgar si la implementación es correcta, no solo si está bien escrita.
* Se recomienda limitar el tamaño de los ''pull requests'' a lo que puede revisarse en una sesión de 30-60 minutos. Los ''pull requests'' muy grandes reducen la calidad de la revisión.

== Revisión por pares del código generado por IA ==
La [[Definición de hecho|DoD reforzada]] para equipos con IA incluye la revisión humana del código generado como componente obligatorio. La revisión por pares del código IA tiene características específicas:
* El código generado por IA puede parecer correcto y completo superficialmente, pero introducir errores sutiles con apariencia de solución válida. El revisor debe ser especialmente cuidadoso con la lógica de negocio.
* La IA tiende a generar código duplicado: la revisión debe verificar que no se ha introducido duplicación no deseada.
* Parte de la revisión puede automatizarse usando otros agentes de IA como revisores (IA supervisando IA), pero la validación final de la lógica de negocio requiere revisión humana.

== Error frecuente ==
<div class="bok-aviso">
'''Revisar el estilo y el formato en lugar del comportamiento.''' Las herramientas de linting y análisis estático resuelven el estilo de forma automática. Si la revisión por pares se centra en el formato del código y no en su lógica, el equipo gasta tiempo valioso de los revisores en algo que ya hace una máquina, y pasa por alto los defectos que solo un humano puede detectar.
</div>
== Referencias ==
* Raymond, Eric S. (1999). ''La Catedral y el Bazar''. O'Reilly Media.

== Véase también ==
<div class="bok-tags">
[[Pair programming]] [[TDD]] [[Refactorización]] [[Agilidad técnica]] [[Definición de hecho]] [[Deuda técnica]]
</div>
<div class="bok-ecosistema">
<div class="texto">
<span class="titulo">'''¿Quieres avanzar en agilidad?'''</span>
<span class="sub">Puedes buscar convocatorias de cursos y exámenes o ir a tu ritmo haciéndote miembro del Club Agile. Esta membresía incluye recursos exclusivos, aulas e-learning y acceso a [https://scrummanager.com/skillarena/ '''Skill Arena''']: un espacio para practicar y medir tus habilidades ágiles a tu ritmo.</span>
</div>
<div class="botones">
<div class="bok-btn-outline">[https://www.scrummanager.com/website/c/calendar/show-courses.php Buscar convocatorias]</div>
<div class="bok-btn-filled">[https://scrummanager.com/club/ Club Agile]</div>
</div>
</div>
[[Category:Glosario de términos]]
[[Category:Practicas_tecnicas]]
[[Category:Practicas_agiles]]