To Code Review or Not to Code Review…

Introduction

During their careers, developers are likely to encounter numerous approaches to code reviews. Some organizations will demand multiple approving peer reviews before any code change can be merged in or will even have dedicated weekly meetings to review all code changes as a team. Other companies bypass code reviews completely, never even mentioning the process. This dichotomy leaves developers with an unanswered question of whether code reviews should be done or whether they are unnecessary.

To Code Review

There are numerous reasons peer reviews are beneficial. Most of these benefits are centered around the adage that two pairs of eyes are better than one.

One of the most common and obvious benefits is that junior developers and developers working in a new language or technology have the security of having more experienced peers checking over their code. It is always better to catch bad or inelegant code as early as possible, so the more checks and balances we implement, the more likely we are to safeguard the production environment.

In addition to protecting the code base, peer reviews aid developer growth. It is easier to stop a bad habit at the beginning than trying to change it later. By developers having immediate feedback from their peers and being forced to update their code before moving on, they are helping accelerate their learning and ensure that they know the tried and true way of doing things rather than having to reinvent the wheel themselves.

Inexperienced developers are not the only ones to professionally benefit from code reviews. Even the most senior and experienced developers have things to learn or new points of view to consider. In fact, many are in the habit of being the technical lead so much that they get into a comfort zone of thinking they are well versed and not in need of other’s involvement. However, this is a dangerous situation to find yourself in. No man is an island. We all need to hear different points of views from time to time. It promotes discussions, refinement, and growth.

Finally, in a team environment, code reviews help to promote knowledge sharing and cleaner code. Even if a developer has worked in a technology and project for years, they are unlikely to know every aspect of the code base. There might be knowledge within the team about why something cannot be done in the usual fashion or about a utility in the application that promotes cleaner code or a business level requirement. By performing peer reviews, this knowledge is more likely to be spread amongst team members and result in a better product.

To Not Code Review

The main and perhaps sole reason not to do code reviews is that doing them increases the time demands of your team and delays delivery of features. Without peer reviews, you often have only one resource involved in changing code and getting it delivered to the testing environment. Implementing code reviews requires the time for someone to read and consider the code changes. If discussions result or changes are needed, even more time is used up that could be focused on other features. Although using experienced developers that have a good general knowledge of a project can lessen the time burden of the review process, it will always require some time dedication. In a critical or fast passed project, even minimal time commitments can take a large toll on goals and make code reviews unfeasible.

Conclusion

In the end, there is no denying the overwhelming benefit that peer reviews provide. They not only safeguard the production environment and ensure clean and correct code but help developer growth and knowledge sharing. However, it is also clear that doing code reviews introduces a large amount of work to the team. This can be mitigated by defining how extensive the peer review process needs to be and by using well-versed and experienced developers. It is up for each development group to decide the amount of time they are willing to dedicate to get the amazing benefits of this process.