Code reviews are an integral part of the software development process; they help you focus on the most important issues. Why should you make code reviews a priority?
In short, a code review (CR) is the process of reviewing someone’s code before it’s merged into the existing codebase. Whenever developers want to make some code changes, they create a pull request (PR) to initiate a CR. Then, selected developers review the code and share their feedback.
Building a code review culture in the team is important for code quality and enforcing consistency in a codebase. When new standards appear, they should be discussed and approved by the team. Here’s how you can make CR more effective.
Best practices for code review
First, minimize the delay in starting a CR. The ideal situation is when the time from creating a PR to a completed CR doesn’t exceed one day. To make the CR more effective, focus on the PR scope, break PR into smaller chunks, and review up to 400 lines of code at a time so that it’s easier to make changes to specific parts of the system. Working this way will also improve and speed up the process.
When reading through the code, start looking at the changes at a high level. Focus on core issues, and look for architectural or structural problems, removing duplications and bugs. Then, lower the level of abstraction and break things down into smaller pieces. Your comments should concern unnecessary code or the need to use modern technology. Things such as badly named variables or styling issues are minor tasks that can be pointed out last.
Note that CR may be an iterative process because the new version of the code that includes the reviewer’s feedback might need a revision.
Foster a positive culture. It’s better to ask questions than make statements and demand changes. When you leave CR feedback, how you comment on the code is usually more important than what you’re saying. Be kind and respectful, and give examples. For instance, instead of writing, “You’re wrong. Change it!” say “Consider splitting this component into a separate function like this: [code example below]” or “What do you think about splitting …”
Another good practice is to avoid addressing the code author directly. Instead of blaming your colleague, it’s better to write impersonally or use “we” as the subject. If you suggest a code change or totally new approach, explain the reasons behind your decision, give guidance based on common rules (not your opinion), and make sure your feedback adds value. Your examples should be based on documentation and thought leaders’ articles. Also, avoid repeating comments regarding the same errors across the same PR.
Code review should be an objective collaboration and discussion, not judgment. Here at Studio Software, we always assume that the reviewer’s comments come with good intentions. If we don’t understand some part of the code, we simply ask the author for clarification.
Last but not least, if you’re a reviewer, remember to reward developers and leave them positive comments and express appreciation if the code is good. A CR is an opportunity for both authors and reviewers to learn, so as an author, keep an open mind and show gratitude to the reviewers. Also, don’t expect a drastic increase in quality right after the first PR. Sometimes, it needs more round.
Code review benefits
The number one code review advantage is making the code work better by improving its quality, avoiding broken builds, and finding bugs before they reach production. Another important one is knowledge transfer—team members are more familiar with the codebase and are on the same page.
Overall, CRs raise team standards. Developers educate one another on how to write better code, look for alternative solutions, and understand business problems. Especially that code reviews are also held as regular meetings (e.g., once a quarter) to discuss the code in a broader context so that the team knows what can be improved for the next review cycle.
CRs make the team communicate better and collaborate so that people are more engaged, and there is more trust among your team. They’re also a way of gaining knowledge and learning new things while both reviewing and getting feedback. Moreover, CRs may be a great solution to improve developer onboarding.
A handy checklist for code review
To sum up, here’s a checklist to follow to conduct an effective code review and speed up the process:
- Does the code work?
- Is the code clear and easy to understand?
- Is the code written following coding standards and design principles, such as SOLID, DRY, KISS, etc.?
- Does the code match the patterns that your team has already established?
- Are there redundant comments—for instance, why an author implemented a certain solution instead of what or how something was done?
- Do the comments specify any hacks, shortcuts, or temporary fixes?
- Are variable and function names self-descriptive? If so, are comments still needed?
- Does the functionality work the way end-users expect?
- Are the libraries or external dependencies well documented and maintained?
- Are the exceptions well described? Are the exception error messages understandable? Are they supported?
- Is the modified code left in a better state than it was found?
- Is an algorithm in the code written in the most efficient way?
Use these tips and share them with your company!
