如何衡量前端工程质量？我们有了平台化的解决方案

如何衡量工程质量？这是每个前端团队都要面临的问题。它反映了团队的研发效能和交付水平，是前端能力与价值的体现。 但这也是一个不太容易讲清楚的问题。如何选择衡量指标？如何量化？需要结合研发体系的具体情况去深入思考。 本文介绍了我们在这方面的方法论和实战经验，并给出了一个可以落地的系统化解决方案。

背景

前端领域的语言标准、开发框架和工具链已逐渐成熟，研发提效成为了团队的重要目标之一，修炼内功的时代到来了。我们正是在这个时间节点上开始思考：一个前端工程从开发到部署，有哪些环节还存在优化空间？如何衡量这些关键环节做得好与不好？

经过分析，我们发现了一些存在的问题：

1. 技术选型碎片化：虽然我们的技术栈是统一的，但具体技术选型五花八门。当团队负责的工程数量达到一定规模时，选型的碎片化无疑会让维护成本陡增，也不利于确定统一的衡量标准。

2. 研发环节缺乏量化评估：当我们寻找可以量化的研发指标时，只有测试部门提供的 Bug 率和运维部门提供的服务稳定性，而对研发环节缺乏有效的量化评估手段。比如，当我们在团队中讲“提升代码的可维护性”时，我们到底在讲什么呢？也许每个人都有自己的理解。

基于以上问题，我们决定建立一个前端工程质量评估模型，并将其平台化，以便能够清楚地了解每一个工程哪里做得好？好到什么程度？哪里做得不够好？应该如何改进？

这个模型我们称之为“ 前端健康度 ”。

平台化思路

如何将前端健康度平台化？我们的思路大致如下：

首先，建立客观的、可量化的研发指标评估体系，这也是最重要的一步。

• “客观”是指要排除主观因素。比如，用户体验问卷这种评估方式往往带有一定的主观性，只可作为参考。

• “可量化”是指某项指标可以做定量分析，能够通过数值区分出优、良、中、差。举个例子，我们经常用各种浏览器去测试系统的兼容性，但它却是一个难以量化的指标。

• “研发”指标侧重评估从工程创建到构建发布之间的研发活动，如 Bug 率、服务稳定性等指标，已由测试和运维体系承担，因此并不纳入前端健康度的评估体系。

其次，实现数据的采集。这一步主要通过脚本和定时任务实现，由于指标的侧重点不同，所以数据源也不同，需要进一步地过滤和加工。

最后，与开发平台整合，输出评估结果，推动优化。作为团队管理者，可以全局掌握团队的研发情况，发现短板；作为开发者，可以了解哪些项目、哪些环节的评分偏低，明确优化方向。

综上，平台化思路的核心链路如下：

下面，具体阐述其中涉及的一些关键问题。

如何选择指标

在客观、可量化的基础上，我们需要尽可能地覆盖研发的关键环节，归纳总结起来可分为技术架构、开发规范、可维护性和生产环境性能四类指标。

技术架构

在工程的创建阶段，我们主要关注框架的技术选型是否先进、是否主流，以及是否收敛。基于对现有工程的了解，我们设定了如下的检测目标：

• 开发框架：React、Vue、Backbone

• 开发语言：ES、TS

• React 版本：15+、16+

• 数据管理方案：Redux、Mobx、Vuex、Not used

• UI 组件库：Ant Design、Material UI、Element UI、Other

• 异步请求方案：Thunk、Saga、Other

• CSS 预处理：Less、Sass、Other

• CSS 使用方式：CSS Module、Styled Components、Mixed、Other

掌握以上技术选型的分布情况是非常有必要的，这意味着我们对研发现状有了清晰准确的认知，推进技术升级就有了抓手。

我们不会严格地限制技术选型，但会保持一定的收敛度。比如，对于是否引入 TypeScript 我们持开放的态度，不纳入评估体系；但升级 React 版本、保持 CSS 使用方式的一致性却是强制的，不达标的工程在相关指标上将会获得较低的权值。

开发规范

技术选型完毕，工程就进入到了开发阶段。相信每个团队都有自己的开发规范，而我们想看到的是这些规范的量化执行程度，因此我们设定了如下几个指标：

• mock 接口占比：我们期望所有的前端工程都可以独立运行，所有的接口都要有 mock 数据并且遵循统一的规范，有 mock 数据的接口占比越高，健康度得分越高。

