background

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

Code quality degradation often feeds on itself, leading to a vicious cycle:

  • Broken Windows: The psychological burden of continuing to produce broken code on top of broken code is much lower
  • Contagiousness: Bad code conveys a negative message of not caring about quality but only about business results, which can hurt the technical enthusiasm and work atmosphere of the team and lead to more bad code

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

Law of entropy increase and code quality

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

For software projects, code quality represents the order of the system, and the increase of rotten code is the embodiment of the rising disorder of the system. In the absence of external forces, bad code only grows.

To keep the system in order, you need a constant input of energy from the outside. For code quality, we need to invest resources proactively to consciously curb the natural tendency of more and more bad code.

Classic cycle

A common cause of bad code is business pressure that doesn’t have the time or inclination to focus on code quality. It’s a classic vicious cycle because when you yield to business pressure and produce bad code, your productivity drops, which leads to more business pressure.


In response to business pressures, it is common to add people to a project, but simply adding people will lead to more bad code due to inconsistent styles, increased communication costs, and so on.


Stopping this vicious cycle requires a multi-pronged approach of proactive code quality control and continuous technology upgrades to address problems systematically.

But quality control and technology upgrading require long-term investment to make a difference. Too often, people tend to quickly solve business stress problems by adding people, while ignoring the negative impact on code quality, resulting in poorer code quality.

Four stages

I call the four common stages of code quality control the “four modernizations” :

  • Standardization – Establish Code specification and Code Review system
  • Automation – Use tools to automatically check code quality
  • Streamlining – Tying code quality checks to code flow processes
  • Centralization – Centralized management of code specifications and transparency of quality status from a team perspective

Stage 1: normalization

The basis for ensuring code quality is to establish a team code specification, which usually includes:

  • Style specification – Indent, newline, case and other style issues
  • Practices – Avoid common pitfalls, or best practices for specific problems
  • Business specification – specific requirements related to the business, such as keywords in the copy

A team’s code specification usually exists as a document for newcomers to learn. But documentation is a form that is often read by new people and then never reviewed again, and it’s hard to really constrain the actual code you’re writing.

On the basis of the specification, the specification should be implemented through Code Review. In Code Review, everyone can communicate with each other about Code quality problems and supervise each other to form a habit of valuing Code.

For Code Review, see another article: Code Review System and Team Culture

Phase two: Automation

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

  • Code specification review – includes style specification, practice specification, business specification
  • Repetition rate – The percentage of code blocks that repeat, usually under 5%
  • Complexity – total number of lines, module size, loop complexity, etc
  • Check coverage – The number of lines checked as a percentage of the total lines in the code base

Automated quality checks can cover most common problems, increasing development efficiency and reducing the cost of manual Code Review.

The rule set of the automated inspection tool corresponds directly to the code specification. With the editor plug-in, check results are given directly at code writing time. At this stage, the team’s code specification documentation is no longer required to state details, and developers can look directly at the automation tool’s rule set to understand the code specification.

Stage 3: Process

Streamline means to bind automated Code quality inspection and Code Review to the process of Code flow, so as to ensure that all online Code is checked by machines and humans.

Code flow process:

When to perform automated code quality checks:

  • Edit-time – Use the editor plug-in to run quality checks in real time
  • Build time – Run quality checks locally or in the build script on the development machine
  • Commit time – Use Git Hooks to run quality checks when committing code or generating a Pull Request
  • Release time – Do another quality check in the release script, usually along with automated tests

Binding quality checks to code flow:

In addition to manual Code Review, all Code quality checks are automated by the machine, with no additional cost to the developer.


Stage 4: Centralization

As teams grow in size and projects grow in number, code quality control faces the following problems:

  • Different projects use different code specifications
  • Some projects have no access to quality checks due to relaxed requirements, or have a large number of unfixed defects
  • The quality comparison of each project cannot be reflected from the overall level of the team

In order to cope with the above problems, it is necessary to build a centralized code quality control system. Key points include:

  • Unified management of code specifications. Use Git or NPM packages to manage the rule set for automated code quality checks, automatically installed, not written locally. One team, one type of project, one set of rules.
  • Use a unified continuous integration service. Projects that fail quality inspection cannot be put online.
  • Establish code quality scoring system. Make horizontal comparisons between projects, vertical comparisons within projects, and aggregate feedback.

conclusion

When faced with business stress, people often tend to relieve it by adding people. From a system-wide perspective, however, increased manpower leads to poorer code quality and less efficient development, which again increases the pressure on the business. This cycle of worsening code quality is a vivid manifestation of the law of entropy in software engineering.

To curb this cycle, we need to consciously invest resources in code quality control. This process is divided into four stages: standardization, automation, process and centralization. Each stage has a different focus.

At present, our team is building a code quality testing center, which is a practice of centralized quality control and has been connected to dozens of projects for pilot. I will continue to elaborate on the details of centralization construction in a subsequent article.