As developers, we produce tons of code each day. We test our code, beautify it with code style scripts and finally verify using continuous integration commands, which control the integrity and cohesion of our solutions. Nevertheless, the true value of used code solution can be checked only by another developer, who knows the business domain, best practices, clean code principles and who may also have a different point of view from yours. In this article, I want to show you how code review can help you keep codebase in order and get more advantages for your team.

Let's Do the Code Review

What exactly is code review? In simple words, you can explain it as reading your code by someone else. And that's it.

One of the clean code principles is to write code that is readable for other human beings. Martin Fowler said:

"Any fool can write code that a computer can understand. Good programmers write code that humans can understand."

Code review is the first and critical check of this rule in real life. If your colleague cannot understand what you pushed to a repository, something went wrong.

Nowadays, you have tons of great tools to review your code, such as Github, Bitbucket, Gitlab and others. They feature a special UI, which lets you track changes and add comments in particular lines or even chars. In terms of usability, code review can be proceeded quickly and smoothly, even if your deadline is tight.

Team Building by Reviews

Programming is creative work, and as such, everyone sees it differently. A problem can have multiple solutions and each of them might be correct. If you do a review, you don't even focus on the code, variables or functions that much, but on the way your colleague has got to a particular point. It means you start seeing the problem through someone else’s eyes.

During the code review, you start thinking about the problem in new categories, you can see it from a different point of view. You also confront your way of thinking with someone else. Finally, you start discussing the particular pieces of code.

The last point has a great impact on relations in your team. All misunderstandings about the code are gathered in one place - in code review's comments. You can speak your expectations and doubts out loud and discuss them with the team, during the development process.

But! There is a huge danger in that approach; You have to keep your comments neutral. It's only your private opinion about the code, so say it as an opinion, not as a statement. Even if you are a technical leader or programming wizard, you have to respect your colleague's code and approach they choose. They could have made certain decisions for a variety of reasons, such as previous work habits or experiences from different technologies. Try to be open to new concepts, but always keep the good of the project and consistency in mind.

Of course, all these suggestions are valid when we're talking about concepts. When it comes to the rules of clean code, you have to be ruthless to all violations.

To keep the code review culture growing, the team needs to have clear review rules. Besides, each developer has to remember that code review is only an suggestion and help, not judgment. This approach builds strong, supportive teams, with solid foundations for further growth.

Keep Teaching, Learning and Evolving

If you're a writer, you practice by writing stories, of course. But first, you have to observe how other authors write their books. How they build characters, plan stories or resolve plots. With this baggage of knowledge, you can try to start your own work. Not by copying and pasting, but by picking the essence from their experience and transforming it to your needs.

This process is similar in programming. You become a better coder not only by writing algorithms or even whole applications. You become a better coder also by reading someone else's code. By doing this, you passively learn new approaches, new methods of resolving problems, you start thinking from further perspective about your own code.

You may think your code is perfect, but it's probably not.

"No one in the brief history of computing has ever written a piece of perfect software. It's unlikely that you'll be the first." - > Andy Hunt

No worries, software development is a process where we all learn from each other. Code review is one of the best tools, offering benefits for both sides - the reviewer and the reviewee. You can share your knowledge and experiences with other coders easily by giving suggestions for improvement. Make those comments derive from your programming skills.

The comments about unit tests could help your colleague understand the process better. Your disjointed code could be restructured with help from someone more familiar with Domain Driven Design, and so on. These simple examples show how powerful code review could be if you base it on true willingness to help and knowledge sharing.

Following Richard Feynman, we can learn new things only by explaining them in the simplest way to another person. Keep growing, learn new methodologies, share and discuss them with your colleagues, to keep your mind sharp and programming skills high.

Code Review Routine

As it was said in the beginning, code review is one of the early warning systems in programming. When you start checking each other's code, you'll see how many mistakes you miss in daily commits. This is the main reason why you should persuade your team to spend a couple of minutes per day on code checking.

Mature teams treat code review as a daily habit and no one in those teams can imagine to merge a pull request without checking. Here is some advice on conducting code reviews in teams and how we handle this in our daily programming routine.

• The more, the better. We always do code review with two or three people. If the project team in its current state is not big enough, we invite colleagues from other projects to support us. There are no excuses for that, even if you develop your project alone.
• Do it always - Code review is obligatory. Even if you want to push a small fix, you have to find someone to check your code. The best way to keep this rule valid is to set restrictions for merging to your repository, e.g. you need to have at least one approval from another developer.
• Schedule some time for reviewing - If your team is big and you make a lot of pull requests which have to be checked, the best option is to schedule some time for conducting code reviews. It doesn't disturb your work and you keep your pull request list clean.
• Make small changes - No one likes reviewing huge commits. When you plan to make a huge change in the codebase, break your work down into smaller chunks and send them for review. Small pull requests are merged way faster than the big ones.
• Fit the guidelines - Quite a lot of comments on code review are caused by style guide violations, especially at the beginning. If you put more effort into fitting your code to accepted rules, the whole process will take less time and the codebase will be more consistent.
• Read carefully - Code review is not a collective responsibility. You take full responsibility as a developer and a reviewer – both for your own code and for the acceptance of someone else’s code. Focus on reading and understanding the code you’re reviewing. Take your duty seriously.

Those small tips, which we use in our daily work, can help you conduct code review efficiently in your company. But before you start a revolution in your team's work, just talk to your colleagues and together create code review rules you’ll all accept. I hope the tips above will help you find a way to your code review routine.

The One-Man-Army Problem

Code review is efficient when conducted at least by two people. It may be a problem for a single programmer working on their own. How to handle this?

First of all, you have quit thinking that your code belongs to you and no one will ever look at it. There is always a possibility that you'll have to share your files with someone else. Don't let the code shame you.

Even if you work on your own, you shouldn't neglect code reviews. There are several methods to do this even in such situation:

• Do the code review by yourself - take the responsibility for your code, treat it as if written by someone else and put an effort to check it carefully. Create pull requests with your code into your repository and try to understand what you wrote afterwards. The problem with this approach is that you can check your code only with your own experience, so it could be not as efficient as code review from another programmer. The essence of team code review is lost.
• Send small pieces of code to your fellow programmers - you may ask befriended developers to take a look at your code, especially if it's an important part of your application. Just to be sure you didn't forget something. You don't have to share the whole codebase, just pick a few essentials and show them to check. In this case, you’ll have different points of view, but the reviewers may not have a lot of knowledge about the business logic, domain and context. It could cause some misunderstandings during the review.
• Send a piece of code to StackOverflow - StackOverflow is not only a service with solutions for any problem that comes to mind, but also a good place to show some piece of code and ask for a review. You can be sure that someone will answers you in a couple of minutes. The problem with this solution is similar as in the previous point. The lack of knowledge about the domain and processes.

As you can see, code review in a one-person project is not a tragic situation, but all of these solutions have some weaknesses. Nevertheless, you shouldn't say “no” to code review when working individually.

Summary

Practicing code review forces your team to educate at all times and share their knowledge with others. It builds a culture of growth and, if communicated in a neutral way, makes the professional relations stronger. Code review offers a lot of advantages at low cost and it should be the main point of the development process in your team.