• npm 脚本规范：新人接手一个项目，通常会从了解 package.json 中的 scripts 开始，清晰统一的脚本可以规范构建工具链，降低上手成本。

• 前端监控接入：我们要求所有的工程都要纳入前端监控体系，因为生产环境的性能指标依赖于监控脚本的上报。

• ESLint 检查：设置统一的 ESLint 规则，保证团队代码风格统一。

可维护性

软件的可维护性是指工程师对软件进行理解和修改的难易程度，可以从可理解性、可测试性、可修改性、可靠性、可移植性等方面来衡量。模块是前端工程的基本组成单元，因此我们设定了两个与此相关的可维护性指标：

• 复杂模块占比：我们约定超过 500 行的模块为复杂模块（这样的模块在可理解性、可测试性、可移植性上都会打折扣），同时考察复杂模块占总模块数的比例。

• 代码重复率：设定这个指标是为了督促工程师不要在模块之间简单地复制粘贴，形成大量重复的代码模式。

为了更加直观，下面展示一个代码重复的例子：

代码路径：src/routers/…/…/Price.jsx

起止行号：306 - 310

<li> <RadioGroup onChange={this.onRadioChange} value={selectedItem}>   <Radio value={3} />   <span className={styles['front']}>Price</span> </li> 

代码路径：src/routers/…/…/GroupPrice.jsx

起止行号：198 - 203

<li> <RadioGroup onChange={this.onRadioChange} value={selectedItem}>   <Radio value={3} />   <span className={styles['front']}>Group Price</span> </RadioGroup> </li> 

通过扫描重复的代码模式，我们可以有效地评估代码复用情况，同时发现优化点。

注意：我们定义的代码重复率 = 重复的模式数 / 扫描的文件数，结果可能会大于 100%。

生产环境性能

工程进入到交付阶段，我们会设置一些生产环境的性能评估指标，其中部分数据来自于前端监控平台：

• 构建耗时

• 最大文件体积

• 首页加载时间

• 首页请求数

• 首页请求总体积

以上都是前端性能常见的优化点，在此就不多赘述了。

健康度计算

指标体系建立之后，就可以设计健康度的计算规则了，我们要达到两个目标：

1. 各项指标加权求和，可以得到一个工程的健康度总分，代表它的综合评估结果。

2. 每项指标可分为“优秀”、“及格”和“待优化”三个等级。

首先，我们根据研发现状设置了各项指标的权重，如下表所示：

接下来，需要计算每项指标的具体得分。我们设置了 5 分制，以“mock 接口占比”这个指标为例，计算方法为：

f(x) = x / 5 - 15 (75 <= x <= 100) f(x) = 0          (0 <= x < 75) 

1. 当占比为 95%~100% 时，得分为 4~5，等级为“优秀”。

2. 当占比为 90%~95% 时，得分为 3~4，等级为“及格”。

3. 当占比低于 90% 时，得分低于 3，等级为“待优化”。

最终，经过加权求和，我们得到了一个工程的健康度雷达， 同时标记出了需要优化的指标项。

健康度巡检

在整个健康度模型中，巡检任务是很关键的一环，大部分指标的获取和计算都在这里完成。一般情况下，我们会每周巡检一次，从 Git 仓库中拉取代码后，做文本扫描和分析。主要流程如下：

为了提升可复用性，巡检脚本被封装成了 npm 包，即可在服务端运行，也可在本地运行，便于工程师在优化代码后可以马上检验优化效果。

如何设计增强回路

一个完整的质量评估系统，不仅需要给出评估结论，还需要形成优化闭环。因此，我们设计了一些增强回路。

健康度周报

每周由巡检任务发送各系统的健康度排名和异常波动，让工程师及时发现技术升级带来的影响。

健康度看板

在开发平台首页，让工程师关注所负责项目的健康度情况，促进主动优化：

趋势回顾

让每次优化记录有迹可循，提升工程师的成就感：

结语

工程质量的提升，衡量标准的制定，是一个不断追求卓越的过程。我们的模型也在不断地迭代，精减已经达成的目标，同时补充新的挑战。我们相信，这套方法论不仅适用于前端，同样也可以拓展到其他研发、测试或运维领域。希望我们的经验对你有所启发，欢迎留言、转发，表达你的观点。

作者介绍：

梁宵，搜狗营销事业部高级架构师，前端开发负责人。