As the saying goes, no love, there is no reason to hate, of course, no reason to Code Review!
First, the purpose
- Ensure consistent coding style team
- Own code to give others see the development process need to pay attention to the code subconscious regulation, and the logical rigor.
- Ensure project quality, stifling the potential risks
- Although they will function after the completion of self-test, but inevitably left out some of the border point, or by thinking at some point limit.
- Enhance mutual
- Others learn the code, see master is how to write rigorous, simple, elegant code, and make their own control, Quqi essence, to its dregs!
- Convenient cross-maintenance
- Through cross Code Review process, learn about the different services, to facilitate post cross maintain, without having to spend more time to get started.
Second, how to carry out
- Pair
- At least two people as a group
- and on-line review process
- All items master is set to Protected, and set allowed to push for the No one, set the Merge checks must be resolved for the All discussions, the branch as a branch deployment
- When you create a development dev branch, and the same is set to Protected, allowed to push for the No one, set the Merge checks must be resolved for the All discussions, the development branch as branch
- Personal best branch in their own name, when needed review the code, put Merge Request to dev branch, the code review people review the code, for non-compliant code editing comment, the code until no question mark after the comment was resolved (at this time branch will allow merge)
- dev branch after the test no problem after line, MR to mention the master branch, now really on the line to complete the project
- collective
- Collective week will review the code a week, every review of the core code, the code is expected to collectively review the three students a week.
- Explain their own modules, preferably with complex business flowchart
- git hooks – pre commit
- The new project using ESLint as unified coding standard detection tool, every Git commit will determine whether the code compliant, only compliant in order to be submitted
Third, the self-test check list
After said before the self-test function to be complete, but the exact cut from what is not defined, then you can probably cut from the following aspects:
- Routine inspection
- If the code can be running?
- Whether the console has a significant error?
- Code has not achieved the desired effect of demand?
- Code logic is easy to understand? Code written for compliance? Whether as a component of?
- There are no duplicates create the wheel?
- Remove a large section of the code comments? (If commented code is available, it would not be submitted delete comment code to Git, and then delete the comments submitted code, to be able to roll back on it)
- Whether the timer with the life cycle of elimination? Controls whether a single button click?
- Security check
- The introduction of others (internal or other external bodies) dependencies, whether the risk is not available and upgrade feature is not available leading to exist?
- Are all requests using https, including image links, embedded applications on App page, whether to provide the https protocol link?
- Code comments, or whether to include a copy sensitive words?
- Document Inspector
- Is there a compliant annotations? Notes whether accurate description? Method parameters or whether the term is explained?
- Are third-party libraries use a sound file?
- Readme document is written specification? Is there an accurate description of the project?
- Performance Check
- Page load exceeds the 3s? What is the reason for more than 3s? There are no friendly tips?
- Code has no significant effect on logic and computing performance?
- Component-level control? Components of the communication is normal? Whether simple nested page?
Fourth, the scoring criteria
Score 30 points, 24 points or more are allowed to merge master code, requires less than 24 MR mention after optimization.
- demand
- 9-10: project a clear structure, reasonable assembly code logic rigorous, exhaustive function
- 6-8 points: no logical error, omission-free function
- 0-5: Code logic errors, omissions functions
- Code
- 9-10 points: The code is simple and reasonable comments, independent modules
- 6-8: moderate coupling module, the code is relatively simple
-0-5 point: higher coupling module, code comments is not clear, the code writing complex, non-standard naming
- readability
- 9-10: strict code specification, code logic is easy to understand, clear notes
- 6-8: logic code exists dyslexia, vague comments
- 0-5: chaos complex logic code, to understand extremely crash