Revisión por pares: Difference between revisions
| (4 intermediate revisions by the same user not shown) | |||
| Line 26: | Line 26: | ||
== Centrarse en lo importante == | == Centrarse en lo importante == | ||
Para que la revisión sea eficaz, conviene centrarse en los aspectos de mayor impacto: | 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 == | == Preparar la revisión == | ||
La efectividad de la revisión depende en parte de la preparació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 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. | ||
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. | ||
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 == | == 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: | 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. | |||
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. | ||
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. | ||
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 == | == Error frecuente == | ||
| Line 53: | Line 51: | ||
</div> | </div> | ||
== Referencias == | == Referencias == | ||
* Raymond, Eric S. (1999). ''La Catedral y el Bazar''. O'Reilly Media. | |||
Raymond, Eric S. (1999). ''La Catedral y el Bazar''. O'Reilly Media. | |||
== Véase también == | == Véase también == | ||
| Line 71: | Line 68: | ||
</div> | </div> | ||
[[Category:Glosario de términos]] | [[Category:Glosario de términos]] | ||
[[Category: | [[Category:Prácticas técnicas]] | ||
[[Category: | [[Category:Prácticas ágiles]] | ||
Latest revision as of 17:14, 19 May 2026
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:
| Tipo | Ventajas | 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 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
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.
Referencias
- Raymond, Eric S. (1999). La Catedral y el Bazar. O'Reilly Media.
Véase también
¿Quieres avanzar en agilidad? 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 Skill Arena: un espacio para practicar y medir tus habilidades ágiles a tu ritmo.