preface
Code review, pair programming, and static analysis are generally considered to be beneficial to improving the overall quality of your code when performed rigorously. There are limits to what people can do to quickly and successfully perform endless, repetitive tasks. Using static analysis tools to perform reviews is becoming increasingly common. It has the following major advantages:
1) The tool has low operating cost and only needs to be manually configured and executed once, and then it can be automatically executed, saving a lot of manpower
2) Tool review is more rational and objective than manual review
Use tools for automated code review to solve 80% of problems, let a person to deal with the important problem of the other 20% automated review can make artificial review more effectively, the underlying code has been through a scan, artificial can focus on the review of the automation cannot handle ways, such as code whether meet the requirements, whether in the long run, easy maintenance, etc.
Review and its Value
Testing is dynamic; it executes software for the purpose of testing functionality. Testing includes: unit testing, component testing, system testing and so on.
Review is the analysis of code based on a predefined set of rules, guided by defined standards. These include: “syntax” of coding, compliance with standard architectural layers, repetitive code, etc.
Tests and reviews are similar in that they do not modify the code, but merely point out where problems might occur.
If a defect is discovered months after it is in the code, time is lost and the context of the problem is lost. With tool monitoring, defects can be found and fixed in a matter of minutes, which will no doubt significantly improve code quality.
Moreover, the number of lines of code written is not an objective measure of developer productivity, some code metrics include comments, and this measurement encourages copy-and-paste. The introduction of code review can provide a way to address this problem.
Continuous review reduces the time between problem discovery and fixing, and identifies the parts of the system that need special attention. Performing continuous automated reviews in CI systems can actively prevent defects and ensure a repeatable and consistent manner.
Reduce code complexity
Cyclomatic complexity value (CCN), which measures complexity by the number of execution paths of a method, becomes a measure, usually an integer value. There is a relationship between paths and defects in surface code. Code with CNN greater than 10 has a greater risk of defects than other code of the same size.
By implementing the review tool, you typically get the following reports:
1) Number of classes, methods, non-commented lines of code, and comment lines of various styles
2) The number of non-commenting lines of code, methods, inner classes, and comments in a class
3) The total number of uncommented lines of code and cyclomatic complexity
As mentioned above, high cyclomatic complexity usually indicates high defect risk. After obtaining the table, check whether the corresponding test exists:
1) Make the number of tests equal to cyclomatic complexity, if any
2) If you don’t have any, write some tests right away and reduce risk through refactoring
The most effective way to reduce cyclomatic complexity is to use “extraction method techniques” that break complexity down into smaller, more manageable, and more testable methods.
If you find that the CCN value has been increasing in the review report, you can use the following methods:
1) Provide a sufficient number of relevant tests to reduce risks
2) Evaluate the possibility of refactoring to reduce long-term maintenance issues
These reviews can be performed as part of an automated build process that identifies areas of code that are more complex for improvement.
Conduct continuous design reviews
When an object has a dependency on another object and a dependency changes, the object may have problems. Afferent coupling and efferent coupling help to determine overcoupling.
Instability = efferent coupling/(efferent coupling + afferent coupling)
A value of 0 indicates stable and 1 indicates unstable.
Objects with high afferent coupling will cause damage, and accessories with high efferent coupling will be broken. Write enough tests for accessories to reach a certain code coverage rate to help locate problems quickly. The following measures can be taken when monitoring the trend of a large increase in coupling:
1) Create tests immediately based on the risks found
2) Assess the possible long-term impact of coupling on vulnerability
3) After testing, consider refactoring to make future changes easier
Maintain coding standards
Coding standards facilitate a common understanding of code by different teams and developers. Standardization of code structure enables different people to quickly determine the behavior of code and make changes as needed, resulting in faster response during development and less dependence on necessary people or teams.
Project too much coding standards, including conditional statements the brace position, naming conventions, design practices, etc., for perusal and bear in mind that these standards for developers have a lot of pressure, but also easy to forget that in the process of work USES the tool to supervise, can timely check corresponding problems in the corresponding regulations, changes in a timely manner.
During CI, code analysis tools can be executed whenever a change is made to a project’s version control repository. Analyze all code in case of file, structure or other system changes and inform relevant personnel through feedback mechanism. By constantly monitoring and reviewing code, teams can stay in compliance with architectural and coding guidelines, and problems can be found early and often, avoiding long-term maintenance issues.
Reduce duplicate code
Copy-and-paste code happens all the time, and often the problem is that developers don’t even realize they’re doing it. Copy-and-paste usually happens when:
1) Database logic, including stored procedures and views
2) Compiled source code
3) Interpreted source code
4) Build scripts
5) Data and configuration files
The following problems may occur:
1) Increased maintenance costs and the need to find, report, analyze and fix defects multiple times
2) It is uncertain whether there are other defects
3) Increased testing costs for additional code written
These pitfalls can be mitigated by automated review tools that identify duplicates in your code and determine the rate of code duplication.
Determining code coverage
There are different ways to test for code coverage. Most methods focus only on “line coverage” (statement coverage), which means only that lines of code were executed, i.e., 7 out of 10 lines of code were executed in the test, and this method has 70% behavior coverage
Some tools also offer “branch coverage,” which attempts to measure coverage at a judgment point. For the branch coverage report, if there are two branches and both branches are executed during testing, the method can be said to have 100% branch coverage.
Monitoring coverage reports can help development teams quickly locate newly written code that does not have corresponding tests. For example, the previous coverage was 70%, but the coverage of this week’s update package is 60%.
1) The number of lines of code in the package increases, but the new code is not tested accordingly (or the new test does not effectively cover the new code)
2) Some test cases were deleted
Evaluating code quality
1) Frequency of coverage inspection
Code coverage tools make minor changes to the source code in order to generate reports, becoming “listeners” that take a little longer and can be used as secondary builds for tools that perform code coverage.
Because testing is divided into different phases, unit and component testing occurs frequently, and code review is not appropriate. You can run another set of tests after the system tests have been executed, with coverage checks turned on, after work or at night.
2) Coverage and performance
Coverage testing affects test performance. It is recommended not to perform performance, stress, and load tests at the same time.
Practice self-inspection
1) Are tests performed regularly, occasionally, or continuously? Are there compliance coverage checks?
2) Is code complexity being monitored?
3) Do you use tools to automate design reviews on an ongoing basis?
4) Is code duplication monitored?
5) Can you judge the current code coverage? How do you process it based on data feedback?
6) Does the build process produce coverage reports?