What do you get from code review?

Absrtact: I don't work at Google anymore. I haven't figured out where to go. There are two or three very good job opportunities in front of me. Because in this decision time, I no longer employed by anyone, I think can write some professional things, some very

I'm not working at Google anymore. I haven't figured out where to go-there are two or three very good job opportunities in front of me. Because I'm no longer employed by anyone in this decision time, I want to be able to write something professional, something interesting, but also a matter of tension in my co-workers and my management work.

Google is a very good company. They have done a lot of admirable things-both outside of the company, in what people can see, and within the company. There are some things that are not kept confidential within the company and have not been adequately discussed outside. That's what I'm going to say today.

One of the most important things that makes Google's program so good seems simple: code review. It's not just Google doing this-code review has been widely recognized as a very good practice, and many people are doing it. But I have not seen a second such large company that can use this kind of thing so widely. At Google, no programs, any products, any program code for any project can be delivered to the code base without a valid code review.

Everyone has to go through code review. And very formal: this kind of thing should be a basic system in any important software development work. Does not refer to the product program--everything. It doesn't take much work, but its effect is huge.

What do you get from code review?

Obviously: Before the code is submitted, check with the second group of eyes to prevent the bug from mixing. This is the most common understanding of the benefits of code review. But, in my experience, this is the least important point. People do find bugs in code reviews. However, the vast majority of bugs found in code reviews are obviously trivial bugs, and the authors of the program take a few minutes to discover them. Bugs that really take time to find are not found in code reviews.

The biggest function of code review is purely social. If you are programming and know that there will be coworkers checking your code, your programming attitude is completely different. The code you write will be cleaner, better annotated, and better structured-because you know the person you care about will see your program. Without code reviews, you know people will eventually see your program. But it's not something that happens immediately, it doesn't give you the same sense of urgency, it doesn't give you the same personal judgment.

There is also a very important benefit. Code reviews can spread knowledge. In many development teams, everyone is always in charge of a core module, and each person is focused on his own module. They never communicate with each other unless their colleagues ' modules affect their programs. The consequence of this is that only one person in each module is familiar with the code inside. If the person is on vacation or-hopefully not-resigned, others are at their wits ' end. With code reviews, at least two people will be familiar with these programs--the author, and the censor. The censor is not as knowledgeable about the program as the author of the program-but it is extremely important that he is familiar with the design and architecture of the program.

Of course, nothing can be done simply. In my experience, you need to take the time to exercise to learn before you can properly conduct a code review. I find that people often make mistakes in code review, causing a lot of trouble--especially in the case of inexperienced censors, who give people an experience of code censorship and become an obstacle to accepting code censorship.

One of the most important principles: code review is meant to find the problem before the code is submitted-you have to find out it's right. The most common mistake in code review--almost every novice would make--is that the censor judges the code of others according to their own programming habits.

For a problem, we usually find more than 10 ways to solve it. For a solution, we can have millions of coding schemes to implement it. As a censor, your task is not to make sure that the code being reviewed uses your coding style--because it can't be the same as what you write. The task of the censor as a piece of code is to ensure that the code written by the author is correct. Once this principle is broken, you will end up suffering and frustrated-this is not the result we want.

The problem is that such errors are so prevalent and easy to make. If you're a programmer, when you run into a problem, you can think of a solution--you put the solution you think of. But that's not the case--as a good censor, you need to understand that.

The second problem with code review is that people feel pressured and feel the need to say something. Do you know that the author uses a lot of time and effort to implement these programs-shouldn't you say something?

No, you don't.

Just say "Wow, that's good", and it won't be inappropriate at any time. If you are always trying to find something to criticize, the result of doing so will only undermine your prestige. When you take pains to find something, just to say something, the censor will know that you say these words just to fill the silence. Your comments will no longer be taken seriously.

The third is speed. You can't rush through a code review--but you need to be able to do it quickly. Your companion is waiting for you. If you and your co-workers don't want to spend too much time doing code reviews and you're done quickly, the censors will feel frustrated, and this code review is just a disappointment. It seems to disturb everyone, so that we can put aside the work at hand for review. It's not supposed to be like this. You don't need to push anything on hand to do code review. But if you delay for a few hours, you will have to rest for a while, have a cup of tea, take a shower, or talk some gossip. When you go back to the review site, you can go on and get things done. If you do, I don't think anyone would like to wait for you there.