Revisión por pares: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
|||
| Line 11: | Line 11: | ||
==Consideraciones básicas== | ==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: | 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). | |||
* 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. | 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. | ||
| Line 19: | Line 18: | ||
{| class="wikitable" | {| class="wikitable" | ||
! width=" | ! width="200 px" style="background:Lavender; color:Black"|Tipo | ||
! width=" | ! width="200 px" style="background:Lavender; color:Black"|Ventajas | ||
! width=" | ! width="200 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. | |'''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. | |'''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: | 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). | 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). | ||