Como bien comenta jgarzas, en su post Beneficios del pair programming, que dos desarrolladores compartan el editor y hagan el desarrollo de forma conjunta puede aportar un plus de calidad a nuestro proyecto.
Del mismo modo, la puesta en marcha es complicada, por la sensación de pérdida de productividad.
Hace tiempo pusimos en práctica la revisión por pares, consiste en definir unos pares de desarrolladores donde cada uno verá el trabajo realizado por su compañero el día anterior.
Un script nocturno en la herramienta de integración continua captura del control de cambios el resumen de las modificaciones realizadas el día anterior por su compañero. Con la información se compone un email y se envía a cada par correspondiente.
El desarrollador lo primero que hace en el día es ver y entender lo que ha realizado su compañero, ante cualquier duda respecto al código, al formato o los comentarios, el desarrollador le consulta a su par e inician un diálogo para aclarar dudas.
Con la revisión por pares conseguimos una serie de beneficios:
- Aprendizaje de trucos y el buen hacer de los compañeros
- Amplio conocimiento de todo el proyecto
- Solución a problemas de estilo de código
- Solución a problemas de código detectado por un compañero
- Unificación de criterios en la forma de desarrollar
No es tan eficaz como la programación por pares, pero ayuda al trabajo en equipo.
Es llevar a la práctica la ley de Linus en un equipo de desarrollo de una forma que no invertimos mucho tiempo en la revisión.
2 comentarios sobre “Revisión por pares”