Code review

Code review is an important topic for teams.

Status analysis and significance

For most developers, the idea of code review is to put code out there for others to see and discuss, with no deep concepts in mind.

In fact, code review involves things including: review tools, review specifications, review procedures, review methods, and even staff participation, time control and so on.

The point of code review, of course, is to reduce online problems as much as possible through process management. For TL, project quality can be controlled through such process management.

Of course, it also has certain disadvantages, increase the software development process, reduce efficiency to a certain extent. (But this is assuming that our projects are of high quality. If there is a problem with the quality of the project itself, the cost will be much higher when it is repaired online.)

Some soft insights

1. Environment shaping of code review

Code review is a process of communication, and if the code is well written, it is a platform to showcase yourself and share good practices.

If there’s a problem with the code, it doesn’t matter, find it and fix it.

Generally speaking, TL’s attitude in this process is very important, if TL’s tone is critical of someone who has a problem, then naturally people will be offended by the matter.

If TL can always output some excellent ways of thinking and code architecture in this process, it is actually a process of teaching experience to the underlings, and everyone will naturally like review if they feel that they have gained something.

In particular, pay attention to the attitude issue, human emotions are very sensitive, and if someone on the team says something like “this line of code is rubbish”, the TL’s focus must not be on the code, but on the tone of someone on the team.

When discussing other people’s code, you can say, “This line of code can be implemented how, express your own knowledge, don’t express special (bad) emotions.”

On the contrary, I like to praise others very much, such as the amount of code, it can be said that others are suffering this period of time. The logic is complicated, and you can say that this really takes a lot of effort or something.

2. Code Review — How to promote it

In fact, people always do not want to expose their own things, similar to the code I write, is the feeling of my things.

When promoting code review, there are two ways to do it. On the one hand, it is the value promotion to make everyone recognize this matter and the importance of code review; on the other hand, it is mandatory to some extent, because it is required for the quality of the team code and the stability of the company’s business.

Based on personal experience and value promotion, it can be explained from the practices and necessity of major companies in the industry, and even the career development of team members, that the probability of success can be recognized by everyone.

Every time we encounter a major problem, it is also an opportunity, depending on whether we will make use of it. If there is an online problem, propose the code review, we should accept it.

3. Code Review — Stay true to your original aspiration

Always remember what our purpose is.

Don’t change a line of style code, do a review. Because it’s not worth talking about.

Generally speaking, when the amount of code exceeds a certain amount, its business complexity, code design can be discussed.

Review the specification of the

Review norms should be implemented according to the specific situation of the team.

However, there are still some common things: for example, what are the main points of review? Who are the review participants? What is the granularity of review?

Review the main points of the

1. Whether the code format conforms to the specification

This section includes lint specifications, naming conventions, and more. The Lint specification can generally be addressed using tools, but naming conventions need to be reviewed.

2. Code readability

Is there deep if else nesting?

Is there a function that is difficult to understand, or a function that is too long?

For example, if it is a Vue project, the official recommended style guide is cn.vuejs.org/v2/style-gu…

3. Border issues

Is there an exception that the developer didn’t think of? This is generally relevant to the specific business scenario.

4. Code architecture

Is there room for tweaking the way the code is organized? Is there reusable code to extract?

participants

If you are in a small team, like three or four people, you should all know what you are doing and be able to participate in it

If a large team is divided into different directions according to the familiar business, relevant personnel can participate in REIVEW.

However, specific implementation level, need specific problems, specific analysis.

Review the granularity of the

Personally, some simple changes do not need code review.

But you need to have some hard rules for managing your team members, and you can count 500 lines of code above that as a tipping point.

Review of the tool

Review is a systematic project, involving personnel, relevant specifications and tools.

Personally, inside Alibaba, there are similar tools.

However, considering that most companies may not have their own tools, I recommend the open source tool ReviewBoard.

Write at the end: This article is part of the author’s feature “Technology Building for the Front-end Team.” See the following article for more information: juejin.cn/post/685705…