View source for Revisión por pares

__NOTOC__
La '''revisión por pares''' (''peer review'', en inglés) puede explicarse, en una primera aproximación, como la revisión del código realizada por otro miembro del equipo diferente al autor original del código.

==Objetivos==
El objetivo principal es la '''búsqueda de defectos y la propuesta y evaluación de soluciones alternativas o de mejoras''' en el diseño y los algoritmos utilizados. 

Además, la revisión por pares '''sirve como facilitador''' para la difusión del conocimiento a través del equipo y, en su caso, de la organización.

==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 de dicho proceso, ha calado en el ámbito del desarrollo de software, donde pueden verse referencias a ella en publicaciones tan dispares como en guías de CMMI<sup>1</sup>, en el Área de Proceso de Verificación, o el libro ''La Catedral y el Bazar''<sup>2</sup>.

==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: sistemas básicos donde la revisión se realiza por un único desarrollador que toma el rol de revisor, o donde la revisión se realiza por un grupo de desarrolladores/revisores.


{| 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==

El valor de las revisiones por pares reside en detectar el impacto de nuevos desarrollos en el sistema. Por ello, durante las revisiones se debe mantener el foco en los aspectos realmente importantes:
*¿Se siguen los principios de la Programación Orientada a Objetos?
*¿Se utilizan correctamente las librerías y ''frameworks''? ¿Se está utilizando alguna no estándar?
*¿Hay refactorizaciones claramente necesarias que mejorarán la legibilidad del código?
*¿Se pueden prever problemas de rendimiento, ''memory leaks''...?
*¿Se están usando correctamente las excepciones, el log...?
*...

Otros aspectos superfluos, como el cuestionarse la visibilidad de un atributo o método de una clase, o indicar las deficiencias de formato del código; podrán obviarse, especialmente cuando estos puedan ser solucionados de manera automática (por ejemplo, usando un formateador de código).

==Referencias==
*<sup>1</sup> Mary Beth Chrissis, Mike Konrad, Sandy Shrum (2003) ''Cmmi: Guidelines for Process Integration and Product Improvement'', Addison-Wesley.
*<sup>2</sup>Eric Raymond (2002) ''The Cathedral & the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary'', O'Reilly Media, Inc.

[[Category:Glosario de términos]]
[[Category:Prácticas ágiles]]