A guide to excel on your code reviews

Code reviews can seem tedious and boring, but they are actually very beneficial. They help avoid shipping bugs to production and provide valuable insights for the reviewer. Moreover, reviewing code is a good way to keep track of what other teammates are working on and to better understand the bigger picture.

Code reviews: Step by step

1. Understanding the code

Start by reading the Pull Request description or the linked Jira ticket to have a good understanding of the problem that the PR attempts to solve. If it isn’t clear enough, don’t hesitate to ask questions.

Next, understand what the code is actually doing. When reviewing, I suggest not reviewing files from top to bottom as this can be confusing and overwhelming. Instead, look for the main file or function and start from there, tracking down each file.

Make sure you are not just reading through the code, but actually understanding what the code is doing and why a particular change belongs to a particular class or function.

2. Code quality

Check for typos, design, structure, access modifiers, and efficiency. Some questions to ask yourself:

• Are the names of functions and variables simple and descriptive enough?
• Are we calling the same function twice unnecessarily?
• Are we copying a value unnecessarily?
• Can we break out of a loop instead of waiting for it to complete?
• Are we using public access modifiers when a function or parameter should be private?
• Should we be logging exceptions instead of throwing them?

3. Test coverage

Every, and I mean every code change should come hand in hand with a unit test change.

• Are we adding unit tests for all classes that have been modified?
• Do the unit tests cover all possible scenarios?
• Should we be using parameterized tests instead of single tests? (to learn more about Parameterized Tests, read this article)

4. PR description

The PR description should clearly explain the purpose of the PR and include a Jira link to the related ticket.

If it isn’t included, ask for screenshots that prove the changes are working locally as expected (if applicable).

5. Going the extra mile

If you can afford to go the extra mile, pull their branch and work on it locally. Try to optimize the code and/or run their changes locally. Then share any suggestions in the review.

One last tip

Even if you are just getting started and/or don’t have enough knowledge around the changes, you can still contribute to code reviews. Asking clarifying questions or reading other developers’ reviews is a great way to learn.

Remember that both the author and the approver of the PR are responsible for the code that goes to production.