Benefits of post-commit code reviews

Many teams debate whether code reviews should occur before a submission or after a submission. I've worked on teams that have used both approaches and am convinced that post-commit code reviews are more beneficial. Post-commit code reviews:

• allow reviewers to easily try out the real code they are reviewing.
• are easier to create.
• promote a culture of many small submissions.
• work better for submissions that require more than one review.
• prove to developers that they are trusted and therefore leads to a happier development community.

Each benefit is explained below.

Reviewers can experiment with code under review

With post-commit code reviews, a reviewer can experiment with the code under review just by checking out the relevant code base from source control. If a reviewer works on the code base frequently, he probably already has a checkout of the code base and just needs to update it. To experiment with code in a pre-commit code review, a reviewer must typically download a patch that is attached to the code review and apply it to his checkout, making sure to apply it to the correct root folder.

Ease of code review creation

Post-commit code reviews are easier to create than pre-commit code reviews. Code review tools, such as Atlassian Crucible, allow you to create a code review simply by selecting a submission. Pre-commit code reviews are harder to create because they typically require the author to create a patch, upload the patch to the code review tool, and ensure that the patch is anchored to the correct folder in source control.

Culture of small submissions

Post-commit code reviews promote a culture of many small submissions - get a little piece of functionality working and then submit it. Repeat this frequently and trust developers to decide when a particular submission requires a review.

Submissions that require more than one review

When you do a pre-commit code review based on a patch, it's not clear how to review the changes made based on review comments (because you'd have to make a patch of a patch to review only the changes). When you do post-commit code reviews, you just make a second submission and, if necessary, call a review for that submission.

Trust in developers

Just like any other group of people, developers like to be trusted and are happier and work more effectively in an environment where they are trusted. Post-commit code reviews promote such trust in developers. Pre-commit code reviews promote the opposite - that developers must be scrutinized. Sure, junior developers may need to be scrutinized but that should not be the default team behavior.

Potential drawback and workarounds

One potential drawback of post-commit code reviews is that an unreviewed submission can break everything. However, modern development tools provide easy workarounds:

• A continuous integration system, such as Bamboo, will quickly tell you that everything is broken.
• A modern revision control system, such as Subversion, allows you to easily revert a single submission. Therefore, in a worst-case scenario when the continuous integration system indicates that the build is broken, you can revert the offending submission and trigger another build.