Code Review Code Review

1. About Code Review1.1 Purpose of
Code Review Code Review is a quality assurance mechanism used to confirm program design and code implementation, through which we can check code, test procedures and comments.
Code Review is mainly used to improve code quality in the software engineering process. Through Code Review, the following purposes can be achieved:
(1) Bugs in the code can be found in the early stage of the project
(2) Help junior developers learn the experience of senior developers, Achieve knowledge sharing
(3) Avoid developers from making some common and common mistakes
(4) Ensure good communication between project team members (5) The
code of the project or product is easier to maintain The conditions are as follows: (1) Whether the code review personnel understand the concept of code review and what the code review will do If the code review personnel cannot understand the importance of code review to the success or failure of the project and the quality of the code, their approach may be to cope with something happened. (2) Whether the code has been built correctly. The purpose of the build is to make the code no longer have basic syntax errors. We don't want senior developers or supervisors to waste time on checking code that cannot even be compiled. (3) Whether the function of the code is correct when the code is executed The Code Reviewer is also not responsible for checking whether the function of the code is correct, that is to say, the code that needs to be reviewed must be the responsibility of the developer or quality personnel for the correctness of the function of the code. (4) Does the reviewer understand the code?









The person who does the review needs to have a basic understanding of the code, what is its function, is to take one aspect of the code, involving the database or communication, so that a targeted inspection can be taken
(5) Whether the developer has done the code Unit testing
This is also to ensure that some syntax and functional problems have been resolved before the Code Review, and the Code Review staff can focus on the quality of the code.


1.3 What does Code Review need to do
Code Review mainly checks whether the following problems exist in the code:
code consistency, coding style, code security issues, code redundancy, whether it is properly designed to meet requirements (performance, functionality), etc.
1.3. 1 Completeness check (Completeness)
Whether the code fully implements the functional requirements proposed in the design document Whether the
code has been integrated according to the design document and
whether the Debug code has created the required database, including correct initialization data Whether there is any error in the code
Variables, constants or data types that are defined or not referenced
1.3.2 Consistency check (Consistency)
Whether the logic of the code conforms to the design document
Whether the format, symbol, structure and other styles used in the code are consistent
1.3.3 Correctness check (Correctness) )
Whether the code conforms to the established standards
All variables are correctly defined and used
All comments are accurate
All program calls use the correct number of parameters
1.3.4 Modifiability check (Modifiability)
Whether the constants involved in the code are easy to modify (such as using configuration, defining as class constants, using special constant classes, etc.)
Does the code include a cross-description or data dictionary to describe how the program accesses variables and constants Is the
code There is only one exit and one entry (except for serious exception handling)
1.3.5 Predictability Check (Predictability)
Whether the development language used by the code has well-defined syntax and semantics
Does the
code avoid relying on the functions provided by default in the development language? Whether the code is inadvertently caught in an infinite loop Whether the
code avoids infinite recursion
1.3.6 Robustness
Whether the code takes measures to avoid runtime errors (such as array boundary overflow, division by zero, value out of bounds, stack overflow, etc.)
1.3. 7 Structural check (Structuredness)
Whether each function of the program exists as an identifiable block of code Whether the
loop has only one entry
1.3.8 Whether the traceability check (Traceability)
code uniquely identifies each program
Whether there is A cross-referencing framework can be used to map code to development
documentation Does the code include a revision history where changes to the code are documented and why
? Are all security features identified
1.3.9 Understandability Check (Understandability)
whether comments are clear enough to describe each subroutine
Whether ambiguous or unnecessarily complex code is used, and whether they are clearly commented
Use some unified formatting techniques (such as indentation, white space, etc.) to enhance the clarity of the code
Whether the naming rules are defined to facilitate memory, reflect the type, etc.
Each variable defines a legal value range In the
code Whether the algorithm conforms to the mathematical model described in the development document
1.3.10 Verifiability Check (Verifiability)
Whether the implementation technology in the code is easy to test

1.4 Steps of Code Review
These are the summary of my experience in my usual work, and I am also following this step at present doing.
(1) The code writer and the code reviewer sit together, and the code writer explains the code and related logic that they are responsible for in turn according to the UC, from the Web layer -> DAO layer;
(2) The code reviewer can be at any time during this process. Ask your own questions while actively discovering hidden bugs; keep track of those bugs.
(3) After the code is explained, the code reviewer arranges for himself a few hours to review the code again.
   The code needs to be read line by line. At the same time, the code should be viewed comprehensively to ensure that the code is well designed as a whole.
(4) The code reviewer writes a "code review report" according to the review results, records the problems found and modification suggestions in the "audit report", and then sends the "audit report" to the relevant personnel.
(5) The code writer should modify the code according to the modification opinions given by the "Code Review Report".
(6) The code writer will give feedback after the bug fix is ​​completed.
(7) The code reviewer updates the valuable problems found in the Code Review to the "Code Review Specification" document, and can send mass emails to all technical personnel for problems that are particularly worthy of reminder.

hint
Documents necessary for Code Review:
"Code Review Specification" document: Documents the standards that code should follow.
Code reviewers code review code according to these standards, while continuously improving the document during the code review process.
2. Execution of Code Reivew
A standard Code Reivew activity should be divided into three phases:
2.1. Preliminary preparation stage
Before a CR, make adequate preparations for the following contents.
2.1.1. Objects of CR
When preparing CR code objects, we should pay attention to the amount of code. If the amount of code is relatively large, it is necessary to decompose the code, determine the key code, and perform CR on the key code, which can achieve the purpose of inferring others.
2.1.2. CR content
We review a lot of code, such as whether the code is written properly (annotation writing format, naming conventions, etc.), technical processing specifications (exception handling, log processing, code organization structure, etc.), business implementation, etc. We cannot hope to complete the review of all these contents through one CR activity, so we must set the content boundaries of this CR activity and determine the focus of the review;
2.1.3. Review norms and standards It is necessary to design and determine review norms and standards
before CR. Through the norms and standards, we can have evidence and reasons to follow in the review process, and can also achieve uniform standards.
2.1.4. Selecting Participants of CR Activities
Before CR starts, all participants must be informed of the object of this CR activity, the content of the review, and the norms and standards of the review.
2.1.5. Choose how the CR campaign will be implemented.
There are many forms of CR activities for us to choose from. We can choose desktop CR, demo CR, one-to-one seat CR and so on according to the actual situation.

2.2. Implementation stage
Adequate preparation in advance is only the premise of doing a good job in CR activities. In the process of CR implementation, we must do the following work.
2.2.1. Accurate records
For the problems found in the CR process, we must record clearly and accurately, and we can use the problem point record sheet to clearly record the items and content.
2.2.2. In the process of explaining and asking
CR, the code author's explanation and the reviewer's questioning method should be adopted. The reviewer can't just ask questions when they find a problem, but also ask the code author to explain a specific problem according to the content of the review.
2.2.3. Item-by- item
review The content of the review determined in advance should be reviewed item by item, and cannot be swept away due to factors such as lack of time.
2.2.4. Pay attention to the atmosphere When
carrying out the review, it is necessary to create an atmosphere for discussing and solving problems. The review meeting cannot be turned into a criticism meeting, which will affect the enthusiasm of the relevant personnel.
2.3. Follow-up after the fact. 2.3.1. Confirmation of the problems found
After CR is completed, the following contents need to be determined first for the problems found.
1. The difficulty of the problem point and the scope of influence;
2. 2. The person responsible for solving the problem and the person who confirms the correction result of the problem point;
2. Timeframe for resolving issues.
2.32. The person responsible
for correcting the problem, in the process of correcting the problem point, three aspects should be recorded.
1. The cause of the problem point;
2. 2. Countermeasures to solve problems
; Corrected content.
2.3.3. Confirmer of
the correction result As the confirmer of the correction result, the correction result must be fully confirmed in a timely manner according to the time limit agreed in advance.

3. Notes 3.1. Frequent Code Review
(1) The more code to be reviewed, the more code to be refactored and rewritten. And the more suggestions that are not accepted by the program author, the more spit wars will be.
(2) The longer programmers write code, the more personal things programmers add to their code.
(3) The closer you get to the software release deadline, the less you can change the code.
3.2. The code review should not be too formal and short.
Forget the checklist of the code review, go to your colleague's seat, ask him to sit in front of your computer like a master, and then spend 5 minutes talking to him Your code, give him another 5 minutes to comment on your code, that's better than anything. And if you use a Checklist to make this thing very formal, one of the following two things must happen:
(1) Only things that exist on the Checklist will be reviewed.
(2) Code Reviews have become a courtesy thing, your colleague will pretend to care about your code, but in fact he wants to leave you as soon as possible.
Only informal code reviews will make you and reviewers relax. Only when people relax will they be very real and sincere. Remember that Review is only a form, and it is most real only when meaningful and constructive suggestions and opinions are obtained through mutual discussions in mutual trust. Otherwise, the author-reviewer relationship becomes a thief-police relationship.

3.3. Let different people review your code as much as possible
If possible, don't always find only one person to review your code, different people have different ways of thinking and have different opinions, so different people can Comprehensively review your code from all aspects.
But don't have too many people, but it will be counterproductive. Basically, no more than 3 people, this is because this is the maximum size of people that can be discussed together.

Here are a few advantages:
(1) It's always good to review code from different directions.
(2) More people will help you maintain your code in the future.
(3) This is also a way to increase team cohesion.
3.4. Maintain a positive attitude The biggest problem for
programmers is "conceit", especially when we Reivew other people's code, I have seen countless scenes, when programmers start to criticize other people's code during Code Review, Question the competence of others. It’s ridiculous, I analyzed it, and these kinds of programmers don’t actually have any skills, because the purpose of accusing each other is to tell everyone how good they are. Programmers who rely on this method to express themselves are actually The legendary "half bottle of water".

Therefore, both code authors and reviewers need a positive attitude. The author needs to be able to accept other people's suggestions with humility, because other people's suggestions are for you to do better; reviewers also need to take a Give your opinion to the author in a positive and positive manner, because that is your comrade in the trenches with you. Remember, you are not a piece of code, you are a person!

3.5. Learn to enjoy Code Reivew
This is probably the most important tip, if you go to a group where everyone loves Code Reivew, then you will enter a vibrant place where everyone can write Write very good quality code, where you don't need managers to manage, the team adapts to all changes, they learn from each other, they help each other, not only write good code, but the team and everyone in it will automatically evolve , and most importantly, this is a team.