Whether you love or hate code reviews, you can’t deny that it helps ensure the quality of code is consistent across a project. As a result, code reviews typically raise the code to a much higher standard. However, code reviews only work if it is taken seriously and everyone that participates in code review is not just going through the motion.
In this post, I will be going over 7 ways on how to get the most out of code reviews. Some of them will be from the perspective of the reviewer and others as the submitter.
Reviewer
1. Focus on the Right Stuff
When reviewing code it is important to put your efforts into the right things. Understand what the problem is and see if the solution makes sense. Will the solution cause problems for another portion of the codebase? Is the code clear or is it difficult to understand? Is the code reinventing the wheel? If so point out what can be used instead. Save the syntax and formatting to a linter.
2. Understand the Purpose of the Code
As the reviewer, your job is not to just look at the code but to understand what the problem the code is addressing. Without understanding what issue the code is trying to address, it will be difficult to get the big picture idea of the solution you’re reviewing. Once you understand the big picture idea, it helps you get context and understand the code you’re reviewing more.
3. Spread out Code Reviews
Code reviews are not something you want to do in a batch at a time. You’re looking at code and trying to understand the code and how it ties to the problem it is trying to solve. It is just as mentally taxing as coding. So, take breaks and spread out code reviews throughout the day so you can recharge after a code review.
4. It Is Okay to Say It Is All Good
It is okay to say the code you’re reviewing is all good and there is no change needed. The point of a code review is to point out bad practices, bugs, incorrect logic, and etc. It is not really a time for you to be nitpicky for the sake of being nitpicky.
Submitter
5. Have Good Commit Messages
As a developer, you should aim to have good commit messages that summarize what the commit is about without the need to look at the code. Just by looking at the commit messages, other developers and reviewers should be able to understand the goal of the commit. For example, a bad commit message would be like “Update a warning message”. A good commit message would be like “Update the warning message for service expiration to include the date. This way the customers don’t need to look for the date.”
6. Keep the Code Change Small
Keeping code change small is beneficial to yourself and the reviewer. When there is less code it is easier to work with and it tends to help keep things simple. If you are finding yourself writing a lot of code, you might want to take a step back and see if you’re overengineering the solution or overcomplicated things. It is good to keep your code lean and always consider YAGNI (You Aren’t Gonna Need It) when applicable.
7. Adhere to Existing Formatting and Syntax
Unless you’re starting a brand new project, chances are the project you’re working on already has a set standard for formatting and syntax. It is also probably enforced by a linter as well. So, instead of trying to go against the grain, stick with that style and format even though it might not be your preference. It helps to keep the code consistent with the rest and eliminates the need for the reviewer to note the formatting and syntax.
I hope this post was helpful to you. If you found this post helpful, share it with others so they can benefit too.
What is your code review process like? What do you look for when doing code reviews?
To get in touch, follow me on Twitter, leave a comment, or send me an email at steven@brightdevelopers.com.