Linux 之父出席、干货分享、圆桌讨论,精彩尽在 OpenCloudOS 社区开放日,报名戳 了解详情
写点什么

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

  • 2020 年 8 月 11 日
  • 本文字数:3290 字

    阅读完需:约 11 分钟

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

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


背景

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


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


  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. 每项指标可分为“优秀”、“及格”和“待优化”三个等级。


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


指标分类指标权重
技术架构
(15%)
React 版本5%
CSS 使用方式10%
开发规范
(30%)
mock 接口占比10%
npm 脚本规范3%
前端监控接入2%
ESLint 检查15%
可维护性
(30%)
复杂模块占比15%
代码重复率15%
生产环境性能
(25%)
构建耗时5%
最大文件体积3%
首页加载时间6%
首页请求数6%
首页请求总体积5%


接下来,需要计算每项指标的具体得分。我们设置了 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 包,即可在服务端运行,也可在本地运行,便于工程师在优化代码后可以马上检验优化效果。


如何设计增强回路

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


健康度周报

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


健康度看板

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



趋势回顾

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



结语

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


作者介绍


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


2020 年 8 月 11 日 08:004195
用户头像

发布了 385 篇内容, 共 113.3 次阅读, 收获喜欢 523 次。

关注

评论 2 条评论

发布
用户头像
非常棒 👍
2020 年 08 月 27 日 16:36
回复
用户头像
赞一个,工程质量指标化,是持续提升的基础
2020 年 08 月 18 日 11:09
回复
没有更多了
发现更多内容

产品经理岗位调研

发条檀木

产品经理训练营

有关单例模式的总结

跳蚤

第八周 学习总结

简简单单

产品训练营第一周作业

懒杨杨

产品经理-新手

产品新手

中台 | 中台到底是什么?

xcbeyond

中台 中台架构 中台的由来 28天写作

第11周-作业1

Mr_No爱学习

《认识产品经理》中的小金句与小尝试

学习高手song轻松

产品

产品训练营-第一章作业

Arnold

产品经理训练营

今天听课想到的小事

Nydia

架构师训练营第三周作业

跳蚤

第八周 课后作业

简简单单

第一周

汪龙龙

作业 - 第一章 认识产品经理

hao hao

产品经理训练营

第3周总结-代码重构-使用UML类图表达程序逻辑

潘涛

架构师训练营 4 期

道德困境 - 电车难题

石云升

28天写作 道德困境 电车难题

架构师训练营第二期 Week 13 总结

bigxiang

架构师训练营第2期

重学JS | Proxy与Object.defineProperty的用法与区别

梁龙先森

大前端 编程语言 28天写作

第一周作业-产品经理岗位能力要求

林亚超

第11周-学习总结

Mr_No爱学习

十三周-作业

水浴清风

产品经理训练营笔记-认识产品经理(下)

.nil?

产品经理训练营

第 13 周作业

Steven

CentOS安装和使用FFmpeg

王坤祥

ffmpeg 视频处理

第一章作业

🌴stolmpj

第一章 认识产品经理(上)

郭栋

产品经理训练营

第八周学习心得

cc

产品经理JD调研备忘录

学习高手song轻松

产品

面试官问我:什么是静态代理?什么是动态代理?注解、反射你会吗?

Java鱼仔

Java 反射 动态代理 java反射

第3周课后练习-代码重构

潘涛

架构师训练营 4 期

第八周命题作业

cc

GPU容器虚拟化:用户态和内核态的技术和实践详解

GPU容器虚拟化:用户态和内核态的技术和实践详解

如何衡量前端工程质量?我们有了平台化的解决方案_技术管理_梁宵_InfoQ精选文章