Revisión por pares - Revision history

Mberne: /* Objetivos */

2023-12-21T12:57:45Z

Objetivos

← Older revision		Revision as of 14:57, 21 December 2023
Line 3:		Line 3:

	==Objetivos==		==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.		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.

	~~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==		==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>.		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>.

Mberne: /* Consideraciones básicas */

2023-12-21T12:56:01Z

Consideraciones básicas

← Older revision		Revision as of 14:56, 21 December 2023
Line 18:		Line 18:

	{\| class="wikitable"		{\| class="wikitable"
	! width="~~200~~ px" style="background:Lavender; color:Black"\|Tipo		! width="100 px" style="background:Lavender; color:Black"\|Tipo
	! width="~~200~~ px" style="background:Lavender; color:Black"\|Ventajas		! width="250 px" style="background:Lavender; color:Black"\|Ventajas
	! width="~~200~~ px" style="background:Lavender; color:Black"\|Inconvenientes		! 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.		\|'''Individual'''\|\|Muy sencilla de implementar\|\|Puede producir pactos tácitos de no agresión. Puede provocar conflictos entre autor y revisor.

Mberne: /* Consideraciones básicas */

2023-12-21T12:54:55Z

Consideraciones básicas

← Older revision		Revision as of 14:54, 21 December 2023
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.
	* Ll 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="~~100~~ px" style="background:Lavender; color:Black"\|Tipo		! width="200 px" style="background:Lavender; color:Black"\|Tipo
	! width="~~100~~ px" style="background:Lavender; color:Black"\|Ventajas		! width="200 px" style="background:Lavender; color:Black"\|Ventajas
	! width="~~100~~ px" style="background:Lavender; color:Black"\|Inconvenientes		! 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==
	====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~~ 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?
	* ~~¿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?
	* ~~¿hay~~ refactorizaciones claramente necesarias que mejorarán la legibilidad del código?		*¿Se pueden prever problemas de rendimiento, ''memory leaks''...?
	* ~~¿se~~ pueden prever problemas de rendimiento, memory leaks...?		*¿Se están usando correctamente las excepciones, el log...?
	* ~~¿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).

Mberne at 12:52, 21 December 2023

2023-12-21T12:52:54Z

← Older revision		Revision as of 14:52, 21 December 2023
Line 42:		Line 42:
	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).

			==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:Glosario de términos]]
	[[Category:Prácticas ágiles]]		[[Category:Prácticas ágiles]]

Mberne: /* Origen */

2023-12-21T12:51:51Z

Origen

← Older revision		Revision as of 14:51, 21 December 2023
Line 7:		Line 7:
	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.		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==		==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 ~~([[Chrissis, Konrad & Shrum]])~~, en el Área de Proceso de Verificación, o el libro La Catedral y el Bazar ~~([[Raymond]])~~.		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==		==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:

Mberne at 12:51, 21 December 2023

2023-12-21T12:51:04Z

← Older revision		Revision as of 14:51, 21 December 2023
Line 1:		Line 1:
	__NOTOC__		__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, y cuyo 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.		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 ([[Chrissis, Konrad & Shrum]]), en el Área de Proceso de Verificación, o el libro La Catedral y el Bazar ([[Raymond]]).		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 ([[Chrissis, Konrad & Shrum]]), en el Área de Proceso de Verificación, o el libro La Catedral y el Bazar ([[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:		Es aconsejable tener en cuenta las siguientes consideraciones básicas a la hora de implantar esta técnica en un equipo de desarrollo:

Smanager: Created page with "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 equ..."

2022-09-13T19:51:49Z

Created page with "__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 equ..."

New page

__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, y cuyo 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.

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 ([[Chrissis, Konrad & Shrum]]), en el Área de Proceso de Verificación, o el libro La Catedral y el Bazar ([[Raymond]]).

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).
* Ll 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="100 px" style="background:Lavender; color:Black"|Ventajas
! width="100 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).

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

Revisión por pares - Revision history

Mberne: /* Objetivos */

Mberne: /* Consideraciones básicas */

Mberne: /* Consideraciones básicas */

Mberne at 12:52, 21 December 2023

Mberne: /* Origen */

Mberne at 12:51, 21 December 2023

Smanager: Created page with "__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 equ..."

Smanager: Created page with "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 equ..."