Code reviews on the sky

Although Code Review is often mentioned, I personally feel that most of the actual situations of Code Review are ugly (half from others' blogs and half from personal experiences.

More often, the Code Review is like a wine that has been stored. When you use it, you can check it out to prove that you have it, but most of the time you don't need it.

 

The reason for further research may come from two aspects:

First, the time pressure is too high.

In software development, there are not many security discounts. It is easy to see documents without writing them, and the code will not move without writing the program.

There is no way to open the Code Review.

After all, the Code Review looks at both eyes and eyes, but it is actually a matter of conscience, which is invisible to outsiders.

At the same time, Code Review itself is indeed a time-consuming activity.

 

Another cause is the lack of effectiveness.

If CodeReview is equivalent to sitting together to view the Code, it is very likely that the Code Review cannot be effectively executed. If we do this, everyone will be exhausted, I think this is a waste of time.

This is a bit related to the previous one. Once the time is tight, the encoding is required to be fast; the encoding speed is fast. For a specific person, there will be more things I don't understand; in addition, you cannot reserve sufficient Code Review time.

In addition to the author, the participants may not understand the code. If you don't understand it, you can only get confused.

From this point of view, the pursuit of high productivity should be wrong, and productivity itself should be a range: lower than a certain value is a foreign engineer, higher than a certain value is a quality change speed.

After all, human resources are sometimes exhausted.

 

 

In terms of the time pressure of a single project, it cannot be solved within the scope of the project, and there are many problems involved.

 

However, you can try to Improve the effectiveness.

One of the main ways to improve is to clarify "what you don't see" and "What you see ".

It should be noted that, most of the time, "What is not defined" is probably more important than "what needs to be viewed.

Of course, the premise here is "get results as much as possible under time pressure ." If a project has time, you may wish to look at each line carefully.

 

I personally feel that in CodeReview, the first thing I don't want to do is "compete with the test ."

Using CodeReview to check whether the basic functions are implemented correctly is itself not completely wrong, but at least it is inefficient.

From the product perspective, CodeReview should be complementary to other methods, rather than overlap as much as possible.

 

The second thing you don't want to do is to compete with static tests ".

Anything that can rely on static tests should be ignored in CodeReview, such as function complexity.

 

In this way, what CodeReview should do will become clearer.

• Areas that are difficult to test, such as multi-thread synchronization and extreme condition processing.
• Whether the logic is clear, such as the deviation between the basic structure and design, and whether the use of global variables is appropriate.
• The encoding style that cannot be covered by the static test. Some items in the encoding rules should be analyzed automatically as much as possible, but some items cannot be checked automatically, for example, whether the exception is suitable.

This type of things can only be overwritten in CodeReview.

 

In CodeReview, I tend to perform subtraction instead of addition. A key prerequisite for this is that the project time is always insufficient,

At this time, CodeReview, static testing, and unit testing functions can only be complementary, rather than overlapping them as much as possible.