4.8 Day Code Review review

Developer: Sun Yu No. No. 02

Auditor: Yang Besen No. No. 06

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        on Wikipedia, the definition of code review is: code review (Review) refers to the systematic review of the computer source code, The common software peer-reviewed approach is designed to identify and correct errors not found in the early stages of software development, improving 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       team need 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 Prudent use of the detection rate of the issue under review as an evaluation criterion       if a problem is found in a 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. The 2nd chapter of the quality of code is 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 makes the benefits of code review easier to identify and structure as well as difficult to spot problems such as timing correlation. Help team members improve programming skills Unified Programming Style 4th Chapter Code Poor quality symptoms all things are tough progress slow test suites run slowly unavoidable bugs your team is negative knowledge lacks shared new developer growth Cycle too long 5th chapter How to Review 1 review processes: First Review design implementation Idea, then review the design pattern, then review the formed backbone code, and finally review the completed generationCode, if the program is complex, it needs to be split into several units or modules, respectively review. 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 can do the following: Add comments to the code, explain the reasons behind the changes, and make it easier for others to review them. 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 inThere are several benefits to doing when coding, including commenting on the code, or documenting simple personal documents, with a few advantages: 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.

4.8 Day Code Review review