Posted by One of your colleagues is asking you to review the code she wrote. Instead of haphazardly looking at the code to find issues with it, use these three simple steps to provide a meaningful, thorough review that will help both yourself and your colleague improve the quality of the code being checked in.
Step 1 – Plan
Before you even follow the link to the review, make sure that you have at least thirty minutes to dedicate to the task. You’ll find it much easier to complete the review in a timely fashion and be able to provide meaningful feedback if you give it your entire attention, instead of a few distracted minutes here and there.
If you’re planning on getting to the review later in the day, make sure the requester is aware of it. She might decide to find another reviewer if she’s in a rush, but at least she won’t wonder if you’ve got it on your radar.
Once you’re ready to go, throw on some noise-cancelling headphones, close your email/slack/phone, and open that code review!
Step 2 – Contextualize
Before you look at any code, take a few minutes to understand what you’ll be reviewing. This can be accomplished in a multitude of ways. Read the ticket that’s associated to the change, go over any documentation that the team has produced for the feature, or even, shock horror, reach out and talk to someone who did the change to get a better understanding of it.
With that done, you’re ready to start looking at the code. Your first pass is to familiarize yourself with what you’re looking at and understand the breadth of the change.
You’re also looking to identify the most important parts of the code that need to be looked at more closely. In any change, there’s a core part of the code, usually focused on a few critical classes, where 80% of the functionality is implemented. Take a note of these classes, as you’ll be coming back to them in step three.
Feel free to comment on obvious mistakes that have made it through the cracks as you go through looking at the code differentials. There shouldn’t be a ton of these if you’re using a static code analyzer.
Before moving on to the most vital step of the review, take a moment to look at what other reviewers have commented on. It’ll give a good indication as to the type of issues you should be on the lookout for. If there are a lot of review comments in a given class, it’s a good probability that it’s an important class to focus on during your own deep dive.
Step 3 – Deep Dive
The first thing to do on a code deep dive is to check that the code actually does what it’s supposed to do. Either through over-eagerness to finish the task or simple forgetfulness, it’s easy to forget to solve part of the problem. A simple way to verify that nothing has been forgotten is to cross-reference the code with the acceptance criteria of the story.
Next up, pull out your checklist and start looking for those high-value code improvements that will make the code more maintainable and less prone to bugs. The best strategy here is to go over each point of the checklist one by one, making sure that the checklist step has been adhered to in the code under review.
A note on comments about potential defects. Most developers often forget that another developer is on the other end of every comment you write. They’ve probably worked a long time on the code to get it where it is and have made numerous decisions to achieve its current level of maturity. It’s often difficult to see defects in code we write and are so close to, so please be thoughtful when writing up what might seem like an obvious defect.
Finally, find a few things that you like about the code. Try to keep it in mind the next time you’re coding something to incorporate it in your code. People like seeing their good coding patterns used by other developers and code review is a great place to share these patterns and practices. And do feel free to complement the coder for the nice piece of code!
Marc Roussy 