Reviewer’s Guide to Effective Code Review

Code review is a one of the least focused responsibilities in our daily tasks as developers. Providing effective feedback to pull requests can significantly increase the quality of the codebase decreasing bugs, tech debts, and future refactors. Here is a detailed guide to help you become an effective code reviewer. Thanks to roadmap.sh for the inspiration!

---

Before the review

Prior to diving in the code changes, gather information about the pull request:

• Read the pull request description. Hopefully the author has included the user story with its purpose and requirements, a list of code changes, and screenshots (if applicable).

• Brainstorm and assemble a list of potential bugs or security risks that could get introduced.

• Determine the depth in which you should review the code.

• Be aware of any relevant documentation that should be updated.

• Check your mindset. You are reviewing only for the good of the codebase and the team, not to show off your knowledge or start an unnecessary argument.

During the review

Now that you have all of the background information, dive into the content of the pull request:

• Validate that the author is targeting the correct branch (this will depend on how your team handles release branches).

• Review all changes to ensure that the code change fills the user story requirements. (This step should be completed prior to providing any feedback.)

• Be respectful and professional in your feedback. Remember it’s feedback, not criticism.

• Consider the overall quality of the code: readability, maintainability, and scalability.

• Identify any performance or security concerns.

• Ensure that the code change adheres to the project’s coding standards and best practices.

• Make sure that the new code is following the style guide set by the organization or team.

• For suggestions that does not require a change, add a resolved comment to make the author aware.

• If the pull request is large and/or complex, pull the branch and test locally.

• If further explanation/discussion is needed, ask the author to set up a meeting.

After the review

After the initial round of feedbacks, you will need to work with the author to complete the request:

• Consider pair programming if a large or major change is required.

• Be open to feedbacks, conflicting opinions, or questions/concerns from the author and be willing to make adjustments.

• Resolve conflicting opinions quickly that could prevent the pull request from completing.

• Review the updated code to ensure that the suggested changes have been implemented.