In addition to Weibo, there is also WeChat
Please pay attention
WeChat public account
Shulou
2025-03-28 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Internet Technology >
Share
Shulou(Shulou.com)06/02 Report--
CodeReview specification what, many novices are not very clear about this, in order to help you solve this problem, the following small series will explain in detail for everyone, there are people who need this can learn, I hope you can gain something.
objectives and principles
Improve code quality, identify potential defects early, and reduce the cost of modifying/compensating defects
Promote knowledge sharing within the team and improve the overall level of the team
The review process is also a process of refactoring ideas for reviewers to help more people understand the system.
It is a means of transferring knowledge so that others unfamiliar with the code know the author's intentions and ideas, so that it can be easily maintained later.
Can be used to confirm that their design and implementation is a clear and simple
Encourage learning from each other's strengths and virtues
Quickly and efficiently complete Code Review
processes and rules
Use Git Flow + Pull Request (PR) mode for Code Review.
Git Flow
Pull Request(PR)
Description of Pull Request
PR submission only after completion of task
Never have multiple tasks in a PR unless they are closely related.
After PR submission, only code for Review discovery is allowed to be submitted again. Unless there is sufficient reason, it is strictly prohibited to submit code for other tasks in the same PR again.
When submitting PR, there is a description box, and the content will be automatically merged according to the Commit message. Remember not to use auto-generated descriptions if a single submission contains many Commits. Please describe in short but descriptive language (ideally within 3 sentences) what you changed, what problems you solved, and what changes people need to look out for that have a big impact. In particular, if you make changes to basic, common components, be sure to include a separate line with special instructions.
PR should be merged or rejected within 1 - 2 business days
After initiating the Pull Request, please send the link to the Pull Request to the code reviewer via Email to notify the other party to review it in time. (BUG Repair class must complete the merger or reject on the same day, function class or feel that there is a major adjustment needs to meet Review must specify the time and meeting personnel in the email)
Code Review Checklist
Code Review mainly checks whether there are problems in the following aspects of the code:
code consistency, coding style, code security issues, code redundancy, whether it is properly designed to meet requirements (functionality, performance), and so on
integrity check
Does the code fully implement the functional requirements set forth in the design document
Has the code been integrated and debugged according to the design documentation
Has the code created the required database, including the correct initialization data
Are there any undefined or unreferenced variables, constants, or data types in your code
consistency check
Does the logic of the code conform to the design document
Whether the format, symbol, structure and other styles used in the code are consistent
correctness checking
Does the code conform to established standards
All variables are correctly defined and used
All comments are accurate
All program calls use the correct number of arguments
modifiability check
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 contain cross-references or data dictionaries describing how the program accesses variables and constants?
Does the code have only one exit and one entry (except for serious exception handling)
predictability check
Does the code use a development language with well-defined syntax and semantics
Does the code avoid dependency on functionality provided by default in the development language
Is the code inadvertently trapped in an endless loop?
Does the code avoid infinite recursion
robustness check
Exception handling and cleanup (freeing) resources
Does the code take steps to avoid runtime errors (such as array boundary overflow, division by zero, value out of bounds, stack overflow, etc.)
structural inspection
Does each function of the program exist as an identifiable block of code
Does the loop have only one entry?
traceability check
Does the code uniquely identify each program
Is there a cross-referencing framework that can be used to map code and development documentation to each other
Does the code include a revision history in which changes to the code and reasons for them are documented?
Are all safety features identified
intelligibility check
Are comments clear enough to describe each subroutine
Is ambiguous or unnecessarily complex code used, and is it clearly annotated
Use uniform formatting techniques (indentation, white space, etc.) to enhance code clarity
Are naming rules defined in a way that facilitates memorization and reflects type?
Each variable defines a legal range of values
Does the algorithm in the code conform to the mathematical model described in the development documentation
verifiability check
Is the implementation technique in the code easy to test
the reusability
DRY (Do Not Repeat Yourself) Principle: The same code should not be repeated more than twice.
Consider reusable services, features, and components
Consider generic functions and classes
scalability of
Easily add functionality with minimal changes to existing code. One component can be replaced by a better one.
safety
Perform authentication, authorization, input data validation, avoid security threats such as SQL injection and cross-site scripting (XSS), encrypt sensitive data (passwords, credit card information, etc.)
performance
Use the appropriate data type, e.g. StringBuilder, generic collection class
Lazy loading, asynchronous and parallel processing
Cache and session/application data
Code review includes but is not limited to the above checklists. Submitters should complete the code format, architecture design, object-oriented analysis and design locally.
Remarks:
Java server development must follow Alibaba Java Development Manual (Ultimate Edition),IDEA installation of related plug-ins has an alarm prompt not allowed to submit merge
Steps to Code Review
The code writer and the code reviewer sit together, and the code writer explains the code and related logic in turn according to UC, from Web layer->DAO layer;
Code reviewers are free to ask their own questions along the way and actively discover hidden bugs; these bugs are documented.
After the code is explained, the code reviewer schedules himself a few hours to review the code again. The code needs to be read line by line. At the same time, the code needs to be looked at comprehensively to ensure that the code as a whole is well designed.
The code reviewer writes a "code review report" according to the review results. The "review report" records the problems found and suggestions for modification, and then sends the "review report" to relevant personnel.
The code writer modifies the code according to the modification opinions given in the Code Review Report. If there is any unclear place, he can actively raise it to the code reviewer.
The code writer gives feedback after the bug fix is complete.
Code reviewers update the Code Review specification for valuable issues identified in Code Review, and email all technical staff in groups for issues that are particularly worth reminding.
Remarks:
Code Review Required Documents:
Code Review Specification document: Document the standards that code should follow.
Code reviewers Code Review code against these criteria, while refining the document during the Code Review process.
Code Review Implementation Preparation Phase
Review norms and standards
It is necessary to design and determine evaluation norms and standards before CR. Through norms and standards, we can have evidence to follow and reason to follow in the review process, and we can also achieve standard unification.
Select participants for CR activities
Before CR starts, all participants must be notified by email of the CR activity's target, review content, and review specifications and standards.
Select the implementation of CR activities
CR activities have many forms for us to choose from, we can choose desktop CR, demonstration CR, one-on-one seat CR and so on according to the actual situation. (Generally, according to the new function desktop CR, milestone function demonstration CR, BUG repair one-to-one seat CR)
implementation phase
Adequate preparation in advance is only the premise of CR activities. During CR implementation, we should do the following work well.
accurate records
For the problems found in CR process, we must clearly and accurately record them. We can use the problem point record sheet to clearly record the items and contents.
Explanation and Questions
CR process, to use the code author explanation and reviewer questions. Reviewers cannot ask questions only when they find a problem, but also ask code authors to explain a particular problem based on the content of this review.
be reviewed
The contents of the examination determined in advance should be examined item by item, and should not be swept away because of factors such as insufficient time.
Watch the atmosphere.
When carrying out the review, we should create an atmosphere for discussing and solving problems. We should not turn the review meeting into a critical meeting, which will affect the enthusiasm of relevant personnel.
follow-up afterwards
After confirming the CR of the discovered problem, the following contents should be determined first for the discovered problem.
the difficulty of the problem points and the scope of influence;
The person responsible for solving the problem and the confirmer of the correction result of the problem point;
Time frame for solving problem points.
The person responsible for correcting the problem shall record the contents of three aspects during the correction process of the problem point. The cause of the problem;
Countermeasures to solve problem points;
Corrected content.
As the confirmer of the correction result, the confirmer of the correction result must confirm the correction result comprehensively and timely according to the time limit agreed in advance.
precautions
Code Review is done frequently.
(1) The more code to Review, the more code to refactor and rewrite. And the less accepted the program's author will be, the more suggestions and spittle wars there will be.
(2) The longer programmers write code, the more personal things programmers add to their code.
(3) The closer we get to the deadline for software release, the less we can change the code.
Code Review is not too formal and short.
Forget the Checklist for code review, go to your colleague's seat, invite him to sit in front of your computer like a master, and then spend five minutes talking to him about your code, and give him another five minutes to comment on your code, which is better than anything. And if you use a Checklist to make it official, one of two things will happen:
(1) Only things that exist on the Checklist are reviewed.
(2) Code Reviews become something of a formality, and your colleague will pretend to care about your code, but in fact he wants to leave you as soon as possible.
Only informal Code Review will make you and the judges relax, and only when people relax will they be real and sincere. Remember that Review is only a form, and only in mutual trust through mutual discussion to get meaningful and constructive suggestions and opinions, that is the most real. Otherwise, the relationship between author and reviewer becomes that of thief and cop.
Get as many different people as possible to Review your code
If possible, don't always find only one person to Review your code, different people have different ways of thinking and different opinions, so different people can comprehensively review your code from all aspects.
But not too many people, too many people is counterproductive, basically, no more than three people, this is because this is the largest size of people that can be discussed together.
Here are a few advantages:
(1) It is always good to review code from different directions.
(2) There will be more people to help you maintain your code in the future.
(3) This is also a way to increase team cohesion.
Keep a positive attitude.
The biggest problem with programmers is "ego," especially when we Review other people's code. I've seen countless scenes where programmers start to attack other people's code and question their abilities during Code Review. It's ridiculous. I analyzed it. This kind of programmer actually doesn't have any ability, because they accuse each other of wanting to tell everyone how awesome they are. The programmer who shows himself by this means is actually what the legend calls "half bottle of water."
Therefore, both the author and the reviewer need a positive attitude. The author needs to be able to accept other people's suggestions modestly, because other people's suggestions are for you to do better. The reviewer also needs to give opinions to the author in a positive attitude, because it is your comrade in the trench. Remember, you are not a piece of code, you are a person!
Learn to enjoy Code Review
This is probably the most important hint, if you go to a group where everyone likes Code Review, then you will enter a vibrant place where everyone can write very good code, where you don't need management from managers, the team will adapt 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 the most important thing is, This is a team.
Did reading the above help you? If you still want to have further understanding of related knowledge or read more related articles, please pay attention to the industry information channel, thank you for your support.
Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.
Views: 0
*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.
Continue with the installation of the previous hadoop.First, install zookooper1. Decompress zookoope
"Every 5-10 years, there's a rare product, a really special, very unusual product that's the most un
© 2024 shulou.com SLNews company. All rights reserved.