Four phases of code quality control

This is a creation in Article, where the information may have evolved or changed.

Background

The code quality discussed in this article refers to the quality of the code itself, including features such as complexity, repetition rate, code style, and so on. Code is the common property of the team, and the code quality is the direct embodiment of the team's technical level and management.

Falling code quality usually leads to a vicious cycle of self-causation:

• Broken window effect: The psychological burden of continuing to produce rotten code on Rotten code is much smaller
• Contagious: Bad code passes a negative message that doesn't care about quality, only sees business outcomes, hurts the team's technical zeal and working atmosphere, and leads to more bad code.

This article will analyze the intrinsic mechanism of code quality degradation and share some practical experience in code quality control.

Entropy increment law and code quality

The law of entropy tells us that a closed system tends to increase in entropy, that is, the degree of disorder of systems is only increasing.

For software projects, code quality represents the order of the system, the increase of bad code is the embodiment of the rise of the system disorder. In the absence of external influence of the case, the rotten code will only the original more.

In order to maintain the orderly system, the external energy is required to enter the system continuously. For code quality, we need to proactively invest in resources to consciously suppress more and more natural trends in rotten code.

Classic Loops

The common cause of bad code is a large business pressure, resulting in no time or willingness to pay attention to code quality. Since the production of bad code with the compromise of business pressure, development efficiency will be reduced, resulting in greater business pressure, creating a typical vicious circle.

In order to deal with the business pressure, the common practice is to add manpower to the project, but simply to increase the manpower, will be due to inconsistent style, communication costs, and other reasons cause bad code more.

To curb this vicious cycle requires a multi-pronged approach that proactively controls the quality of the code and continuously upgrades the technology to solve the problem systematically.

But quality control and technology upgrades require long-term investment to produce results. Often people are inclined to solve the problem of business pressure quickly by increasing manpower, ignoring the negative effect on the quality of code, which leads to the poor quality of the code.

Four Stages

The four stages that I typically need to go through to code quality control are called "Four Modernizations":

• Normalization-establishing code specifications and Codes review system
• Automation-use tools to automatically check code quality
• Process-binds code quality checks to code flow processes
• Centralize-centrally manage code specifications and achieve transparency in the quality of the team as a whole

Phase One: Normalization

The basis for ensuring code quality is to establish code specifications for the team, usually including:

• Style specification-style issues such as indentation, line wrapping, capitalization, etc.
• Practice specifications-Avoid some common pitfalls, or best practices for specific issues
• Business specifications-specific business-related requirements, such as keywords in the copywriting

Code specifications for a team usually exist as documents for new people to learn. But this form of documentation is common in situations where new people don't look back after they've seen it, and it's hard to create real constraints on the actual writing code.

On the basis of the specification, the specification will be landed by code review. In code review, you can communicate with each other about the quality issues and supervise each other to form the habit of the team attaching importance to the code.

For code review, refer to another article: Code review System and team culture

Phase II: Automation

Automation refers to the use of automated tools for quality checks based on code specifications, usually including:

• Code specification Check-includes style specification, practice specification, Business specification
• Repetition rate-repeated occurrences of code chunks, usually requiring less than 5%
• Complexity-Total number of rows, module size, loop complexity, etc.
• Check coverage-the number of rows inspected as a percentage of the total number of code base rows

Automated quality checks can cover most common problems, improve development efficiency, and reduce the cost of manual code review.

The rule set for the automated Check tool corresponds directly to the code specification. Through the editor plug-in, the code is written directly to the test results. At this stage, the team's code specification document no longer needs to state the details, and developers can see the code specification directly by looking at the rule set of the automation tool.

Phase Three: Process

The process is meant to bind the automated code quality check and code review to the process of flow, thus ensuring that all on-line code is checked by multiple parts of the machine and manual.

Code Flow process:

The time to perform automated code quality checks:

• When editing-use the editor plugin to run quality checks in real time
• Build-run quality checks either locally or in the build script of the development machine
• On commit-run a quality check when using git Hooks to commit code or generate pull request
• When publishing-Perform a quality check in the release script, usually with automated tests

Effect of quality check and code flow binding:

In addition to the manual code review, the quality checks of each link are automatically run by the machine and do not bring additional costs to the developer.

Phase IV: Centering

As teams grow larger and more projects grow, code quality control faces the following issues:

• Different projects use code specifications differently
• Some projects due to relaxation requirements, no access to quality checks, or there are a large number of non-fixed defects
• It is not possible to reflect the quality of each project from the overall team level.

In order to deal with the above problems, we need to build a centralized code quality control system, including:

• Code specification Unified Management. Use Git or NPM package to manage automated code quality checks for rule sets, automatic installation, not local write rules. A team, a class of projects, a set of rules.
• Use unified, continuous Integration services. Items that are not approved by the quality check cannot be launched.
• Establish a code quality scoring system. Enables cross-cutting between projects and projects, and the project itself can be compared vertically, with aggregated feedback.

Summarize

In the face of business pressure, people often tend to reduce business pressure by increasing manpower. However, from the overall system point of view, the increase in human resources will lead to poor code quality, development efficiency decline, and thus again increase business pressure. This kind of code quality is getting worse cycle, is the entropy increases the law in the Software engineering field Vivid embodiment.

In order to suppress this cycle, we need to consciously invest in resources to build a code quality control system. This process is divided into four stages: normalization, automation, process, and centrality. Each stage has a different point of focus.

At present, our team is building code quality Testing Center, is a centralized quality control of a practice, has been connected to dozens of projects in the pilot. I will continue to elaborate on the details of the central construction in the following articles.