 |
| Photo by Bochelly |
Code reviews are methodical assessments of code designed to identify bugs, increase code quality, and help developers learn the source code. Developing a strong code review process, or utilizing version control, sets a foundation for continuous improvement and prevents unstable code from shipping to customers.
Software developers should be encouraged to have their code reviewed as soon as they’ve completed coding to get a second opinion on the solution and implementation. The reviewer can also act as a second step in identifying bugs, logic problems, or uncovered edge cases. Reviewers can be from any team or group as long as they’re a domain expert. If the lines of code cover more than one domain, we should have experts from both domains.
Benefits of Code Review
Knowledge Sharing:
When software developers review code as soon as a team member makes changes, they can learn new techniques and solutions. Code reviews help junior developers learn from more senior team members, similar to how peer programming effectively helps developers share skills and ideas. By spreading knowledge across the organization, code reviews ensure that no person is a single point of failure. Everyone has the ability to review and offer feedback. Shared knowledge also helps team members take vacation, because everyone on the team has background knowledge on a topic.
Discover Bugs:
Rather than discovering bugs after a feature has been shipped and scrambling to release a patch, developers can immediately find and fix problems before customers ever see them. Moving the review process earlier in the software development lifecycle through unit tests helps developers work on fixes with fresh knowledge. When waiting until the end of the lifecycle to do a review, developers often struggle to remember code, solutions, and reasoning. Static analysis is a cheap, efficient way to meet business and customer value.
Maintain Compliance:
Developers have various backgrounds and training that influence their coding styles. If teams want to have a standard coding style, code reviews help everyone adhere to the same standards. This is especially important for open source projects that have multiple individuals contributing code. Peer reviews bring in maintainers to assess the code before pushing changes.
Enhance Security:
Application security is an integral part in software development, and code reviews help ensure compliance. Security team members can review code for vulnerabilities and alert developers to the threat or even setup the quality gates in static code analysis to make sure they are identified well ahead. If your application is dealing with sensitive information then team should be trained on secure coding practices.
Increase Collaboration:
When team members work together to create a solution, they feel more ownership of their work and a stronger sense of belonging. Authors and reviewers can work together to find the most effective solutions to meet customer needs. It’s important to strengthen collaboration across the software development lifecycle to prevent information silos and maintain a seamless workflow between teams. To successfully conduct code reviews, it’s important that developers build a code review mindset that has a strong foundation in collaborative development.
Best Practices
What to look for during the code review
It’s important to go into reviews knowing what to look for in a code review. Look for key things like code structure, style, logic. performance, test coverage, code readability and maintainability.
You can do automated checks (e.g., static analysis of the code) for some of the things like structure, style, standards and logic. But others areas like design and functionality, requires a human reviewer to evaluate as we don't have any tools for the same.
Reviewing code with certain questions in mind can help you focus on the right things. For instance, you might evaluate code to answer:
- Do I understand what the code does?
- Does the code function as per the requirements?
- Does this code has been written as per the company standards requirements?
Build and Test — Before Code Review
In today’s time, we have Continuous Integration setup as part of the process. It’s key to build and test before doing a manual review. Ideally, the code review should be done after tests have passed. This ensures stability and doing automated checks first will cut down on errors and save time in the review process.
Limit Review Time for 45-60 Minutes
Never review for longer than 45 - 60 minutes at a time. Performance and attention-to-detail tend to drop off after that point. It’s best to conduct code reviews often (and in short sessions). Taking a break will give your brain a chance to reset. So, you can review it again with fresh eyes.
Review 300 Lines at a Time
If you try to review too many lines of code at once, you’re less likely to find defects. Try to keep each code review session to 300 lines or less. Setting a line-of-code (LOC) limit is important for the same reasons as setting a time limit. It ensures you are at your best when reviewing the code.
Give Feedback that Helps
Try to be constructive in your feedback, rather than critical. Be kind, explain your reasoning, balance giving explicit directions with just pointing out problems and letting the developer decide and encourage developers to simplify code or add code comments instead of just explaining the complexity to you.
Giving feedback in-person for the new members will help you communicate with the right tone as they will be new to the process.
Communicate Goals and Expectations
You should be clear on what are the goals of the review, as well as the expectations from reviewers. Giving your reviewers a checklist will ensure that the reviews are consistent. Engineers will evaluate each other’s code with the same criteria in mind.
By communicating goals and expectations, everyone saves time. Reviewers will know what to look for — and they’ll be able to use their time wisely in the review process.
Include Everyone in the Code Review Process
No matter how senior the engineer is, everyone needs to review and be reviewed. After all, everyone performs better when they know someone else will be looking at their work. When you’re running reviews, it’s best to include engineer and leads/architect. They’ll spot different issues in the code, in relation to both the broader codebase and the overall design of the product.
Including everyone in the review process improves collaboration and relationships between programmers.
Automate to Save Time
There are some things that reviewers will need to check in manual reviews. But there are some things that can be checked automatically using the right tools. Static code analyzers, for instance, find potential issues in code by checking it against coding rules. Running static analyzers over the code minimizes the number of issues that reach the peer review phase. Using tools for lightweight reviews can help, too.
By using automated tools, you can save time in peer review process. This frees up reviewers to focus on the issues that tools can’t find — like usability.
