Si empareja el programa, ¿todavía necesita una revisión por pares?

Question

Creo que, en general, las evaluaciones pares son una parte muy buena del proceso de desarrollo; a menudo captan o cuestionan cosas que no eran aparentes cuando el código se escribió originalmente y te hacen más consciente para formatear mejor, poner comentarios, etc.

Sin embargo, si usted es un programa de par, efectivamente tiene una revisión por pares en vivo, entonces ¿vale la pena seguir teniendo una revisión por pares como parte del proceso? ¿Puedes tener revisiones por pares?

Pregunto como la programación de pares está empezando a suceder donde trabajo, y en general esto se ve como un sustituto para la revisión por pares. No estoy tan seguro, pero creo que el tiempo invertido por el desarrollador en la programación de pares y la revisión por pares puede dañar la productividad.

Había una similar question hace un tiempo pero con diferente énfasis y hay un consenso claro

Answer 1

Eso depende.

El objetivo de una revisión por pares, en mi opinión, no es solo encontrar defectos directamente en el código escrito, sino también asegurarse de que el código funcione bien con la base de código existente. A veces, es posible que desee involucrar a un experto del código que está escribiendo y no puede ser un miembro de la pareja.

Por ejemplo, si escribe la parte de Gráficos 3D de una aplicación, le recomendamos que la revise su experto en OpenGL.

Dependiendo de las circunstancias, es posible que desee un tercer par de ojos para analizar su problema. Esta persona ni siquiera puede ser colocada (en otro huso horario o algo así).

Además, cuando se empareja, puede tener una tendencia a pensar igual. Por lo tanto, otra opinión puede abrir los ojos a algo que te perdiste.

Si mis desarrolladores se asocian al código, aún así les incitaría a que revisen su código si no son 100% expertos en esa parte del código.

Answer 2

Si los socios cambian en la programación en parejas, a continuación, que básicamente tienen revisiones por pares de forma automática (incluso más que sólo un par de ojos "extra") Y en caso de que ambos programadores no estén seguros de cómo hacer algo, pueden (debería) seguir pidiendo ayuda, lo que de nuevo resulta en algún tipo de revisión por pares.

Answer 3

Creo que la revisión por pares sigue siendo importante porque el conjunto de ideas involucrado en ambos casos es bastante diferente al momento de la programación, la mentalidad normal no es crítica mientras se hace una revisión por pares. las pruebas manuales realizadas por el mismo devloper que lo ha desarrollado no serían tan buenas como obtenerlo de un probador

Answer 4

La conmutación de pares fue pensada para resolver el problema de las revisiones por homólogos. Cuando el desarrollador se une al nuevo par, él/ella tiene que entender el problema en el que va a trabajar. Y el entendimiento incluye la revisión.

Creo que solo se requieren exámenes de expertos separados para los puntos críticos del sistema.

Answer 5

Paring es la revisión por pares. O como dice XP, si algo es bueno, tómalo al extremo. Si las revisiones entre pares son buenas, hágalo continuamente, es decir, empareje la programación.

Cuando la programación emparejada se realiza correctamente y los pares se rotan con frecuencia, se realizarán revisiones continuas por pares de todos los códigos desarrollados.Mejor aún, el código se revisa a medida que se diseña, prueba y escribe (sí, escriba primero la prueba A.K.A. Desarrollo impulsado por prueba) no después de que se haya escrito el código y sea más costoso de solucionar.

El código revisado por pares es solo una ventaja de la programación de pares. Las otras ventajas son:

Mejora de la calidad: Un par de programadores activos que trabajan en la misma tarjeta historia va a completar la tarjeta con menos defectos

Mejora de la productividad: un par es menos probable que sea más lento si no se bloquea directamente cuando se resuelve un problema. Además, es más difícil tomar un correo electrónico o unas vacaciones en la web cuando trabajas con un compañero ... no quieres decepcionar al socio. Usted va a resolver el problema con un diseño más limpio y menos líneas de código cuando se trabaja como un par

eliminar los silos de conocimiento: Con pares giratorios, aprenderá aplicación y dominio de conocimiento del negocio a través del equipo. Es menos probable que el equipo esté bloqueado porque Sue se fue de vacaciones y nadie más conoce su código.

Transferencia de habilidades: Los pares rotativos enseñan nuevas habilidades (ingeniería y dominio) entre sí mientras trabajan juntas. El nivel del equipo aumentará para todos y el conocimiento se propaga a través del equipo.

El equipo se selecciona a sí mismo: El equipo aprende las habilidades de una antera y eliminará rápidamente a alguien que no esté actuando.