This article is translated from: https://dzone.com/articles/4-types-of-code-reviews-any-professional-developer
Please indicate the source when reprinting: Grape City official website , Grape City provides developers with professional development tools, solutions and services to empower developers.
No one can guarantee that the code he produces will be perfect. The following describes 4 mainstream types of code review (code review), I believe that as a professional developer, you should know them all!
Every professional software developer knows that code reviews are a necessary part of any formal development process. But what most developers don't know is that there are many types of code reviews. Each type of code review has its own set of advantages and disadvantages, depending on your project and team structure.
In this article, I will list several types of code reviews and explain in detail how each of them works. And, I'll also give you some advice on when to make which choice.
Alright, let's get started.
First, at a very high level, you can categorize code reviews into two broad categories: formal code reviews, and light weight code reviews.
formal code review
A formal code review is based on a formal development process. One of the most popular practices is the Fagan inspection.
It provides a very structured process for trying to find bugs in code, and it can also be used to find bugs in specifications or design.
Fan root inspection method consists of 6 steps: Planning, Overview, Preparation, Inspection Meeting, Rework, and Follow-up. The basic idea is to pre-determine the output requirements that each step needs to achieve. Next, when you get to a process, you examine its current output and compare it to the desired output requirements previously formulated. Then, you decide from this whether to move on to the next step, or to continue working on the current step.
This structured process is not used much. In fact, in my career, I've never met a team that uses this approach, and I don't think I'll see it happen in the future.
I think the reason is that this process has a lot of overhead and not many teams use it.
However, if you're developing software that is life-or-death and will kill people because of bugs, then it makes sense to look for bugs in this structured way.
For example, you are developing software for a nuclear power plant. You may need a very formal process to ensure that the final code is handed over without problems.
But like I said, most of the software we developers make is not life-threatening, so we use a more lightweight approach to code review as an alternative to the formal process.
So, let's take a look at this lightweight approach.
Lightweight Code Review
Lightweight code reviews are commonly used in development teams these days.
You can subdivide lightweight code reviews into different subcategories:
- Instantaneous code reviews, also known as pair programming;
- Simultaneous code review, also known as over-the-shoulder code review;
- Asynchronous code reviews, also known as tool-assisted code reviews;
- Occasional code reviews, also known as meeting-based code reviews.
Type 1: Instant code review
The first type is instantaneous code review, which occurs in the context of pair programming. While one developer is typing code on the keyboard, another developer is staring at the code, noticing potential problems in the code, and giving suggestions for improving the quality of the code in the process.
complex business problems
This method of code review works well when you need to solve a complex problem. Bringing together the brain power of two people in the careful search for a solution increases the odds of success. By having two minds thinking about the same problem and discussing possible solutions with each other, you are more likely to cover some edge cases of the problem.
I like to use pair programming for tasks that require a lot of complex business logic. This way, it helps the two people thoroughly sort out all the different possibilities in the process, ensuring that all situations are handled appropriately in the code.
Unlike complex business logic, sometimes, you also need to solve a complex technical problem. For example, you're using a new framework, or exploring some new technology that you haven't used before. In that case, it's better to go it alone, because you can make quick adjustments to your situation. In order to figure out how the new technology works, you need to search a lot of information on the Internet, or read the documentation.
At this point, pair programming won't help much, because you'll be a hindrance to your own acquisition of this knowledge.
However, when you're stuck with a problem, talking to your colleagues about the solution can often help you gain a different perspective on the problem.
same professional level
Another important aspect to consider pair programming is the level of expertise of the two developers when working together. It is best for both developers to be on the same level, because then they can work together at the same speed.
Pair programming a junior developer with a senior developer doesn't work well. When a junior developer is in charge of writing code, the senior programmer sitting next to him may be annoyed that he is writing too slowly. In this setting, the capabilities of the senior programmer are limited, thus wasting time.
And when the keyboard is in the hands of the senior programmer, he taps too fast, and the junior programmer cannot keep up with the ideas of the senior programmer. After a few minutes, the junior programmer is lost in the context of the code.
This setup only makes sense if the senior programmer slows down and explains his approach to the junior programmer. However, this is not what we call pair programming, but a learning session in which a senior programmer is teaching a junior programmer how to solve a specific problem.
But if both developers are on the same level, it's amazing how much progress they can make in this setting. One of the great benefits of this is that two developers can motivate each other, and when one loses focus, the other can pull him back on track.
To summarize: Pair programming is suitable for situations where two developers with similar levels of experience are working on complex business problems.
Type 2: Synchronized 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 finds a code reviewer for review.
Reviewers come to the developer's desk, looking at the same screen, reviewing, discussing, and improving the code together.
The reviewer is not clear about the goal of the code
This type of code review is effective when the reviewer is unclear about the goal of the task. It happens when the team doesn't have refinement sessions, or sprint planning sessions, to discuss each task up front.
This often results in the fact that only specific developers know the requirements of a task.
In such cases, it is helpful to brief the reviewer about the goals of the task before the code review.
Expect lots of code improvements
Synchronous code reviews can also be effective if the code writers are inexperienced and write code that needs a lot of improvement.
If an experienced senior developer is going to review a piece of code written by a very junior programmer, then it is far more efficient to work with the senior developer to improve the code after the junior programmer has written the code. For junior programmers to see it by themselves.
Disadvantages of forcibly switching ideas
However, a major disadvantage of synchronous review is that it forcibly switches the thinking of the reviewers. Not only does it frustrate reviewers, it also slows down the efficiency of the entire team.
Type 3: Asynchronous Code Review
Then we have a third type, asynchronous code reviews. This type of review is not done at the same time, on the same screen, but asynchronously. After the developer has written the code, makes the code visible to reviewers, and then starts her next task.
When the reviewer has time, he conducts code reviews on his own schedule at his desk. Instead of communicating with the developer in person, he uses the tool to write some comments. After completing the review, those tools will notify the developer of the comments and required changes. Developers will improve the code based on the comments, and again, do these things on their own schedule.
The cycle starts all over again with the code changes being submitted to the reviewers again. The developer modifies the code until there are no comments saying improvements are needed. Finally, the changes are approved and committed to the master branch.
As you can see, there is a big difference between a synchronous code review and an asynchronous code review.
no direct dependencies
One of the great things about asynchronous code review is that it happens asynchronously. Developers don't need to depend directly on reviewers, and they can all do their work on their own schedule.
Disadvantages of multiple review loops
The downside here is that you may have many rounds of review, which may last for days before finally being accepted.
After the developer has finished the code, it usually takes a few hours before the reviewer starts doing the code review. Many times, the suggestions given by the reviewers are only fixed by the developers the next day.
In this way, the first review cycle took at least one day. If you repeat this cycle multiple times, the review time stretches to a full week -- and that's not counting the time spent writing code and testing.
But here are some things you can do to avoid the loss of control caused by such long intervals. For example, on my team, we have a rule that every morning each developer has to work through the backlog of code review tasks before starting other work. The same is required after the midday lunch break.
Because after a long break, the developer is no longer in his code ideas. By doing code reviews at this point, you're not forcing them to make unnatural thinking switches, and you're able to get the code 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 Reviews
A long time ago, I used to have a monthly code review meeting with the entire team. We're sitting in a conference room with a developer showing and explaining a difficult piece of code he recently wrote.
Other developers try to find potential bugs, leave comments, and give suggestions on how to improve the code.
I don't think any team and long-term use the occasional code review approach. I can only think of one situation where this type is suitable: when the whole team has no experience with code reviews, let everyone get together and do code reviews together, after doing this a few times, it may help everyone understand the code review. purpose and meaning.
However, this fourth type is not an appropriate technique in the long run, as it is inefficient to have the entire team review a piece of code.
Which code review type should I choose?
Well, now you might be thinking, which type to choose.
We discussed the formal type, which is obviously less popular and harder to use in practice.
Then, we discussed the broad category of lightweight code reviews, and then the 4 well-known subtypes within it.
Type 1, instantaneous code review, for pair programming. This approach works well when two developers have similar technology portfolios and are dealing with some complex business problems.
Type 2, synchronous code review, is used when the reviewer is unclear about the purpose of the task and the developer needs to explain it to him. This code review mode also works well when developers are inexperienced and write code that needs a lot of improvement.
But it has the disadvantage of requiring a forced switch of ideas, frustrating reviewers, and slowing down team development.
Type 3, asynchronous code review, avoids the problems of forced switching of ideas, and works well for most use cases.
Type 4, the occasional code review, is not a long-term option for professional teams. Can only be used when the team is just starting a code review.
Use asynchronous code review as default choice
In my opinion, professional teams should make asynchronous code reviews the default choice. Because it avoids the pitfalls of synchronous code review.
Synchronous code review can be used when the reviewer cannot understand why the developer made a code change. But in that case, the reviewer will go and ask the developer for additional information and clarification. If you work on a team, this should rarely happen.
Synchronized code reviews make sense if you're not in a real team but working with a group of people. If the reviewer has no idea what you've been working on the past few days, it makes sense to give the reviewer a proper description before starting to do a code review together.
If you have two developers who have similar skill sets and are tackling a complex business problem, there is also a reason to switch to pair programming. However, a team tends to consist of many members with different levels of experience and does not always deal with complex business problems. Most of the time, you're dealing with routine tasks of average complexity.
Therefore, the best option for professional teams is to use asynchronous code review as the default choice, then switch to synchronous code review or pair programming when needed.
Well, that's it for today.
What type of code review does your team use? Do you know of other types of code reviews that I've missed here? Please let me know in the comments.
Talk to you next time. Take care of yourself.
Reprinted in: https://www.cnblogs.com/powertoolsteam/p/9479555.html