In software development, a code review is an activity where one or more fellow developers review the code written by another developer to look for mistakes or other possible improvements.
Why do a code review?
There are several reasons why software development teams would want to do code reviews. The most obvious being to catch logic errors in the code before it gets released to customers. A few other reasons include verifying that the code changes:
- meet the requirements
- are covered by unit tests
- conform to style guidelines
However, in my experience, one of the most compelling reasons for doing code reviews is that it provides an opportunity for developers to share their knowledge. This knowledge sharing prevents developers from always owning a particular code section or from becoming the “critical path” developer.
Won’t code reviews slow the team down?
Yes and no, code reviews do slow down the process of completing a task. However, many studies have shown a significant increase in the amount of work a team can ship overall because of the improved quality (i.e., fewer bugs) in the software. The later in the software development lifecycle that bugs get found, the longer it will take the team to go back and fix what was broken (aka code churn).
When do you do a code review?
Ideally, requests for code reviews are generated automatically as a part of a project’s build pipeline after any automated checks or tests are done, but before the code gets merged into the main branch.
If you’re unable to automate the code review process, consider doing “over the shoulder” code reviews where you find another developer and have them scroll through the code while you explain what you did and why.
What do you look for in a code review?
I’m a big fan of checklist driven development, meaning you should consider using a checklist to remind you of the kinds of things you should be thinking about during a given task.
There are plenty of code review checklists that are a quick web search away; here is the one I use:
Code Review Checklist
- Does the code compile? Is the logic correct?
- Does the code do what it is supposed to? Does it meet the requirements?
- Is the code easy to read/understand?
- Does the code conform the agreed to coding standards?
- Are there comments that describe the intended function of the code?
- Are edge cases identified and described?
- Do unit tests cover the code?
- Are there any obvious performance implications?
- Are there any obvious security implications?
- Are data inputs validated for type, length, format, and range?