背景

本文讨论的代码质量指的是代码本身的质量，包括复杂度、重复率、代码风格等要素。代码是团队的共同财产，代码质量是团队技术水平和管理水平的直接体现。

代码质量下降通常会自成因果，导致恶性循环：

• 破窗效应：在烂代码上继续生产烂代码的心理负担小很多
• 传染性：烂代码传递着一种不在意质量，只看业务成果的负面信息，会伤害团队的技术热情和工作氛围，导致更多烂代码出现

本文会分析代码质量下降的内在机制，并分享在代码质量管控方面的一些实践经验。

熵增定律与代码质量

熵增定律告诉我们，一个封闭系统总是趋向于熵增，也就是系统的无序程度只会不断增加。

 

对于软件项目来说，代码质量代表着系统的有序程度，烂代码增加就是系统无序性上升的体现。在无外力影响的情况下，烂代码只会原来越多。

为了维持系统有序，需要外界向系统不断输入能量。对于代码质量，我们需要主动投入资源，来有意识地抑制烂代码越来越多的自然趋势。

经典循环

烂代码产生的常见原因是业务压力大，导致没有时间或意愿讲究代码质量。因为向业务压力妥协而生产烂代码之后，开发效率会随之下降，导致业务压力更大，形成一种典型的恶性循环。

 

为了应对业务压力，常见的做法就是向项目中增加人力，但是单纯地增加人力的话，会因为风格不一致、沟通成本上升等原因导致烂代码更多。

 

要遏制这种恶性循环，需要多管齐下，主动对代码质量进行管控，并且持续进行技术升级，系统性地解决问题。

 

不过质量管控和技术升级需要长期投入才能产生效果。通常情况下人们还是倾向于通过增加人力快速地解决业务压力的问题，而忽略了对于代码质量的负面影响，导致代码质量越来越差。

四个阶段

我把代码质量管控通常需要经历的四个阶段，称之为“四个现代化”：

• 规范化 - 建立代码规范与Code Review制度
• 自动化 - 使用工具自动检查代码质量
• 流程化 - 将代码质量检查与代码流动过程绑定
• 中心化 - 以团队整体为视角，集中管理代码规范，并实现质量状况透明化

阶段一：规范化

保障代码质量的基础是建立团队的代码规范，通常包括：

• 风格规范 - 缩进、换行、大小写等风格问题
• 实践规范 - 规避一些常见的隐患，或者针对特定问题的最佳实践
• 业务规范 - 与业务有关的特殊要求，比如文案中的关键词

团队的代码规范通常以文档的形式存在，供新人们学习。但文档这种形式常见的情况就是新人看过之后就不再回顾了，也很难对实际写代码形成真正的约束。

在规范的基础上，要通过Code Review将规范落地。Code Review中大家可以对代码质量问题进行交流，并且相互监督，形成团队重视代码的习惯。

关于Code Review可以参考另一篇文章：

 

阶段二：自动化

自动化是指在代码规范的基础上，使用自动化工具进行质量检查，通常包括：

• 代码规范检查 - 包括风格规范、实践规范、业务规范
• 重复率 - 重复出现的代码区块占比，通常要求在5%以下
• 复杂度 - 总行数，模块大小，循环复杂度等
• 检查覆盖度 - 经过检查的行数占代码库总行数的比例

自动化质量检查可以覆盖多数常见问题，能够提升开发效率，也可以降低人工Code Review的成本。

自动化检查工具的规则集与代码规范直接对应。通过编辑器插件，在写代码的时候直接给出检查结果。到这个阶段，团队的代码规范文档已经不再需要陈述各种细节，开发者可以直接通过查看自动化工具的规则集来了解代码规范。

 

阶段三：流程化

流程化的意思是将自动化代码质量检查和Code Review与代码流动的过程绑定，从而保证所有上线的代码都经过机器与人工多个环节的检查。

代码流动过程：

执行自动化代码质量检查的时机：

• 编辑时 - 使用编辑器插件，实时运行质量检查
• 构建时 - 在本地或者开发机的构建脚本中运行质量检查
• 提交时 - 利用Git Hooks，提交代码或者生成Pull Request时运行质量检查
• 发布时 - 在发布脚本中再做一次质量检查，通常与自动化测试放在一起

质量检查与代码流动绑定后的效果：

除了人工的Code Review之外，各个环节的代码质量检查都是机器自动运行的，不会给开发者带来额外的成本。

 

阶段四：中心化

当团队规模越来越大，项目越来越多时，代码质量管控就会面临以下问题：

• 不同项目使用的代码规范不一样
• 部分项目由于放松要求，没有接入质量检查，或者存在大量未修复的缺陷
• 无法从团队整体层面上体现各个项目的质量状况对比

为了应对以上问题，需要建设中心化的代码质量管控体系，要点包括：

• 代码规范统一管理。使用Git或者NPM包管理自动化代码质量检查的规则集，自动安装，不在本地写规则。一个团队、一类项目、一套规则。
• 使用统一的持续集成服务。质量检查不通过的项目不能上线。
• 建立代码质量评分制度。让项目与项目之间能够横向对比，项目自身能够纵向对比，并且进行汇总反馈。

总结

在面临业务压力时，人们通常会倾向于通过增加人力来缓解业务压力。但从系统整体的角度来看，人力增加会造成代码质量变差，开发效率下降，从而再度增大业务压力。这种代码质量越来越差的循环，是熵增定律在软件工程领域的生动体现。

为了抑制这种循环，我们需要有意识地投入资源来建设代码质量的管控体系。这个过程分为四个阶段：规范化，自动化，流程化，中心化。每个阶段都有不同关注的要点。

目前我们团队正在建设代码质量检测中心，是中心化质量管控的一种实践，已经接入几十个项目在进行试点。关于中心化建设的细节，我会在后续的文章中继续阐述。