Code Review Review

Developer: Xuzhou 1 4

Audited by: Jin Yongpeng 1 3

Project, because of the quality of the two different, write the code quality varies, in order to ensure the quality of the project, have to review the line of code. At the same time, in order to have a deeper understanding of the code review and learn from other peer practice results, in the online collection of a lot of project knowledge, the following is the collation of these knowledge.

1th Chapter Premise
In Wikipedia, the definition of code review is: code review (Review) refers to the systematic review of the computer source code, common software peer review method, the purpose is to identify and correct errors found in the early stages of software development, improve software quality and developer technology. Code reviews often take different forms, such as pairing programming, seeing the entire code informally, or formally checking the software.
1.1 Code review first requires the team to have a good culture
The team needs to recognize that code reviews are designed to improve the ability of the entire team, rather than checking "levels" for individual settings. "A's code has a bug found by B, so a ability is not good, b ability is better", this kind of traps can easily be spread to affect the collaboration within the team, so need to avoid. In addition, the code review itself can improve the developer's ability to learn from the mistakes they have made and learn from the others ' ideas. If the developer has a conflict or aversion to this process, the goal will not be reached.
1.2 Cautious use of the detection rate of the problem in review as an evaluation criterion
If a problem is found in code review, it is a good thing for the person who found the problem and should be encouraged. But for those who are found, we do not advocate the use of this method of punishment. Bugs are unavoidable in software development, and excessive demanding is inherently counterintuitive. Worse, the code review has no value and meaning if the participants are afraid of taking responsibility and are reluctant to point out the issue in the review.
2nd. Code Quality Properties
Understandable: code needs to be easily understood at all levels. Ideally, the software should be very simple and without very obvious flaws.
Testability: Code that needs to be written is very easy to test.
Correctness: The code needs to meet both functional and non-functional requirements. 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?
Validity: The code requires efficient use of system resources (memory, CPU, network connection, etc.).
The 3rd chapter of the Code review benefits
Easier to find and more difficult to spot, such as architecture and timing-related issues.
Help team members improve their programming skills
Unified Programming Style
4th. Symptoms of poor code quality
Everything's going to be tough.
Slow progress
Test suite runs slowly
Unavoidable flaws
Your team is negative.
Lack of knowledge sharing
The growth cycle for new developers is too long
5th chapter How to examine
1 Review process: First review design implementation ideas, and then review design patterns, then review formed the backbone of code, finally review the completion of the code, if the program is complex, it needs to be split into several units or modules review respectively.
As much as possible to let different people reivew your code: Do not always find a person to review your code, different people have different ways of thinking, have different views, so, different people can comprehensively from all aspects of commenting on your code, some from the angle of implementation, some from the angle of demand, Some from the user's point of view, some from the angle of the algorithm, some from the point of view of performance efficiency, some from the angle of legibility, some from the perspective of extensibility ... Then there will be more people to help you maintain your code in the future.
Maintain a positive positive attitude: the biggest problem with the program is "ego", especially when we reivew someone else's code. Therefore, both the code author and the reviewer need a positive positive attitude, the author needs to be able to accept the advice of others, because other people's advice is to make you do better, the reviewer also need a positive attitude to the author's opinion, because it is with you in a trench comrades.
Control the code size for each review: According to a survey conducted by Smartbear in Cisco, each review of 200 lines-400 lines of code works best. Every time you try to censor too much code, the ability to find a problem drops.
Do it with the problem: in every code review, we ask reviewers to use their experience to think about the problems they might encounter and then verify that they have been resolved by reviewing the work. One trick is to verify that the usage scenario works correctly in code reading, starting with the user-visible functionality and assuming a more complex usage scenario. Using this technique, you can give the reviewer a sense of being in, and actually immerse yourself in the code to improve efficiency.
Use static code analysis tools as much as possible to improve review efficiency.
The 28 law deals with high-risk code: Reviewing all the code does not make much sense, and the focus should be on high-risk code and code that is prone to high-risk modification or refactoring. Old and complex, handling sensitive data, handling critical business logic and processes, large-scale refactoring, and code implemented by developers just joined the team are the focus of the review.
Ask the original author to identify the problem: there are two purposes for this, to confirm that the problem exists, to ensure that the problem is resolved, to allow the original author to understand the problem and to help it grow.
Self-censorship: All team members must conduct a review before submitting the code to other members for review. In addition to checking the correctness of the code, this self-correcting form of review can also be done as follows:
Add comments to the code to explain the reasons behind this change and make it easier for others to review.
Fixed coding style, especially the naming of some key data structures and methods to improve the readability of code.
From a holistic look at the design, whether all scenarios are considered completely. This stage can be well remedied if there are poorly thought-out scenarios for the design done before the implementation.
Review summary After the code review: Members should do a handy record when coding, including commenting in the code, or documenting simple personal documents, with several benefits:
Avoid omissions. Any issues that will be taken into account during the encoding are documented and re-examined during the review phase to confirm the resolution.
According to the study, everyone is used to making some repetitive mistakes. This type of problem is recorded in the code and can be used as a basis for inspection at the time of the review.
After taking notes repeatedly and finding similar problems in the review, the incidence of such problems is significantly reduced.

Code Review Review