January 26, 2019
Code Review is a great way to ensure that code that goes in is high-quality. A lot of value here isn’t from the review itself, it’s from the fact that developers know that they need to send the code past others.
In order to accomplish an effect code review process, you want to balance three perspectives:
The degree to which you want higher safety and knowledge dissemination both correspond to the rigidity of your code review. For example, if you value safety over speed, you might have a more involved process with more stakeholders. If you value knowledge dissemination, you might want to enforce pair programming and a more strict code review process.
Whichever direction you pick, at least one other person should read all of the code that goes into the codebase — no exceptions. Though I recommend pair programming, I also recommend that that other person not be one who paired on the project. The ideal reviewer is actually one who is unfamiliar with the codebase, that way they aren’t biased by the current architecture, and they gain some knowledge in the area.
Below are some guidelines I consider valuable, but you should adapt them to what you consider important.
In general, prefer false negatives to false positives – in other words, if there’s any question about if the PR is good enough, don’t approve it. You’d rather have the process take longer and the work be able to be confidently approved later.
Be respectful of your reviewers’ time!
When you receive a comment, you can: