Understanding and understanding of code reviews

Code review should be a fundamental system in any important software development effort. Does not refer to the product process alone-it is everything. and code reviews don't take a lot of time and effort, but it can make a huge impact.

　　What can I get from the code review?

For code review, check with other people's eyes before the code is submitted to prevent bugs from mixing. This is the most common understanding and the most extensive understanding of the benefits of code review.

But, in my opinion, this is the least important of it. People can actually find some bugs in the code review. However, the vast majority of bugs that can be found in code reviews, obviously, are trivial bugs, and the authors of the program can find them in a matter of minutes. Bugs that really take time to find are not found in code reviews.

The biggest benefit of code review is that if you're a programmer and you know there will be other colleagues checking your code, your programming attitude is completely different. The code you write will be neater, with better annotations and better program structure. Because you care about what others think of your program. Without a code review, you might think that the program you write is almost never seen, and unless someone uses it, it doesn't give you the same sense of urgency. In addition, there is a very important benefit. Code reviews can disseminate knowledge and foster a shared atmosphere. In many development teams, each person is often responsible for a core module, and everyone focuses on his own module. Unless a colleague's module affects their own programs, they never communicate with each other. The consequence of this situation is that only one person in each module is familiar with the code inside. If the person is on vacation or resignation, others are helpless. With code review, at least two people will be familiar with these programs. Although the reviewer does not know the program and the business as well as the author of the program, it is extremely important that he is familiar with the design and architecture of the program and the architecture of the business.

In the beginning, people often make mistakes in code review, causing a lot of trouble, especially some inexperienced censors, who give programmers a bad feeling when it comes to code reviews, eventually leading to a code-censorship breach.

Review for all
* First of all, it must be admitted that reviewers are judging people's code according to their own programming habits. So many of the programming propositions are a personal point of view. Therefore, we should discuss their pros and cons, put forward your preferred point of view, quickly in the team to agree.

* To the reviewer and the censor, we feel pressure, feel the need to say something, have to find out what problems come out just fine, others have put forward something, they have to say a little bit. (No need at all.) Just say one sentence "This procedure is really good." "It will be OK."

* Try to use a question or suggestion rather than an order. ("Name this variable: user_id, what do you think?") ”)

* Request description. ("I don't understand.") Can you explain it? ”)

* Avoid the contention of code attribution. ("My", "Not Mine", "Yours")

* Don't be sarcastic, laugh at other people's code, avoid using words that are considered or may be considered to be relevant to your personal characteristics. ("idiot", "foolish", "dumb", "two") to regard everyone as charismatic, intelligent, and well-intentioned.

* To be clear. Remember that not everyone can understand your intentions.

* Be humble. ("I'm not sure--let's analyze it.") ”)

* Do not use "always", "Never", "Forever", "no ..." rhetorical language.

* If there's too much I don't understand about a particular code, or if everyone has a different view, you can organize a seminar, or technology sharing, and then develop a common understanding of your interactions and summarize them into documents.

* Code review, not time is too short, so there is not much effect, but the time can not be too long. After all, we have other work to do.

　　Ask someone to review your code

* First of all to reach a consensus to understand that censorship is not right for people. The review is your code, not yours.

* To affirm and appreciate the recommendations of the reviewers. ("Yes, you're right.") "," Thank you for reminding me. I'll fix it. ”)

* Explain why the code is written so that you can illustrate the business logic of this code.

* Organize your changes without having to get rid of them on the spot, complex programs, or refactor them in later iterations.

* Try to understand the position of the reviewer and try to understand the author's position as well.

* Communicate with developers about places you feel very good about and not very well.

* Find ways to solve problems and simplify code, making your code simple.

* Propose your implementation, but show that the author is also considering this scenario. ("How do you feel about using a custom check here?") ”)

* Program style styles and annotations are also the scope of code reviews, not just programs.

Understanding and understanding of code reviews