As a developer, are you aware of these four types of code review methods?

This article translated from: Dzone.com/articles/4-types-of-code-reviews-any-professional-developer

Please specify the Source: Grape City website, Grape City for developers to provide professional development tools, solutions and services, empowering developers.

No one can guarantee that the code he produces must be perfect. The following is a description of the 4 main types of code review, and I believe that as a professional developer, you should be aware of them!

Every professional software developer knows that code review is a necessary part of any formal development process. But what most developers don't know is that code reviews are divided into many types. Depending on your project and team architecture, each type of code review has its own advantages and disadvantages.

I'll list the types of reviews for several kinds of code in this article, and explain in detail how they work each. And I'll give you some advice on when you're going to make a choice.

All right, let's get started.

First, at a very high level, you can classify code reviews into two main categories: Formal code review (formal Codes review), and Lightweight Code review (light weight Codes review).

Formal Code review

Formal code reviews are based on the formal development process. One of the most popular practices is the Vangen inspection method (Fagan inspection).

It provides a very structured process for trying to find flaws in the code, and it can also be used to discover flaws in the specification (specifications) or in design.

The Vangen inspection method consists of 6 steps: Plan (Planning), overview (overview), preparation (preparation), convening of an inspection session (inspection meeting), Redo (rework), and tracing (follow-up). The basic idea is to set the output requirements to be met in advance for each step. Next, when you proceed to a process, you examine its current output and compare it with the ideal output requirements that were previously made. Then, you decide whether you want to go to the next step, or you still need to continue working in the current step.

This structured process is not much used. In fact, in my career, I've never met a team that uses this approach, and I don't think I can see it in the future.

I think the reason for this is that this kind of process has a lot of overhead, and not many teams use it.

However, if you are developing software that is life-or-death and can be lost because of a flaw, it makes sense to look for software defects in such a structured way.

For example, you are developing software for nuclear power plants. You may need a very formal process to ensure that the final hand-over code is no problem.

But as I said, most of the software we do is not life-threatening, so we use a lighter-weight code-review approach as an alternative to formal processes.

So, let's take a look at this lightweight approach.

Lightweight Code Review

Today, lightweight code reviews are often used in development teams.

You can narrow down the lightweight code review into different subclasses:

1. Instantaneous code review, also known as pairing programming (pair programming);
2. Synchronous code reviews, also known as instant (Over-the-shoulder) code reviews;
3. Asynchronous code review, also known as a tool-backed (tool-assisted) code review;
4. Occasional code reviews, also known as conference-based (meeting-based) code reviews.

Type 1: Instantaneous code review

The first type is the instantaneous code review, which occurs in pairing programming scenarios. While a developer is writing code on the keyboard, another developer stares at the code, notices potential problems in the code, and gives suggestions for improving the quality of the code in the process.

Complex business issues

This method of code review works well when you need to solve a complex problem. In a careful search for solutions, bringing together two of people's brains increases the odds of success. Ask two minds to think about the same problem and discuss a workable scenario with each other so that you are more likely to cover some of the boundary conditions of the problem.

I like to use pair programming when encountering tasks that require a lot of complex business logic. This will help two of people to thoroughly clarify all the different possibilities in the process and ensure that all situations are properly handled in the code.

Unlike complex business logic, there are times when you need to solve a complex technical problem. For example, you're using a new framework, or some new technology that you didn't use before you explored it. In that case, it's best to act alone because you can make quick adjustments to your situation. To find out how new technologies work, you need to search the Internet for a lot of data, or read documents.

At this point, there is little help in pairing programming because you will become an impediment to acquiring this knowledge.

However, when you get stuck with a problem, talking to your coworkers about the solution often helps you get a different perspective on the problem.

Same level of professionalism

Another important aspect to consider for pairing programming is the professional level of two developers when working together. Two developers are best to be at the same level, because then they can work together at the same speed.

It's not good to have a beginner developer and an advanced developer pair programming. When the novice developer is responsible for writing code, the senior programmer sitting next to him may be bothered by the slowness of his writing. With this set-up, the ability of this senior programmer is limited, thus wasting time.

When the keyboard is in the hands of a senior programmer, he knocks too fast, and the novice programmer can't keep up with the idea of a senior programmer. A few minutes later, the novice programmer gets lost in the code context.

This setting is justified only if the senior programmer slows down and explains his approach to the novice programmer. However, this is not what we call pairing programming, but a learning link where senior programmers are teaching novice programmers how to solve specific problems.

However, if two developers are at the same level, in this setting, the progress they can make is surprising. One of the great benefits is that two developers can inspire each other, and when one loses attention, another developer can pull him back on track.

To summarize: Pair programming is suitable for two of developers with similar levels of experience to handle complex business problems.

Type 2: Synchronous code review

The second type is synchronous code review. This is where a developer writes the code alone, and when she finishes writing the code, she immediately checks with the code reviewer.

The reviewer went to the developer's desk and looked at the same screen, reviewing, discussing, and refining the code.

The reviewer is not clear about the target of the code

This type of code review works well when the reviewer is unsure of the goal of the task. It will happen in this case: there is no optimization meeting (refinement sessions) in the team, or the Sprint Planning meeting (Sprint planning sessions) to discuss each task in advance.

