¿La programación de pares elimina la necesidad de revisiones de código en un proyecto de Programación Extrema (XP)?

En un proyecto de programación extremo, los programadores hacen pares de programación la mayor parte del tiempo.

Como estos pares también rotan, es decir, empareja el programa con diferentes personas, y existe una sensación de propiedad colectiva, el código fuente se revisa y actualiza con frecuencia.

Siendo así, ¿hay una necesidad de revisiones de código? Quiero decir, deja de programar y en realidad solo revisa el código.

— Eduardo Copat
fuente

La programación en pareja es solo un inquilino de XP. Hay muchas otras metodologías ágiles que no siguen XP. No hay nada en el Manifiesto para el Desarrollo de Software Ágil ni los Principios detrás del Manifiesto Ágil que menciona la programación de pares. Tampoco hay nada sobre las revisiones de código tampoco. Es importante no asumir que todo ágil es extremo.

Permítanme reformular mi pregunta para incluir solo XP entonces.

— Eduardo Copat

¿Hay alguna razón por la que no lo intentes y te asegures de establecer algunos criterios para parar? Si el equipo se siente cómodo con el registro del código, esa debería ser una buena razón.

— JeffO

Uno de los recursos clave para Extreme Programming es el de Ward's Wiki, también conocido como Portland Pattern Repository, también conocido como C2.com . Aquí es donde varias personas analizaron varias metodologías y las documentaron a medida que las usaban.

Dentro de este wiki, hay una página: Revisiones de código de programación extrema que tiene varios contribuyentes, incluidos Ron Jeffries y Kent Beck.

A esto, dijeron:

Las revisiones de código son consideradas importantes por muchos gurús de procesos grandes. Su objetivo es garantizar el cumplimiento de las normas y, lo que es más importante, garantizar que el código sea claro, eficiente, funcione y tenga QWAN. También tenían la intención de ayudar a difundir el conocimiento sobre el código al resto del equipo.

ExtremeProgramming requiere que todo el desarrollo sea realizado por dos ingenieros que trabajen juntos. El código se revisa sobre la marcha, en gran medida. Esto garantiza que más de una persona tenga un conocimiento íntimo del código en todo momento.

ExtremeProgramming requiere que todos los objetos tengan UnitTests. Esto garantiza que el objeto funcione y continúe funcionando según lo modificado.

Algunos idiomas son reflexivos. En dichos idiomas, UnitTests puede verificar directamente la conformidad de los estándares importantes. (por ejemplo, los objetos deben implementar # = y #hash, o ninguno de los dos).

ExtremeProgramming practica CollectiveCodeOwnership, lo que significa que los objetos que requieren atención serán examinados por muchos desarrolladores. Esto tiende a ejercer presión sobre aquellos que producen código que no cumple con los estándares. Se alienta / espera que los desarrolladores visitantes pongan el código en conformidad cuando encuentren desviaciones. Esto también asegura que el conocimiento del código se difunda más allá del par inicial de programadores que lo creó.

Por lo tanto, los proyectos ExtremeProgramming no requieren revisiones explícitas. Sueltalos de tu metodología.

También hay bastante más discusión sobre el tema allí por parte de otros.

Sin embargo, los puntos clave son que con la combinación de pruebas, propiedad colaborativa y programación de pares, estas cosas resuelven los objetivos que normalmente se supone que debe realizar una revisión de código, tales como:

Dispersar el conocimiento de lo que se está haciendo
Un segundo (o más) conjunto de globos oculares en el código para asegurarse de que sigue los estándares
Verificar el correcto funcionamiento del código.

Estos se realizan de forma continua a través de la programación de pares y las pruebas automatizadas en Extreme Programming y, por lo tanto, no es necesaria una inspección explícita de Fagan .

Lectura relacionada:

Programación de pares versus revisiones de código en Coding Horror
Las revisiones de código se consideran perjudiciales en ExtremeProgramming.org

Argumenté en otra pregunta y respuesta que la revisión del código es un desperdicio innecesario (en el sentido Lean de la palabra) y que la programación de pares debería ser el método preferido para proporcionar todos los beneficios que proporcionaría una revisión del código. No hace falta decir que la gente se ofendió por mi argumento porque no lo había respaldado con THE VOICE OF AUTHORITY (TM) como tú. Para un grupo de personas que se ocupan de la lógica día a día, somos un grupo ilógico.

— Michael Brown

El riesgo de hacer programación de pares sin revisiones de código adicionales es que ambos programadores están muy involucrados en el momento de escribir y pueden escribir código que parece completamente claro y lógico en ese momento, pero menos cuando se vuelve a ver después de unos días. Qué tan grande y / o aceptable es ese riesgo depende de su organización.

— Bart van Ingen Schenau

@MikeBrown también podría argumentar que la programación de pares es un desperdicio innecesario y que la revisión del código debería etc., etc.

— AlexFoxGill

Vea lo que quise decir con DESECHO fue la definición "Lean" de la palabra. Piense en el proceso típico de la línea de ensamblaje. La idea es llevar el automóvil a la línea lo más rápido posible y se realizan controles de calidad después del hecho (revisión del código). Los principios Lean propugnan tomar un poco más de tiempo y esfuerzo para crear calidad en (programación de pares) para que la verificación posterior sea innecesaria.

— Michael Brown