Software engineers need to do code reviews in order to improve overall product quality and learn from each other. 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.
Not more than 400 lines of code is sent for code review
Reviewer 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 will allow reviewing changes regularly during a few days of feature development.
Code review task has a higher priority than the development one
Pull request should not be in Open status for a long time. The longer it’s open the more chances to get merge conflicts. That’s why software engineer should put away his or her 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 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 reviews
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 I need to look at during a review?”. The checklist can include some general considerations like “Is new code covered by unit tests”, “Are there any code duplicates” and some project-specific stuff if needed.
The software engineer receives a comprehensive feedback from 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!
Top comments (0)