We’ve all heard the term, we’ve all seen spiels about it’s importance, but we also have so many excuses why not to do it. The place I’m currently working at ran into two of the most common reasons I’ve seen and here I document how we overcame them for the benefit of anyone who thinks code review might help (hint: it will) but feels they can’t justify it.
No proper tools
Whether the answer is no budget for Crucible or not enough time to set up Phabricator, this is an incredibly common cop out. Our team used Subversion without any branching for version control and a web-based task tracker (Pivotal Tracker) so we created this quick manual process:
- When you commit a task, copy the link to the task into the commit message
- Comment on the task message with a commit number and tag a team member to review
- If they approve, mark as complete. Any suggestions/comments should go in comments, allowing further commits/reviews.
For a small bit of copy-pasting we’ve set up a good process to make sure each commit gets reviewed. In an emergency we can still deploy things before a review, but they must get reviewed before being marked as complete. While it is possible that someone could game the system by just marking tasks as complete without tagging someone for review, we’re a small and close-knit team who understands that the process is about collaborative work and information sharing, not competition about getting stuff released first.
Small team
I know someone who complained that with only six developers it was hard to justify code reviews as they felt they’d be doing more reviews than code. This is understandable and when you first start reviewing major commits or examining another’s code it might take a bit. However the more in tune you get with your team members the shorter you’ll find reviews take as the reviewee will make sure to add appropriate comments, tests, and names that are logical and understood by the rest of the team and the reviewer will be able to assess what has been done based on the task, the commit message, and the file changes.
In truth, my team at work has had no more than 3 developers at any one time since we started code reviews and we’ve still found them incredibly handy for locating areas of improvement (such as logging, documentation), spotting bugs before deployment, and learning more about new codebases that one of us may be working on.