En todo proyecto de desarrollo se deberían hacer revisiones de código. Las dos motivos principales son que sirven para mejorar la calidad del código y ayuda a reducir el porcentaje de defectos.

En algunos de los proyectos en los cuales he trabajado esta tarea de revisión se denominaba “peer reviews” y era obligatoria en un porcentaje fijo del código. Las revisiones se realizaban por otros programadores, pero si era necesario la podía hacer el arquitecto software o el jefe de proyecto.

El problema con las revisiones de código es que los programadores pueden sentir que son juzgados. Además para poder realizar una buena revisión de código es necesario tener tiempo y conocimiento del sistema, con lo que esta tarea se puede convertir en un cuello de botella, transformándose el remedio en enfermedad.

La solución a esta situación es enfocar las revisiones de código no como una simple de forma de encontrar errores, sino como una manera de compartir los conocimientos y establecer buenas prácticas a la hora de desarrollar entre todos los programadores. Si se hacen así las revisiones fomenta el sentimiento de pertenencia del código realizado por el equipo.

Cuando se realicen las revisiones es necesario que los comentarios no sean ácido y que siempre se respete el trabajo de los otros. En lugar de dejar la revisión a los más expertos es bueno que se repartan el trabajo en diferentes roles. Una persona se puede encargar de la documentación, otro sobre la funcionalidad y otro sobre las consultas a la base de datos. Estos roles deben ir rotándose de manera semanal para que el equipo vaya aprendiendo del resto de compañeros. Una buena forma de programar este tipo de revisiones es juntar al equipo un par de horas a la semana en una sala de reuniones y analizar una parte del código al azar. Es importante que en las reuniones de revisión no se entre en detalles sobre el formato de código. Para esto es mejor utilizar herramientas que lo realicen de manera automática.

Si eres capaz de hacer que las reuniones de revisión se conviertan en algo divertido, serán mucho más productivas y los programadores las aceptarán de manera más natural.

Adaptado de un consejo de Mattias Karlsson.