Software Engineers use Code Reviews to Improve Product Quality

Software engineers need to do code reviews in order to improve overall product quality and learn from each other. The code review process has a set of best practices like any other complex processes. Check best practices below. Do you follow them on your current project?

Each change in the source code is reviewed by at least one team member

Even changing a single line of code a software engineer can accidentally break the whole application. Configure your CI environment so that it’s not possible to push changes to the main (master, development) branch bypassing code review flow and approvals from the team members.

Code review process is automated, not manual

Software engineers need to use code review tools like pull requests in GitHub, Crucible, Review Board, Collaborator etc. Some of you may be wondering what manual code review means.

“Manual” means that software engineer pushes changes to the main branch and then request a code review by writing a text message in Skype or Slack… The example may seem far-fetched, but unfortunately it happens.

No more than 400 lines of code are sent for code review

Reviewers cannot effectively review large pull requests. That’s why large functionality needs to be split into several smaller tasks during sprint planning so software engineers can send fewer lines of code for code review.

If it’s not doable, ask the team members to create draft pull requests and regularly commit changes. It helps to review changes regularly during the few days of feature development.

Code review task has a higher priority than the development one

Pull requests should not be in Open status for a long time. The longer it’s open, the more chances it has to get merge conflicts. That’s why software engineers should put away their current task and do the code review when requested.

It is possible to identify who was the reviewer

The reviewer is also responsible for the code, not just the author. So the team or stakeholders should be able to quickly identify who was reviewing given task to ask questions if any. The name of reviewer can appear in a Jira ticket or can be included in the commit message.

Reviewer should be able to log the time spent on code review

Usually code review is not a 5-minutes process, so the reviewer should be able to log his or her time spent on code review. Ideally, there should be ability to log time in the same task that the author logged his development efforts (for example Jira allows configuring different Work types like Development, Code Review for the ticket when logging the time).

The reviewer clearly understands acceptance criteria of the functionality he or she is reviewing

One of the key goals of code review is to understand whether the code fulfills requirements. So ideally the first step of code review process is to open Jira ticket and get familiar with acceptance criteria.

Code review checklist is used by the reviewer

Code review checklist answers the question “What do I need to look at during a review?” The checklist can include some general considerations like “is the new code covered by unit tests?”, “are there any code duplicates?” and other project-specific questions, if needed.

The software engineer receives comprehensive feedback from the reviewer

You as a reviewer shouldn’t just say “Refactor it!” or “Split the logic into two methods”, but need to explain why you requested changes. You should teach your teammates, so they will do the same for you!

Also published at https://programmingstuff.medium.com/code-review-best-practices-in-software-engineering-7ed39b83ef0b