Skip to content

立完flag,你可能需要对flag进行量化

image

引言

当你的能力足够,并且获得领导的信任之后,很自然地就会去承担更大、更重要的责任,比如成为大中型业务的Owner。

大中型业务指的是该业务足够大,足够复杂,仅凭一己之力无法按要求交付版本,需要团队协作。

我们假设该业务一共12个人,其中角色分布如下(按产品研发流程排序):

角色职责成员数
产品经理对接用户,是需求的来源1
项目经理管理项目进度,有节奏地进行版本交付1
设计负责UI交互和视觉,是用户体验的设计者1
前端前端用户界面和交互效果开发3
后台后台数据存储和接口开发4
测试负责版本质量1
运维负责现网部署1

如果你被分到该业务,成为前端Owner,你可能需要做些什么,以高效率、高质量地实现版本交付呢?

1 明确目标和职责

首先要了解组织和领导对你的期望,假设组织希望你能够改善该业务的交付质量,赢得用户口碑。

目标非常明确,就是提升交付质量,这个目标将牵引你未来一年的方向和行为,也是你超预期完成目标的前提。

有了目标之后,我们还需要去衡量它,这样才知道有没有提升,尽量寻找可以量化的指标。

这一块可以参考我们以前的文章:《如何度量前端项目研发效率与质量》

2 交付质量的组成

质量代表的是好不好,问题越少就越好。

从产品侧来看,缺陷率JS错误率都是非常不错的衡量指标。

从开发侧来看也有很多很好的衡量指标,比如:

  • 重复率
  • 圈复杂度
  • ESLint问题数
  • 巨石文件/方法数

3 计算缺陷率

缺陷率=缺陷数/代码规模

缺陷也就是BUG,当我们开发完产品特性后,需要部署到测试环境,并提测,测试人员测试完,会提一堆BUG单,这些BUG的数量就是缺陷数。

代码规模可以用代码行数来表示,一般源码都放在工程根目录下的src目录中,可以使用cloc工具统计代码行数:

cloc src

如果要排除里面的某些目录,比如__tests__,可以加上--exclude-dir参数

cloc src --exclude-dir=__tests__

比如html2canvas库的代码行数:

有了缺陷数和代码规模,就可以计算缺陷率啦。

可以先统计下历史迭代的缺陷率,缺陷数可以通过查看测试报告获得,该版本增加的代码行数可以通过Git提交记录获得。

比如上一个迭代1.2.6,从2020.12.14-2020.12.25

我们可以使用以下命令统计到新增的代码行数:


git log --after="2020-12-14 00:00:00" --before="2020-12-25 23:59:59" --pretty=tformat: --numstat | grep -v 'static' | awk '{ add += $1 ; subs += $2 ; loc += $1 - $2 } END { printf "增加行数:%s 删除行数:%s 变化总行数:%s\n",add,subs,loc }'

还是以html2canvas举栗子🌰

假设通过查看测试报告,这段时间一共出了3个BUG,那么缺陷率就是:

缺陷率=缺陷数/代码规模=3/130=2.3%

也就是上个迭代的缺陷率为2.3%,我们可以多计算几个迭代,然后算个平均数,这样我们就知道以前这个业务的缺陷率水平大致如何。

这样你作为业务Owner,后续通过一系列举措,最后降低了这个指标,假设降低到1.8%,那么可以认为质量提升了:

(2.3-1.8)/2.3=21.7%

4 监控JS错误率

第二个是JS错误率,就是监控现网用户访问页面时,是否有JS报错,如果有JS报错,很可能某些功能就可用。

我们没法在用户的现场,我们不知道用户使用我们产品的体验如何,他是否在使用过程中遇到了困难,这些我们没法直接知道。

但是JS报错给我们提供了一些了解这些信息的线索,假设某个时刻,现网出现了JS报错,我们或许就能复现这个报错,找到报错的原因,并在用户投诉之前及时修复这个缺陷。

可以说:

降低现网JS错误率就是在排除地雷,地雷越少,炸到的用户就越少,这对产品的用户口碑意义重大

这个指标需要通过前端监控平台采集,比如我们DevUI内部的Furion平台,它的计算公式如下:

JS错误率=JS错误数/PV

也是先看下以往的现网JS错误率水平,假设是6.2%,你通过努力将这个指标降到0.1%,那么质量提升就是98%

5 统计重复率

除了产品层面的质量衡量指标,我们还可以设定一些开发侧的质量指标。

重复率就是一个很不错的指标,如果项目里面重复的代码太多

  • 一来我们的维护成本提高,一处变更,要改很多地方;
  • 二来容易漏该某些地方,从来导致BUG。

重复代码是万恶之源

我们可以用jscpd工具来统计前端代码的重复率:

jscpd src

以html2canvas为🌰

它一共有14处重复代码,重复率为1.71%(算比较低的),jscpd命令还会列出每一处重复所在的文件以及所在的行/列。

我们要做的就是照着重复率报告,一处一处改掉即可,当然修改重复代码也要考虑可读性,不能为了消除重复,降低了代码的可读性。

假设改完之后,重复率降到1.16%,那么质量提升了32%

6 计算圈复杂度

圈复杂度可以参考下我们之前的文章:浅谈前端中的圈复杂度 ,这里就不赘述。

7 ESLint问题数清零

ESLint通过一些最佳实践的规范,来约束我们的代码,从而保障代码质量。

下图清晰地展示了ESLint的价值:

  • 如果你不使用ESLint,你的代码只能靠人工来检查,格式乱七八糟,运行起来bug丛生,你的合作者或用户会怒气冲冲;
  • 如果你使用了ESLint,你的代码有可靠的机器进行检查,格式规则,运行起来问题会少很多,大家都会很满意。

如果项目中的代码没有遵循ESLint规则,那么就会产生一条ESLint错误或者提示,将这些ESLint问题修复,在一定程度上是可以提升代码质量的。

假设ESLint问题清零了,那么质量提升就是100%

8 统计巨石文件/方法数

大而复杂的事物,我们理解起来一般更费劲,简洁的事物往往易于理解。

代码也是一样,简单的代码,我们一眼就知道它是做什么的,这样修改它就不容易出错。

如果一个文件包含几千行代码,或者一个方法包含几百行代码,里面分支众多,嵌套又深,那么我们就很难读懂它,修改它的时候总不免战战兢兢、如履薄冰,还容易出bug。

统计所有文件的代码行数,并按代码行数从大到小排序,可以使用之前提到的cloc工具:

cloc src --by-file

还是以html2canvas为🌰(只截取了代码行数大于100行的文件)

一般一个文件的代码行数不要超过300行,超过300可能就需要进行适当的模块拆分,以增强代码的可读性和可维护性。

另外也要权衡下文件的嵌套深度,从根路径开始往下,一般不超过7层

我目前没想到比较好的统计巨石方法的办法,只能去巨石文件里面找,找到超过50行的方法,我就会考虑重构。

大家有更好的办法欢迎推荐。

小结

我们做一个简单的小结,从产品侧来看,可以通过

  • 缺陷率
  • JS错误率 来衡量质量。

从开发侧来看,可以通过

  • 重复率
  • 圈复杂度
  • ESLint问题数
  • 巨石文件/方法 来衡量质量。

这些质量指标可以根据自己团队的特点和偏好,设定相应的权重,并最终计算出一个总的质量提升比率。

对目标进行量化之后,我们就可以撸起袖子开干了。

经过一段时间的努力,我们超预期完成了组织的目标,就可以拿着这些质量提升的量化指标去跟组织要年终奖和加薪啦!

发布时间:

Made with ❤ by