This practice usually results in a result: only a specific developer knows the needs of a task.

In this case, it would be helpful to introduce the reviewer to the target before the code review.

Expect a lot of code improvements

If the code writer lacks experience, the code that is written requires a lot of improvement, and synchronous code review can be very effective.

If an experienced senior developer is going to review a piece of code written by a very junior programmer, it will be much more efficient to work with a senior developer to improve the code when the novice programmer finishes writing the code than the novice programmer can see for himself.

The disadvantage of forcibly switching ideas

But there is a big drawback to the simultaneous review, which is that it forcibly switches the censor's mind. Not only does it frustrate censors, it slows down the efficiency of the team as a whole.

Type 3: Asynchronous code review

Then we have a third type of asynchronous code review. This type of review is not done at the same time, on the same screen, but asynchronously. After writing the code, the developer makes the code visible to the reviewer and starts her next task.

When the censor has time, he will conduct a code review on his own desk in accordance with his own schedule. Instead of communicating with developers in person, he uses tools to write reviews. After the review is completed, the tools will notify the developer of the comments and changes needed. The developer will improve the code according to the comments, and the same is to do it on their own schedule.

This loop will be re-submitted to the reviewer again with the code churn and start over again. The developer modifies the code until there is no comment that needs improvement. Finally, the changes are agreed to and submitted to the main branch (Master branch).

As you can see, synchronous code reviews are significantly different than asynchronous code reviews.

No direct reliance.

One of the great benefits of asynchronous code review is that it happens asynchronously. Developers do not need to rely directly on reviewers, and they can do their jobs on their own schedule.

Disadvantages of multiple review loops

The downside here is that you may have many cycles of review, and they may last for several days until they are finally accepted.

It usually takes a few hours for the developer to complete the code, and the reviewer begins to do the code review. Most of the time, the advice given by the reviewer can only be repaired by the developer the next day.

In this way, the first review cycle is spent at least one day. If you repeat this cycle again, the time for the review will continue for a whole week-it's not the time to write code and test.

But here are some ways to avoid the runaway of such a long time interval. For example, in my team, we stipulate that every morning, every developer will have to deal with the backlog of code review tasks before starting to do other work. Similarly, this will be done at the end of noon lunch break.

Because after a long rest time, the developer is not in his code thinking. At this point in the code review, you do not force them to do unnatural switching of ideas, and to allow the code to be reviewed at the right time.

Comparing the pros and cons of this type of code review, I think asynchronous code review should be the default option for every professional development team.

But before I tell you why I think so, let me look at the fourth type of code review.

Type 4: Occasional code review

A long time ago, I used to have a code review meeting with the whole team every month. We sat in a conference room where a developer showed up and explained a difficult piece of code he had written recently.

Other developers are trying to find potential flaws, post comments, and suggest ways to improve the code.

I don't think any team and the way to use occasional code reviews for a long time. I only think of a situation where this type is appropriate: When the entire team has no experience of code review, let's get everyone together and do a code review, so after a few times, it might help everyone understand the purpose and meaning of the code review.

However, in the long run, this fourth type is not a suitable technology, because it is inefficient to have the entire group of members review a piece of code.

What type of code review should I choose?

Well, now you might wonder which type to choose.

We discussed the formal type, which is obviously less popular and more difficult to practice.

Then we discussed the big class of lightweight code review, and then there are 4 of the famous sub-types.

Type 1, instantaneous code review, for pair programming. This works well when two developers have similar technology portfolios and deal with complex business problems.

Type 2, a synchronous code review that is used by the reviewer when it is unclear to the target of the task, requires the developer to explain it to the situation. This code review pattern works well when the developer is inexperienced and the code that is written requires a lot of improvement.

But its downside is the need to forcibly switch ideas, frustrating reviewers, and slowing down team development.

Type 3, asynchronous code review avoids the problem of forced switching of ideas, and works well for most use cases.

Type 4, the occasional code review, is not a long-term choice for a professional team. It can be used only when the team has just started the code review.

Use asynchronous code review as the default selection

I think that the professional team should take the async code review as the default choice. Because it avoids the flaw of synchronous code review.

When a reviewer doesn't understand why a developer makes a code change, you can use a synchronous code review. In that case, however, the reviewer will ask the developer for additional information and instructions. If you work in a team, this should happen very infrequently.

If you are not in a real team, but working with a group of people, then a synchronized code review will make sense. If the reviewer has no knowledge of what you have done in the past few days, it is reasonable to give the reviewer a proper explanation before starting a code review.

If you have two developers who have similar skill sets and are overcoming a complex business problem, then there is a reason to switch to pairing programming patterns. However, a team is often made up of members with different levels of experience and does not always deal with complex business problems. Most of the time, you are in the hands of the average level of complexity on the regular task.

Therefore, the best choice for a professional team is to use asynchronous code review as the default choice, and then switch to synchronous code review or pair programming when needed.

Well, that's what it is today.

What type of code does your team use to review? Do you know the other types of code reviews that I've missed out here? Please let me know in the comments.

Let's talk about it next time. Take care.