Do Code Reviews Really Matter?

Having a second set of eyes to review code is key to catching potential problems. You might already be using linters in your projects, but code reviews provide a method of enforcing coding standards that are difficult to automate away.

Code reviews provide a learning experience for developers of all levels. When new or junior-level developers review code, it's a chance to get more familiar with the application. Being able to see how other developers solve issues is a great learning experience.

The code review process also gives developers an opportunity to ask questions and discuss more effective solutions. As these discussions grow they can produce reusable solutions and serve as a reference for future coding standards. This type of collaboration leads to better team communication and creates a more inclusive environment as everyone can contribute.

Effective Code Reviews

The Ground Rules

The most important rule of code reviews is to be kind. Once upon a time I worked for a company with a highly competitive and defensive culture when it came to reviewing each other's code, that is not how you do code reviews. Code reviews aren't a platform to put anyone down or put yourself higher, it's about working as a team to sharpen each other and release a higher quality product.

When you need to address potential problems in the code, try to offer suggestions instead of accusations. Think comments like these:

• "Is there a better way to handle this?"
• "If you rewrite it like this, it could make the code clearer,"

...instead of:

• "This is wrong, do it over again!"

If there's a serious issue with the code, address it with the developer in private to avoid turning the situation into public shaming.

Who Participates?

As I mentioned above, developers of all levels should review code (and have their code reviewed) by all other developers.

Effectiveness

Address all review comments, even if it's just an acknowledgement of the issue that you'll handle later. When someone makes a suggestion, don't simply make the change, unless you fully understand why the code should change, and that you agree on the change; this is a group discussion. If you don't understand a comment, simply ask them to clarify. If you feel that your original solution is best, make sure to present your reasons; it could be that your approach is correct, but that the reviewer misunderstood your reason for taking that approach.

The code review process should be completely integrated it into your development process. Just as a client or manager would need to sign-off on the product, code reviewers should sign-off on the code. Create a review for every new feature or bug-fix, don't make exceptions. You might save a bit of time by not doing it, but you'll lose that time having to fix an issue which could have been caught. On top of that, everyone loses out on the learning experience of reviewing the code.

An effective code review process should have an approval step. I recommend requiring at least one or two other developers to "sign-off" or approve the code review. Don't skip this either; once you start circumventing a rule, it can become a habit, and you'll lose out on any benefit to having that rule.

Correcting Code Before the Code Review

To avoid repeatedly bringing up common issues in code reviews you'll want to automate as much as possible. First, put together a list of coding standards (spaces vs tabs, indentation, location of braces, etc.) in place where every developer can access and easily update. Developers should review these standards before starting development.

In order to enforce these standards, you'll want to leverage tools like linters and .editorconfig. Many IDEs support these and are able to provide immediate feedback to the developer, increasing overall code quality long before the code is even committed or reviewed. In addition to IDE support, you can use Githooks to automatically run your linter when a developer attempts to commit code. This automation not only makes the development process easier, but it takes the burden off of code reviewers as the common potential code issues have been covered.

Code Review Tools

While having any code review process is better than no code review process, you'll really want to use a system which offers line-by-line commenting, and some type of approval process.

To be effective, the code review process should be integrated with your source control system (you are using source control, right?) If you're using Git, then a code review would typically occur during the pull request process. Git front-ends such as GitHub and Bitbucket provide tools to review and comment on code, as well as options to approve the code.

If you're using a source control system other than Git, Crucible is a good choice. It is able to integrate with various source control systems and provides functionality to perform everything discussed above.

Some other popular code review tools are Phabricator and Upsource which both offer some type of free version.

The Time is Now

Hopefully at this point you have a better understanding of the benefits of code reviews, and how to incorporate them within your workflow and within your team. I encourage you to start using code reviews now, and if you already are, to use some of these ideas to maximize their benefits. Let me know how you're using code reviews within in your team; what's working and what's not.