Code Reviews
Three Best Practices
Establish a clean objective
Start by identifying the purpose of the review. You should be aware what exactly you are looking for in a review. This could be functionality, performance, security, etc. Also establish the scope of the review, such as specific functions, files, and modules.
Communicate these objectives and scope of review to everyone involved, so that they understand what is expected of them.
Action items:
- If you’re using a ticketing system (Jira, Git host issues, help desk) reference the ticket number in the commit message and pull request summery.
Focus on the code, not the person
Having someone else review your work is always going to produce some stress. Be sure to keep the focus on the code being reviewed, and not the person who wrote it. Avoid using critical or judgmental language. It is a shared code base and so any feed back should be that any feed back in a code review is cascaded to the rest of the team.
Action items:
- Focus on specific issues with the code and provide constructive feedback on how to address them.
- Be respectful and courteous when giving feedback. This helps to create a positive and collaborative environment for the review
Provide actionable feedback
It’s important to be specific and provide actionable feedback that the developer can act upon when reviewing code. Instead of saying, “this code is bad”, you could say “this function could be simplified by using a ternary operator instead of an if-else statement.” This gives the developer a specific task to work on and helps them improve the code.
Action items:
- When giving feedback, try to focus on the most important issues and prioritize them based on their severity and impact on the code. This can help the developer address the most critical issues first and improve the code more quickly.