Code reviews, when implemented effectively, can provide a valuable set of benefits to a software development organization. Most of these benefits derive from the feedback mechanism that code reviews add to the software development process. By nature, most software engineers have a tendency to work in isolation. While they intimately understand the code that they develop, often no other team member does. This results in the software code base being divided into discrete silos, each with varying conventions, quality levels, architecture and ownership. If an organization loses a software engineer, the silos owned by that engineer often fall into disrepair or become abandoned due to the lack of understanding of the code contained therein. Code reviews can help prevent the formation of silos in the first place, thus avoiding such problems.
Most organizations implement code reviews as a means of improving the quality level of the code base. This is certainly one of the primary benefits of code reviews, and it is usually quite easy to achieve some level of quality improvement with any code review process. The magnitude of quality improvement will depend largely upon the effectiveness of the implementation of the code review process. Quality improvement are generally achieved in several ways as follows:
- Bug identification – reviewers can often spot bugs that the implementer missed. Most often, the type of bugs that are found during code reviews are the fairly obvious ones that can be spotted quickly. Obscure logic flow bugs are not often found during code reviews due to the amount of time that it takes to analyze such problems. Every bug found during a code review is one less bug that needs to be found through testing and debugging processes, which can result in significant time savings.
- Thorough error handling – Whether due to laziness, forgetfulness or other reasons, software engineers frequently omit checks for return codes, validation of input parameters, exception handlers, assertions and the like. These omissions are easy for a reviewer to spot and point out. Good error handling can help avoid or detect many classes of bugs.
- Added documentation – I have often heard software engineers claim “my code is so readable that it doesn’t need comments”. This misconception is due to the fact that the implementor understands the intent of the code, and simply assumes that anyone else will too. Such is rarely the case for all but the most trivial bits of code. Even if a reviewer can derive the intent by a detailed study of the code, the process of understanding the intent can be significantly accelerated through sufficient documentation in the form of code comments. Added documentation improves code quality by making it more understandable to others, and thus of greater value to the software organization. Also, it is not uncommon to discover logic bugs or architectural flaws while documenting the intent of the code.
- Alternate implementations – there are often many ways to implement a particular bit of functionality, and reviewers are often well suited for providing a different way of addressing a given problem. While the end result may be the same, alternate implementations can often provide improvements in performance, scalability, capability and extensibility or help reduce the complexity of the implementation.
- Code reuse – The amount of functionality available in platform SDKs, third-party libraries and a company’s own code base covers most of the commonly used algorithms and data structures that a software engineer would need. Yet, frequently the software engineer repeatedly chooses to reinvent the wheel, creating their own implementation. The most common reason for this occurring is the lack of knowledge of the pre-existing functionality. Having someone review the code provides another opportunity for such pre-existing functionality to be identified as an alternative to rewriting the functionality. In most cases, using pre-existing code improves quality because that code has generally already been well tested. It also improves the maintainability of the code base by reducing its size and complexity.
Another important benefit of code reviews is the training that automatically results as part of the process. Training during code reviews is bidirectional. The reviewer is trained on the new code developed by the implementor, while the implementor is trained by the recommendations made by the reviewer. Simply the act of having one engineer review another engineer’s code ensures that more than one individual is familiar with and understands the implementation of that code. This is a critical step toward tearing down the silos. In order for the reviewer to sufficiently understand the code changes, he or she needs to invest a meaningful amount of time reviewing the code. The amount of time necessary is generally proportional to the number of lines of code. As a general rule, a reviewer should spend at least one minute for every ten lines of code changes, plus whatever time is needed to comment on the changes. Having more than one person review code changes helps to further spread the knowledge and understanding of the code implementation across the team. Code reviews are also an excellent opportunity for senior engineers to mentor less experienced engineers. It is important to have the junior engineers first attempt to work through the implementation on their own, but the subsequent review by a senior engineer can then provide a valuable critique of the work along with constructive suggestions for improvement. So long as the recommendations are made in a positive, nuturing manner, this can result in accelerated learning on the part of the junior engineer, thus increasing their productivity and effectiveness as a member of the team.
Many software organizations establish a set of coding standards to ensure that the software developed conforms to certain conventions. A good set of coding standards can help ensure that the organization and implementation of code is fairly consistent across the organization, making it much easier for an engineer to work on code developed by another. Thus, standards also help to avoid the creation of silos. Standards should not be so inflexible as to stifle creativity or personal style, but rather encourage good practices that help to make code easier to maintain. Code reviews are an ideal point at which to enforce coding standards. Along with identifying other problems with the code changes, the reviewer should also point out any violations of coding standards so that they can be addressed prior to committing the code changes.
As a means of counteracting the naturally independent nature of most software engineers, code reviews help to increase the amount of collaboration among team members. While some initial resistance to such “forced” reviews is often encountered, the engineers eventually realize the value of getting regular feedback and critique of their work. They often learn a tremendous amount in the process, increase their productivity, improve their code quality and conversely decrease the amount of time they have to spend debugging. Once software engineers realize the value provided by their peers and mentors via code reviews, they will often seek out their input more frequently in other contexts such as during design work. The effect of this increased collaboration begins to touch on virtually all aspects of the team’s operations, increasing the synergy and effectiveness of the group as a whole.
There are few arguments against doing regular code reviews. They are generally accepted in the software industry as a best practice. The main opponents of code reviews are those who claim that other practices such as pair-programming and test-driven development are more effective at reducing software defects. I’ll reserve a comparison of those practices for a later date, but most teams will find that code reviews are easier to adopt than those other practices.
When it comes to reducing software defects, eliminating code silos, increasing team productivity and collaboration, code reviews are a powerful tool in the software development process. If your software team is not yet doing code reviews, then get started.