Network Security Internet Technology Development Database Servers Mobile Phone Android Software Apple Software Computer Software News IT Information

In addition to Weibo, there is also WeChat

Please pay attention

WeChat public account

Shulou

What are the CodeReview specifications?

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.

Share To

Internet Technology

Wechat

© 2024 shulou.com SLNews company. All rights reserved.

12
Report