I need to fully understand this part of the code to make sure it works, and if I fix the problem in the code, I wouldn't write that, so I hope you don't write it that way.

Jim Bird is an experienced software development manager, Project manager and CTO with a focus on solving difficult problems in the areas of software development and maintenance, software quality and security. Over the past 15 years, Jim has managed team building and led the construction of a high-performance financial system. His main interest is how to improve the efficiency of small teams to build real software: High quality, safe, reliable, high performance and adaptable. Recently, Jim wrote a blog about the value of code review, how to conduct code review, the process of code review, and the issues that need attention in code review, hoping to bring some insight into the code review.

　　Start Code Review

From the start, developers will help each other, and if there are problems with the test or if a newcomer joins the team, the leader or senior developer will review their code. In addition, we have hired external experts to conduct security code reviews.

After the system was released, we decided to take a more proactive approach, starting with a risk-based review: Someone in the project would write some high-risk code (such as frameworks and security code, APIS, core business logic, or where there have been problems before), and we'll review their code. In this process, the code review reflects its value, and we reap quite a lot. Even so, we went a step further and let code review become a standard practice.

This is not a one-night form. Let the team believe that the value of code reviews is not difficult, and they have benefited from a risk-based review. But it's not that simple to change the way people work, and make sure they have enough time to review, understand, and respond to feedback. In addition, it takes time to design an efficient code review process.

At first, we let the developers choose a good partner and arrange the review, but the result was a bit confusing. Sometimes, developers look for people who are bcause or busy, so censorship is easier to pass, and two of developers are likely to negotiate in advance so the review process will be over soon. Because people don't know how much time it takes to complete a code review, the review often takes a long time and is often done after the code has been tested or even released.

Since most people do not have much code review experience, they are not sure what to look at during the review and how to give meaningful feedback. Developers are often frustrated by negative criticism and sometimes even distracted.

Finally, we decided to do most of the review by the leadership. While this increases the amount of leadership work, it also means that they don't have much time to write code, but it works. Typically, the main developer has a better understanding of the requirements and a clear understanding of the behavior of the code, which means they are more likely to find errors in the code. Because the same person has done most of the code review, the reviewed developer receives consistent feedback.

　　How We conduct code reviews

In the past few years, there has been little change in the way we conduct code reviews.

No matter who wrote it, no matter what the functionality of the code, important code changes are definitely reviewed. We don't have a formal review conference, nor do we see the need to use tools such as code collaborator, Crucible, but now it seems that using these tools to manage and track reviews helps the team get a better start.

Sometimes the review is done in person, but most of the time it's offline. Reviewers and developers exchange information, perhaps by email, because we find this way more convenient and more convenient for everyone to schedule their own time.

As time goes by, the changes in the review are what the censor should see and see.

　　Review correctness

Many times, programmers spend a lot of time arguing about what to look for in the code review process, but they don't actually spend too much time doing real code reviews.

We started the code review to improve the quality of the code and look for problems that were not found in the test. This is not to teach inexperienced developers how to write better code, or how to share knowledge within a team. These should be the indirect benefits of code review, but the final goal of the review should be to ensure that the code works correctly.

In relation to the use of long checklists, the reviewer will first ask several questions when looking at the code:

• Is the behavior of the code consistent with expectations, and is the logic correct?
• Does the code under review have similar structure and functionality to other code?

　　Review of comprehensible

As time goes by, what you look for and get in code review changes. This is because the code itself can change, and the people who do it-developers and censors can also change.

Developers need to load code-checking tools in their IDE, and we'll use some good static analysis tools to automatically check for common coding bugs and bad coding practices. This means that the reviewer's time can be spent on more important design errors, such as concurrency bugs, race conditions, and potential deadlocks, as these problems are not detectable by the tool.

　　Understand, not criticize

The purpose of the review is to understand the code and to make sure that the code works properly, not criticizing anyone.

In the code review process, do not mix in such controversies as "What do I think good code is, what do you think good code is?" The code review should focus on "I need to fully understand this part of the code to make sure it works properly, and if I fix the problem in the code, I wouldn't write that, so I hope you don't write it that way."

　　With the passage of time, some things will be better, some not

As time goes by, as you look at the code, you'll see that the code is changing. Michael feathers found that most of the code was rarely or never changed after it was written, and that most of the changes took place in a very small part of the code base.

Because censors see the same code changing constantly, it also changes the way they censor.

　　Avoid diminishing returns

Like other practices in software development, you will eventually find that code reviews have a diminishing payoff, especially when you're always doing the same thing and looking at the same problem in the same way. There will eventually be a stage in which the value of code review is almost 0. But that doesn't happen to us, and we still get a lot of revenue from the code review process.

Even with improved tools and testing capabilities, we still conduct code reviews because bug checking tools, reviews, and tests can find different types of issues. We also found that code reviews make testing more efficient, because if a problem has been discovered before, there will be no excessive reciprocating between developers and testers.

http://kb.cnblogs.com/page/199658/

I need to fully understand this part of the code to ensure that it works properly, if I fix the problem in the code, I would not write this, so I hope you do not write this (go)