The importance of code review

Translator: Yawenina

The original link

I recently read on Twitter:

Unfortunately, it seems that code review is an unfamiliar practice for many students, freelancers, and organizations.

Obviously, the usefulness of code reviews is not particularly obvious to everyone. Maybe I’m naive, but I really think this is the process that should exist in all IT companies. Obviously I was wrong, and it scares me.

In this article, I’ll talk about my thoughts on code review, why I believe code review is important in code shippng, and how we can start using it. If you don’t have code reviews, or if you want to do better, I hope this article helps!

What is code review?

We live in the age of Wikipedia, so let me start by giving you a definition of Code review:

Code review is a systematic review (sometimes called peer review) of a computer’s source code. Its purpose is to find errors that go unnoticed during the initial development phase and improve the quality of the software. Reviews can take many forms, such as pair programming, informal and formal inspections.

Code review, as its name suggests, is the process of reviewing code to make sure it works and improve it as much as possible.

Method of code review

Why is reviewing code important

So why should code review be important? After all, we are all capable people. Of course we can hand over code without looking over our shoulder as if we’re doing everything.

In theory, yes. But in reality, there are many reasons why having an established code review process is helpful. Let’s look at some.

It limits risk

This is probably the most important reason of all. Having someone double-check our work doesn’t hurt us and shows errors that go unnoticed. Even good developers sometimes think poorly in one area.

It’s usually nice to make sure you haven’t forgotten anything. For example, proper keyboard navigation, screen reader accessibility, internationalization flexibility and friendliness, non-javascript behavior are often forgotten in the front-end world.

It dramatically improves code quality

Let’s make things clear: this is not about standards and code static analysis (at least not entirely). It’s about making code more efficient.

In a team where everyone has their own background and habits, it’s always a good idea to ask for improvements (because that’s what code review is all about). Someone can come up with a smarter solution, a better design pattern, a better way to reduce complexity, or improve performance.

It makes everyone better

By forcing it, everyone can learn and get better. Code submitters can receive feedback on their work, making them more aware of possible problems and areas that can be improved. Code reviewers can learn new things by reading code and apply appropriate methods to their work.

It helps people become more familiar with the project

When a team is working on a project, it is not possible for every developer to work on every aspect of the application. Sometimes one developer may be working on one big aspect at a time while another is working on something else.

Code reviews help people become familiar with code they didn’t write but might be assigned to maintain in the future. It promotes knowledge of the entire team’s code base and has the potential to speed up future development.

How to use it properly

Again, having an established code review process is very useful and important. Every team that writes code should have code reviews in one way or another.

That said, doing meaningful and useful code reviews is not always as easy as it might seem. Don’t worry, he won’t bite you if he does it badly. It may not be that useful, it may be a waste of time.

Recently at my workplace, we did a review of our code review process. When we found out that only three of our 12 developers were involved in the code review, we realized that maybe we weren’t doing something right.

To help us change this, one of our Scrum masters organized a review to determine where there was room for improvement and how to implement it.

Plan ahead

The most common argument that people give for not participating in code review is that it takes time — people don’t want or want to spend time.

I have to say THAT I really don’t understand this reason myself, because I think of it this way: if a colleague comes to me directly and asks me to help them, I don’t say — “No time, no interest”. I will find time to help them. Maybe not now, maybe in an hour — but I’ll make time for them. Why is that? because

That’s part of what it means to be a team
If they need my advice, it’s because they think it’s one way or the other and, therefore, it makes sense to help them.

“You don’t participate in code reviews?”

“I don’t have time”

To me, a pull request is no different from a colleague asking for help. Sometimes it’s a good excuse to say you don’t have the time, but by systematically refusing help, you’re actively pushing yourself out of the team. It’s not friendly or positive. Find the time to help.

In order to find time for developers, we started thinking about having each developer spend a few minutes a day (about 30 minutes) on code review. There were no more surprises when we finished a day and a half of code review: it was part of the day.

We also tried to significantly reduce the amount of pull requests that make up the code. We used to have a lot of pull requests — thousands of changes in dozens of files.

We try not to do that anymore. With a small number of pull requests, we made vetting easier, feedback more relevant, and developers more willing to participate in the process. “Handoffs are small and frequent.”

Provide context

The second biggest problem we find is that we often lack an understanding of the context of the code, especially when you’re providing helpful feedback. In the absence of context, what we usually do is a grammar check — sometimes useful, but not enough. You may simply become a “human checker.”

Fortunately, the solution to this problem is relatively simple: add a description to the pull request to explain what the topic is and how to get there. It doesn’t need a lot of words; A few lines are usually enough. Adding a link or story to an issue is also helpful. Liv Madsen, one of our developers, even added screenshots — or related videos — to illustrate what she did, which was amazing.

! [give a pull request to provide the context of the descriptive text or screenshots or a video]] (dab1nmslvvntp.cloudfront.net/wp-content/…).

ask

The third issue we raised was that sometimes we didn’t know there was code we needed to review. Let’s face it, we’re inundated with emails and reminders every day — it’s hard to keep track of them. After all, we are only human.

The solution is simple: Request a code review. There are plenty of ways to do this, like honking your horn in the office or ping someone on Slack for someone on your team.

We build teams on Github based on our activities, then submit pull Requests, and we’re usually evoking a team. Members will receive the prompt and can deal with it when they have time. Sometimes we tell one or more developers directly when the job clearly belongs to someone. That’s also useful.

In this case, tell people they can review the code and leave comments. Sometimes there’s nothing explicitly to report — just a reminder that the code can be integrated, for example, and we leave comments.

Because we sometimes blindly integrate code without regard to the comments left, we have a strict “reply or fix” policy. When you receive feedback, you need to fix the code or reply to the reason why you are not integrating. In any case, you never leave a pending comment, and you never pull a request with an unprocessed comment.

conclusion

Having a regular and effective code review process is essential to maintaining high standards of quality code, as well as helping the team grow and share learning among developers.

Seeking code reviews is not a sign of weakness. There’s nothing embarrassing about asking for help, and neither is code review. Take feedback from others and give constructive comments to the people who submitted the pull request.

Find what works for you. Reviewing code should be a big part of the code transition process, so you should use it on your team. Make it do what you want it to do so it can help everyone.

Happy reviewing!