I am currently writing a blog post on this topic. The short answer is
* The best way to review code is through pair programming
* It's a bad idea to gate merge to mainline - by creating a separate
branch, for example - on a formal review process. This inhibits
continuous integration (the best way of reducing the risk of bad
changes, which is what you are really aiming to achieve).
* I think Gerrit is a nice tool, but it should be used *after* check-
in (that's how it's designed, in fact). Part of the job of the senior
developers is to review all check-ins. They could, for example,
subscribe to a feed.
To summarize: code review is good. So good, we should be doing it
continuously, through pair programming and reviewing commits. If a
senior dev finds a bad commit, she should pair with the person who
committed it to help them fix the problem.
Gating merge to mainline on a formal review is bad, and creating
branches to do so is extra bad, for the same reason that feature
branches are bad.
On Feb 5, 2:30 am, Frederic Conrotte <frederic.conro...@gmail.com