Porque el code-review es crítico en los proyectos de Odoo

El code-review es el proceso por el cual un desarrollador revisa el código que desarrollo otro desarrollador para resolver un ticket. El proceso es simple. Una vez finalizada la tarea de desarrollo para un ticket, otro desarrollador revisa el código y realiza sus comentarios pidiendo cambios. El desarrollador original discute los comentarios, implementa los cambios y obtiene la aprobación de un revisor para implementar dicho código. Por lo general esto se realiza con github. Se hace antes de un pull-request y pueden haber uno o varios reviews (dependiendo de la criticidad y complejidad del ticket). Tambien se lo puede implementar sin github (por ejemplo con gitlab), inclusivo manualmente (pero es más dificil de controlar). 

Beneficios del code-review

• Acelera el aprendizaje de los desarrolladores junior (o con poca experiencia en Odoo). En un principio, la revisión de código desarrollado por un junior debe ser realizada por un desarrollador senior. En estos casos lo ideal es que la revisión la hagan juntos, así el proceso de aprendizaje del desarrollador junior se acelera.

• Rompe con la dependencia del proyecto en un solo desarrollador. Me parece fundamental para que los proyectos no se estanquen debido a que su desarrollador principal fue raptado por extraterrestres.

• Si bien no es una actividad de testeo, siempre es bueno que el código sea revisado por más de dos ojos. Y esto reduce en forma notoria los errores. 

Dificultades en la implementación

• Implementar el code-review es caro porque en un principio agrega tiempo al desarrollo. Cada línea de código es revisada por un tercero, discutida y muchas veces va a tener que ser reescrita. Y así sucesivamente hasta que el equipo gane experiencia. Muchas veces durante el code-review se encuentran problemas en el diseño de la solución, lo que hace que tenga que revisarse el diseño mismo. El lider de proyecto debe aceptar que el proyecto sufrirá retrasos por las actividades de revisión, pero que son necesarias para que el equipo aprenda y además para mejorar la calidad del trabajo.

• Egos por parte del equipo de desarrollo. Muchas veces en un principio al desarrollador no le gusta que le revisen el trabajo por un tercero. Y menos que esta revisión le retrase su trabajo. El desarrollador debe aceptar que lo que se busca con el code-review es mejorar el producto y que el no es el dueño de del proyecto. El equipo lo es. 

• Muchas veces es factible implementar el code-review cuando ya gran parte de la infraestructura de desarrollo esta en pie y funcionando. Es decir: ya hay repositorios en donde se hace el versionado del código, a los ambientes de producción y testeo solo se promueven los cambios que hayan sido revisados. Si esta infraestructura no esta presente, es muy dificil gestionar el proceso de desarrollo junto con el code-review. Es imposible mantenerlo.

• Para que el code-review sea efectivo el equipo de desarrollo debe tener disciplina para seguir los flujos de trabajo. Si esta disciplina no está presente, solo se perderá el tiempo revisando el código.