No meu trabalho, temos uma regra muito simples: as alterações devem ser revisadas por pelo menos um outro desenvolvedor antes de uma mesclagem ou um commit no tronco . No nosso caso, isso significa que a outra pessoa senta-se fisicamente com você em seu computador e passa pela lista de alterações. Este não é um sistema perfeito, mas melhorou notavelmente a qualidade do código.
Se você sabe que seu código será revisado, obriga você a pesquisá-lo primeiro. Muitos problemas se tornam aparentes então. Sob o nosso sistema, você tem que explicar o que você fez ao revisor, o que novamente faz com que você perceba problemas que você pode ter perdido antes. Além disso, se algo no seu código não for imediatamente claro para o revisor, isso é uma boa indicação de que é necessário um nome melhor, um comentário ou uma refatoração. E, claro, o revisor pode encontrar problemas também. Além disso, além de observar a alteração, o revisor também pode perceber problemas no código próximo.
Existem duas principais desvantagens para este sistema. Quando a mudança é trivial, faz pouco sentido que seja revisada. No entanto, temos absolutamente que nos ater às regras, para evitar o declive escorregadio de declarar que as mudanças são "triviais" quando não são. Por outro lado, essa não é uma maneira muito boa de revisar mudanças significativas no sistema ou adição de novos componentes grandes.
Já tentamos revisões mais formais antes, quando um desenvolvedor enviava um e-mail para o código para ser revisado para o restante da equipe, e então toda a equipe se reunia e discutia o assunto. Isso levou muito tempo a todos e, como resultado, essas revisões eram poucas e distantes, e apenas uma pequena porcentagem da base de código foi revisada. A "outra pessoa analisa mudanças antes de cometer" funcionou muito melhor para nós.