Revisión por pares - Revision history

Mberne: /* Véase también */

2026-05-19T15:14:26Z

Véase también

← Older revision		Revision as of 17:14, 19 May 2026
Line 68:		Line 68:
	</div>		</div>
	[[Category:Glosario de términos]]		[[Category:Glosario de términos]]
	[[Category:~~Practicas_tecnicas~~]]		[[Category:Prácticas técnicas]]
	[[Category:~~Practicas_agiles~~]]		[[Category:Prácticas ágiles]]

Mberne: /* Referencias */

2026-05-19T14:55:14Z

Referencias

← Older revision		Revision as of 16:55, 19 May 2026
Line 51:		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 ==

Mberne: /* Revisión por pares del código generado por IA */

2026-05-19T11:00:21Z

Revisión por pares del código generado por IA

← Older revision		Revision as of 13:00, 19 May 2026
Line 42:		Line 42:
	== 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 ==

Mberne: /* Preparar la revisión */

2026-05-19T11:00:12Z

Preparar la revisión

← Older revision		Revision as of 13:00, 19 May 2026
Line 36:		Line 36:
	== 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 ==

Mberne: /* Centrarse en lo importante */

2026-05-19T11:00:02Z

Centrarse en lo importante

← Older revision		Revision as of 13:00, 19 May 2026
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?

	~~'''Lógica~~ de ~~negocio:''' ¿la implementación cumple lo que la historia~~ de ~~usuario o la spec pedían?~~		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.
	~~'''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:

Mberne: /* Consideraciones básicas */

2026-05-19T10:59:45Z

Consideraciones básicas

← Older revision		Revision as of 12:59, 19 May 2026
Line 12:		Line 12:

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


	{\| class="wikitable"		{\| class="wikitable"

Mberne: /* Consideraciones básicas */

2026-05-19T10:59:38Z

Consideraciones básicas

← Older revision		Revision as of 12:59, 19 May 2026
Line 12:		Line 12:

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

	{\| class="wikitable"		{\| class="wikitable"
	! width="100 px" style="background:Lavender; color:Black"\|Tipo		! width="100 px" style="background:Lavender; color:Black"\|Tipo

Mberne: /* Consideraciones básicas */

2026-05-19T10:58:57Z

Consideraciones básicas

← Older revision		Revision as of 12:58, 19 May 2026
Line 8:		Line 8:
	== 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.'''
	'''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:		A partir de estos principios, es posible construir sistemas más o menos complejos de revisión entre pares:
Line 22:		Line 21:
	\|'''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 ==		== 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:

Mberne at 10:58, 19 May 2026

2026-05-19T10:58:25Z

@@ Line 1: / Line 1: @@
 __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.
+{{Meta-bok|min=5}}
-==Objetivos==
+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.
-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.
+== 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.
-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.
+== 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:
 {| class="wikitable"
 ! width="100 px" style="background:Lavender; color:Black"|Tipo
@@ Line 27: / Line 22: @@
 |'''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==
+== Revisión por pares del código generado por IA ==
-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 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.
-*¿Se siguen los principios de la Programación Orientada a Objetos?
+La IA tiende a generar código duplicado: la revisión debe verificar que no se ha introducido duplicación no deseada.
-*¿Se utilizan correctamente las librerías y ''frameworks''? ¿Se está utilizando alguna no estándar?
+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.
-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).
+== Error frecuente ==
-==Referencias==
+Raymond, Eric S. (1999). ''La Catedral y el Bazar''. O'Reilly Media.
 [[Category:Glosario de términos]]
-[[Category:Prácticas_técnicas]]
+[[Category:Practicas_tecnicas]]
-[[Category:Prácticas ágiles]]
+[[Category:Practicas_agiles]]

Mberne at 14:50, 11 May 2026

2026-05-11T14:50:26Z

← Older revision		Revision as of 16:50, 11 May 2026
Line 46:		Line 46:
	[[Category:Glosario de términos]]		[[Category:Glosario de términos]]
	[[Category:Prácticas_técnicas]]		[[Category:Prácticas_técnicas]]
			[[Category:Prácticas ágiles]]