In March, during PHPers Silesia in Gliwice, Poland, I talked about code review—how it builds and strengthens team relationships. If you didn’t attend the presentation, in this article I’ll highlight key elements and further explore the topic, sharing with you how exactly code review benefits the whole team, helping developers deliver better products.

The Code Review Dilemma

Many of you probably came upon the process of code review when working on the code. For some, it was great, for others, plain torture. But most of you surely encountered the negative side of code review, questioning the viability of this process in software development.

Code Review Explained

Code review can be implemented in three variants of team structure:

#1. When we work in one team where all developers are from the same company and build a custom product.

Here, every developer on the team is more or less aware that the product in development is important for the company, and that everyone who participates in its creation plays for the same team.

#2. When we work in one team but the developed product is for one of the many clients of the company we work at.

In this case, the developers sometimes do not feel equally responsible for the project. With a lower sense of accountability, the developers might be less likely to ensure the best quality of the end product.

#3. When we work in a mixed team of developers from our native company with developers from other companies, hired by the client.

In this setup, it’s difficult to find a common responsibility factor for the project or foster awareness that all parties involved play for the same team. Additionally, there are also matters of rivalry between developers and companies that both lead to a rather difficult task set for code review.

The Benefits of Code Review

Before I explain how to start “humanizing” and polishing the process of code review across various team structures, I’ll list out the benefits it brings.

Contrary to what many probably think, code review does much more than just improve project and code quality. Click To Tweet.

Thanks to code review, we have an opportunity to learn how to program from others and discover coding techniques of fellow developers. I know that people tend to think their own solutions are the best, but in most cases, it’s not true.

Programming allows us to reach the same goal using many approaches. And many of those approaches are as good as the solutions and methods we’ve been using for years. The best example here is the never-ending war of spaces vs. tabs. Both solutions have their own benefits and drawbacks, but in reality, the two are equally good—the only thing to keep in mind is to use the same solution across the whole project.

Code review is also an excellent way to learn about a project and be up to date with its development, especially when we’re dealing with complex systems made by large teams of developers.

It’s a myth that junior developers shouldn’t participate as reviewers in code review. Actually…

Every dev, either with little experience or when being new to a project, should participate in reviewing every fragment of the code. It’s one of the most effective ways to learn how the project functions and what are the rules of the team. Click To Tweet.

Of course, in that case, a less experienced developer shouldn’t be the only reviewer, but can conduct the first review of a particular pull request, merge request, etc., and then leave the final approval of the code for someone with more project experience and a higher awareness of the client’s business.

How to Control Code Review

How can we control the process of code review when we conduct it in mixed teams for a completely remote project to us so that the review generates positive results?

First, we should start by creating a shared document with rules pertaining to a particular project. Thanks to a simple outline of project rules, we’ll be able to eliminate most of the redundant discussions that often take part in the comments section of the code in review.

In the document, there should be information such as:

• Coding standards
• Description of the structure of the project and data
• Rules for handling the code repository
• Description of the process of code review

If we’re unsure what exactly should be in such a description, it’s worth taking a look at the archived discussions that happened during code review in other projects. It’s also good to actively follow pull requests. Whenever we see that a particular discussion could have been avoided based on the rules outlined in the document, we should add a specific rule that covers how to solve that specific problem.

Let’s remember that the document should be rather easy and short, so everyone involved in the project could refer to it whenever unsure about something.

Another aspect is enforcing the usage of specific tools that automate work done manually before. Here, I’m talking about all sorts of linters, which are tools for code review based on specific rules such as the type of line indents, rules for naming the variables, methods, etc.

If we eliminate things like checking the formatting of the code during every code review, we not only save lots of time but also avoid many unnecessary discussions. Why waste time when something can be done quickly and efficiently by a “machine”?

Last but not least, is choosing a decision-maker in the project—a person who will always make crucial project-related decisions. That person can be the team leader responsible for a team of developers, or the architect who designs the whole system. They take responsibility for how the whole project looks like and they should know which solution fits it best.

The Reviewer as a Mentor

When we eliminate most of the easy problems and mistakes made by developers, we can then start doing really effective work as a reviewer.

We have to keep in mind that the role of the reviewer isn’t to point out mistakes and disparage other developers. The reviewer should be the guardian of the code but also the mentor for others. Reviewing is not about showing that we know more than others or that we can look at the code from a wider perspective and see things that a developer missed.

In fact, the worst we can do is to blindly point out mistakes without providing any information about what could have been done to make a part of the code better. If we see there’s something wrong with the code, we should help a developer and suggest a different method to solve a problem. Let’s not be egoistic. When being reviewers, most of us are also one of the programmers on the project. We’re all playing for the same team, and when someone fails at their task, it’ll make itself known in the lower quality of the end project.

How to Approach Code Review

Our current state of mind has a big impact on the quality of our review. We definitely shouldn’t begin reviewing the code when we’re tired or nervous. To effectively review the code, we should set aside an appropriately long chunk of time free of other responsibilities, for example, in the morning, just after coming to work. At that time of day, we’re usually relaxed and fresh, ready to tackle issues that will come up during code review.

How to Receive Code Review Feedback

Many of us forget that, when working on the code as developers, we’re responsible not only for the project itself but also, to a certain extent, for the business results of our client. It’s a big responsibility, so even if a reviewer negatively evaluates our changes in the code, he or she doesn’t do it because they don’t like us, but because they care about the project.

All of us are prone to make mistakes, but when we do, we shouldn’t be afraid to admit and fix them. When someone points out our errors, many of us too often fail to admit to our mistakes, even when we know we’re wrong. We should learn that there are cases where we don’t know the perspective of a specific business and our assumptions aren’t always accurate. Sometimes another programmer who knows the client and their business better has a broader perspective on the project and is able to find issues we wouldn’t have otherwise thought about.

And what if we really believe or are certain we’re right? Our team leader—the decision-maker on the project—will be able to address our uncertainties. The team leader takes the final responsibility for the whole project, and we simply have to trust the decision the team leader makes.

Code Review Makes a Team Stronger

Let’s remember that code review is first and foremost a process that should evoke constructive discussions where everyone is open to the arguments of others, without causing fights. Code review also isn’t a place for rivalry between developers from other companies.

All of us should do our best during code review—both as a reviewer and a person being evaluated. The worst that can be done during code review is fighting in the comments section and forfeiting project quality and the implementation of new solutions.

Code review contributes to the delivery of good quality software solutions, strengthening team bonds during their development.