首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

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

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

背景

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

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

  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

复制代码

代码语言:javascript
复制
<li> 
<RadioGroup onChange={this.onRadioChange} value={selectedItem}> 
  <Radio value={3} /> 
  <span className={styles['front']}>Price</span> 
</li> 

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

起止行号:198 - 203

代码语言:javascript
复制
<li> 
<RadioGroup onChange={this.onRadioChange} value={selectedItem}> 
  <Radio value={3} /> 
  <span className={styles['front']}>Group Price</span> 
</RadioGroup> 
</li> 

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

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

生产环境性能

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

  • 构建耗时
  • 最大文件体积
  • 首页加载时间
  • 首页请求数
  • 首页请求总体积

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

健康度计算

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

  1. 各项指标加权求和,可以得到一个工程的健康度总分,代表它的综合评估结果。
  2. 每项指标可分为“优秀”、“及格”和“待优化”三个等级。

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

指标分类

指标

权重

技术架构 (15%)

React 版本

5%

CSS 使用方式

10%

开发规范 (30%)

mock 接口占比

10%

npm 脚本规范

3%

前端监控接入

2%

ESLint 检查

15%

可维护性 (30%)

复杂模块占比

15%

代码重复率

15%

生产环境性能 (25%)

构建耗时

5%

最大文件体积

3%

首页加载时间

6%

首页请求数

6%

首页请求总体积

5%

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

代码语言:javascript
复制
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 包,即可在服务端运行,也可在本地运行,便于工程师在优化代码后可以马上检验优化效果。

如何设计增强回路

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

健康度周报

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

健康度看板

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

趋势回顾

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

结语

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

作者介绍

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

  • 发表于:
  • 本文为 InfoQ 中文站特供稿件
  • 首发地址https://www.infoq.cn/article/FGrQeAw5mNKjWkxGV12U
  • 如有侵权,请联系 cloudcommunity@tencent.com 删除。

扫码

添加站长 进交流群

领取专属 10元无门槛券

私享最新 技术干货

扫码加入开发者社群
领券