Review before or after code commit, which is better

code-reviews

Traditionally we performed code review before commit, I had an argument with my colleague today, who preferred code review after commit.

First, here's some background,

  1. We have some experienced developers and we also have new hires with almost zero programming experience.
  2. We'd like to perform fast and short iterations to release our product.
  3. All team members are located at the same site.

The advantages of code review before commit I've learned:

  1. Mentor new hires
  2. Try to prevent errors, failures, bad designs early in the development cycle
  3. Learn from others
  4. Knowledge backup if someone quits

But I've also had some bad experiences:

  1. Low efficiency, some changes may be reviewed over days
  2. Hard to balance speed and quality, especially for newbies
  3. One team member felt distrust

As to post-commit review, I know little about this, but the thing I'm most worried about is the risk of losing control due to lack of review.
Any opinions?

UPDATE:

  1. We're using Perforce for VCS
  2. We code and commit in the same branches (trunk or bug fixing branches)
  3. To improve efficiency, we've tried to split code into small changes. We've also tried some live dialog review, but not everyone followed the rule. This is another problem though.

Best Answer

Like Simon Whitehead mentions in his comment, it depends on your branching strategy.

If the developers have their own private branch for development (which I'd recommend in most situations anyway), I'd perform the code review prior to merging with the trunk or main repository. This will allow developers to have the freedom to check in as frequently as they want during their development/testing cycle, but any time code goes into the branch that contains the delivered code, it gets reviewed.

Generally, your bad experiences with code reviews sound more like a problem with the review process that have solutions. By reviewing code in smaller, individual chunks, you can make sure it doesn't take too long. A good number is that 150 lines of code can be reviewed in an hour, but the rate will be slower for people unfamiliar with the programming language, the system under development, or the criticality of the system (a safety critical requires more time) - this information might be useful to improve efficiency and decide who participates in code reviews.

Related Topic