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: