En mi trabajo, tenemos una regla muy simple: los cambios deben ser revisados por al menos otro desarrollador antes de una fusión o un compromiso con el troncal . En nuestro caso, esto significa que la otra persona se sienta físicamente con usted en su computadora y pasa por la lista de cambios. Este no es un sistema perfecto, pero aún así ha mejorado notablemente la calidad del código.
Si sabe que su código será revisado, lo obligará a revisarlo primero. Muchos problemas se hacen evidentes entonces. Bajo nuestro sistema, tiene que explicarle lo que hizo al revisor, lo que nuevamente hace que note los problemas que pudo haber omitido antes. Además, si algo en su código no queda inmediatamente claro para el revisor, eso es una buena indicación de que se requiere un nombre mejor, un comentario o una refactorización. Y, por supuesto, el revisor puede encontrar problemas también. Además, además de observar el cambio, el revisor también puede detectar problemas en el código cercano.
Hay dos inconvenientes principales en este sistema. Cuando el cambio es trivial, tiene poco sentido revisarlo. Sin embargo, debemos respetar las reglas, para evitar la pendiente resbaladiza de declarar que los cambios son "triviales" cuando no lo son. Por otro lado, esta no es una buena manera de revisar cambios significativos en el sistema o la adición de nuevos componentes grandes.
Hemos intentado revisiones más formales antes, cuando un desarrollador enviaba un código de correo electrónico para ser revisado al resto del equipo, y luego todo el equipo se reunía y lo discutía. Esto tomó mucho tiempo de todos, y como resultado estas revisiones fueron pocas y distantes, y solo un pequeño porcentaje de la base del código se revisó. La "otra persona revisa los cambios antes de comprometerse" nos ha funcionado mucho mejor.