Most would not dispute that code review is a good idea in at least some circumstances. But is it right for my team? If so, how do we do it?

Do we even need code review?

Probably. Software projects usually have three phases: exploration, settlement, and vision.

From: Automated Testing—Why Bother? by Mike Bland

In the exploration phase, the design of the product or validity of the business is unclear. In the settlement phase, a direction has been determined and we start building for the long term. In the vision phase, complex interdependencies require especially mature development practices. Code review is an investment that pays in as soon as a few weeks. But, for exploratory projects you may not earn returns if you end up quickly throwing most of the code away to start over.

From: Is High Quality Software Worth the Cost? by Martin Fowler

Once you’ve done sufficient exploration and decide to start settling, code review and similar investments such as automated testing will pay in the long run if implemented correctly. Startups may frequently find themselves in the exploration phase, but this is no excuse to cut corners when building for the long haul.

Should my small team really, really, really do code reviews?

How do we do it?

In theory, code review is simple:

1. Open a pull request for each change
2. Once the pull request is approved by the desired reviewers, it can be merged

But, there’s a few practices you should follow to get the most value from this process.

Keep pull requests small!

The level of effort required to review a pull request increases exponentially with its size. Use this rule of thumb:

<aside> 💭 "If you think this PR would be easier to review if it was broken into smaller pieces, break it down"

</aside>

https://twitter.com/iamdevloper/status/397664295875805184

In the interest of facilitating quick and thorough reviews, authors may be asked to break up PR's that are too big to be reviewed effectively.