content
4. Specify code review specifications
5. Execute code review specifications
6. Carry out PR Bash activities
1. Background
2019 has become history, and 2020 has quietly arrived. In 2019, our R&D team experienced personnel changes and rapid business growth. In the daily agile R&D process, operation and maintenance process, and platform upgrade process, a series of inescapable problems occurred, which in turn produced some negative impacts. Near the end of the year, as the leader of the project team, I deeply reflected on the performance of the individual and the management of the R&D team in 2019, and came to a fundamental reason that our R&D team wrote code in a random style and lacked code control. , and thus buried a lot of hidden dangers.
In order to better and more efficiently support the company's business goals in 2020, I have formulated the "R&D Team Code Review Process (Trial Version)" to conduct a more rigorous review of the code written by each team member, and try to find some of the code as much as possible. Low-level BUG, and then improve the quality of the product, as follows:
2. Goals
(1) Built-in quality, real-time detection and removal of defects, smooth and high-quality delivery of effective value to users;
(2) Continue to optimize, improve the overall coding ability of individuals and teams, and create the ultimate experience;
(3) Step on pits as little as possible, eliminate repeated pits, effectively improve platform stability, improve collaboration efficiency, and reduce communication, operation and maintenance costs;
(4) Try to avoid the situation of "frequent online bugs, leaders get angry, employees complain constantly, and it is difficult to find bugs".
3. Process
As shown in the figure above, the team carried out code review work and tried to carry out the following aspects:
1. Formulate code review specifications, combined with the seriousness of non-standard code writing ( naming style, constant definitions, comment specifications, control statements, exception handling, unit testing, table building specifications, SQL statements, etc. ) in the daily programming process of project team members The review specification is formulated in stages according to the degree of development, and do not improve too much each time, otherwise it will not be able to be truly implemented (each iteration cycle can only focus on about 5 to 10 improvement items);
2. After the code review specification is formulated, it is necessary to organize relevant team members to hold a discussion meeting to reach a consensus on the form, process, content and other details of the specification, clarify the process rules, make the team unanimously understand and commit, and facilitate strict compliance with the Code Review Specification in the later stage. "implement;
3. Perform code review in accordance with the "Code Review Specification", strictly control the code quality, and try to find potential logic problems and bugs as much as possible, thereby reducing the cost of bug modification and improving the overall performance of the project;
4. Carry out PR Bash activities and set out a special time period. All the personnel involved in the project will concentrate all their energy to find bugs for the approved PRs, in order to measure and improve the code quality from various dimensions. The frequency of this activity should not be too high, it can be carried out once a month, or once every two months;
5. Summarize and formulate the next code review specification, and carry out step-by-step improvements according to the implementation of the previous stage and other non-standard programming habits existing in the project team.
4. Specify code review specifications
Combined with the recent implementation of the code review of the Guizhou project, the first round of code review specifications are mainly improved in terms of naming style, constant definition, code style, comment style, control statements, etc. The details are as follows:
4.1. Naming style
(1) The naming in the code is strictly forbidden to use the combination of pinyin and English, and it is not allowed to use Chinese directly
(2) The class name uses the UpperCamelCase style; the method name, parameter name, member variable, and local variable all use the lowerCamelCase style, which must follow the camel case form
(3) The package name is uniformly lowercase, and there is only one English word with natural semantics between the dot separators. The package name uses the singular form uniformly, but if the class name has a plural meaning, the class name can use the plural form
4.2, constant definition
(1) Do not allow any magic values (ie constants that are not predefined) to appear directly in the code
(2) All constant names are capitalized, and words are separated by underscores. To express complete semantics, try not to use abbreviated forms.
4.3, code style
(1) The limit of the number of characters in a single line is not more than 120, and a new line is required if it exceeds
(2) The total number of lines for a single method does not exceed 80 lines. Description: The total number of lines including the method signature, closing closing brace, code within the method, comments, blank lines, carriage returns and any invisible characters does not exceed 80 lines
(3) Copying and pasting the code at will will inevitably lead to the repetition of the code. When you need to modify it later, you need to modify all the copies, which is easy to miss. Extract common methods when necessary, or abstract public classes, or even componentize
4.4. Annotation style
(1) All classes must add creator and creation date
(2) Comments on classes, class attributes, and class methods must use the Javadoc specification, use the /**content*/ format, and cannot use the //xxx method
(3) All abstract methods (including methods in interfaces) must be annotated with Javadoc. In addition to return values, parameters, and exception descriptions, they must also indicate what the method does and what functions it implements.
(4) When the code is modified, the comments should also be modified accordingly, especially the modification of parameters, return values, exceptions, core logic, etc.
4.5. Control Statements
(1) The logic judgment code of if-else with more than 3 layers can be realized by using guard statement, strategy mode, state mode, etc.
(2) In the loop body, the connection method of strings is extended using the append method of StringBuilder
5. Execute code review specifications
(1) The content of the project team is unified in the IDE environment, and the SonarLint plug-in is installed (SonarLint is a code quality detection plug-in that can help us detect bad smells in the code);
(2) When team members are writing code, they need to take branches separately (do not submit code directly on the master and feature branches), and after the functions to be developed or the bugs to be fixed are processed, the code to be written is processed through SonarLint. Code quality inspection, code refactoring is carried out according to the inspection results and rectification suggestions (the improvement items agreed in the "Code Review Specification" agreed upon by the team are the key points to be paid attention to, and those that do not conform to the code review specification must not submit the code);
(3) Push high-quality code to the code cloud, and then initiate a PR request according to the actual situation, and assign relevant reviewers. The reviewers must strictly review the code submitted by the initiator in accordance with the Code Review Specifications. After the review is passed, the PR can be approved
6. Carry out PR Bash activities
PR Bash, also known as PR cleaning, refers to a special time period at the end of the project development milestones (such as before the Beta version is released), during this period, all the people involved in the project will focus all their energy on finding the project. Bugs, the purpose is to measure and experience the product from all dimensions.
After the requirements of the release version are completed, try to arrange a special period of time, organize team members together, and focus on finding problems for all the functions of the release plan. If the PR Bash activities are implemented in place, some logical errors of the existing products can be found, the negative effects that may be caused after the launch can be avoided, and great losses can be avoided in advance. Through these PR Bash activities, the product verification process can be greatly advanced, which not only achieves a better experience effect, but also effectively guarantees the quality of the launch.
To organize a PR Bash event, you can start from the following aspects, as follows:
(1) Time: You can choose this iteration cycle or several iteration cycles, so after the function development is completed, this activity takes two to three hours (it can also be arranged reasonably according to the actual situation of the respective team), before the activity starts, Make every effort to eliminate all interference factors;
(2) Location: You need to find a separate, relatively quiet space that is isolated from the outside world. Participants are encouraged to bring their own notebooks, so that everyone can concentrate on doing this as much as possible. During the activity, you can prepare some fruits and snacks to keep the activity as relaxed and pleasant as possible;
(3) Personnel: In addition to R&D members and testers, people with different roles in the project team such as PO and operation and maintenance can participate, so that they can review the code from different perspectives and find possible problems as much as possible;
(4) On-site arrangement: You can directly post the questions from the on-site feedback on the whiteboard, or use the electronic whiteboard to scroll and update the ranking of bugs or suggestions. It should be noted that creating an interactive atmosphere is very critical;
(5) End of the event: After the event, the number of bugs or suggestions should be announced directly, prizes will be given on the spot, and the whole group will be notified by email. Finally, after the bugs are deduplicated, they must be classified and graded to determine which bugs must be fixed and which ones will be better if they are changed. Also, don’t forget to publicize the results, clarify the repair plan, and formulate the review specifications for the next stage.