Most would not dispute that code review is a good idea sometimes. But is it right for my team? If so, how do we do it?
Probably, but not always. 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 definitely needed at the vision stage but is sometime valuable at the exploration phase. It’s an investment that pays in as soon as a few weeks. But, exploratory projects 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?
In theory, code review is simple:
But, there’s a few practices you should follow to get the most value from this process.
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 split into several smaller PRs, 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 PRs that are too big to be reviewed effectively. When creating multiple PRs for a single change, make each new PR's base branch the branch from your previous PR. This creates a chain of PRs that will automatically update as each one is merged. For special changes like renaming a common variable, hundreds 50+ files might be the right size. But most of the time, a small scrollbar and “large diffs not shown by default” are signals your PR is too big. 2-15 files is a nice range but context matters more.