你工作很高效，如何证明？你做了很多优化，是否有效？
为了回答这些问题，最有力的就是用数据来支持，所以需要将自己的工作量化。
量化的工作总共分为两层：业务需求和代码质量。
一、需求统计
需求统计包括完成率和用户满意度评分。
1）完成率
公司每双月会开一次需求讨论会，罗列本双月的需求。
我会以这份列表为基础，自己再开一份在线列表，记录所有需求的状态，并且会将不在此列表中的零碎需求也记录。
这份列表有 5 列，包括需求名称、线上BUG数、功能点数量、状态和备注。
其中状态又包括设计、提测、上线、延期等，可以一眼就能反映出需求所处的阶段。
线上BUG数就是字面意思，而功能点数量是 QA 提供的，他们在写测试用例时就会有这个数据。
我的需求完成率是按提测状态来统计，而不是上线状态。
因为有时候是需要多端联调的，经常会碰到协作方因为种种原因无法配合联调或延期。
提测是指 QA 可以验收需求，所以要说明此处的联调问题并不是指我们写好界面，然后等服务端给接口。
而是比如我们完成管理后台的前后端功能，提供数据源，服务端没有时间处理这批数据，类似于这种场景。
2）用户满意度评分
这是一张问卷调查，收集大家对我们组工作的反馈，对当前存在的问题可以做出针对性的优化。
需要填写所处部门，需求类型（后台或活动），是否达到预期，维度包括成果、沟通、响应等。
最后还有两个可选项，就是填写意见或建议，以及最想表扬的同学及其理由。
若是正面反馈，那自然很好；若是负面反馈，那就要总结.
二、核心指标看板
核心指标主要与代码质量有关，包括异常状态码接口、慢响应、前端错误、白屏和首屏时间等，以折线图的形式描述趋势变化。
因为我们组维护着大量的 Node 服务，所以指标中就会包含多个服务端数据。其中慢响应作为我们组的北极星指标。
所谓北极星指标，也叫第一关键指标，是指在产品的当前阶段与业务/战略相关的核心指标，一旦确立就像北极星一样指引团队向同一个方向前进。
1）状态码接口
状态码是指报 500、502、503 和 504 的接口，其中 500 是代码错误，我们可以通过日志做排查。
在 500 的错误码中，监控接口占据了 94% 左右，主要是因为上传的数据量太大导致报错，服务端限制 1M，最终在上传时就做大小限制。
还有一个占据了 6.2% 的错误接口主要是逻辑不够严密，边界条件没有处理好，修复后就降到了 0。
502 是转发到错误的后端服务，503 是没有转发，都是 Nginx 的问题，如果大量报，那就要找运维了。
504 是由后端服务出问题导致的超时引起的，例如数据库因为一条耗时的查询语句而被挂起。
2）慢响应
慢响应是那些响应时间超过 2 秒的接口，一种是内部逻辑慢，另一种是受调用的接口影响而变慢。
第一种就可以我们自己解决，第二种就需要找协作组配合解决了。
有一个占了慢响应 67.4% 的监控列表接口，属于前者，在内部会查询一张 430W 的大表 6 次。
优化手段也很直接，就是减少查询次数，降到 1 次，慢响应次数一下子减少了 95%。
还有个举报接口，也属于前者，这张表也比较大，增加查询条件，触发索引，就立竿见影的把速度提上来了。
该慢响应次数一下子减少了 90%。这两个接口优化后，慢响应总占比从 0.23% 降低到 0.1%。
3）前端错误
前端错误就是通过监控系统搜集到的错误日志，分为脚本错误和通信异常。
脚本错误就是 JavaScript 的异常，例如用 undefined 当对象读取属性。
一个项目中的脚本错误在修复后，从高峰的4073降低至246，减少了93.96%，进一步的保障项目质量。
通信异常其实也是 500、502 和 504 接口，之前的接口异常数量会包括静态资源以及内部的服务调用。
而此处的通信异常只包含从客户端发起的那部分接口，可以简单理解为其子集，不过有时候发现 502 和 504 的统计两边会有略微差异。
4）白屏和首屏时间
白屏就是等待白屏的时间（FP），首屏更确切的说是首次有意义的内容加载时间（FMP）。
之前做过一套性能监控系统，白屏比较好计算，而首屏比较复杂，我们这边采用最简单的埋点的方式。
也就是手动的在某个阶段记录首屏时间，比较麻烦的是需要将线上页面逐个添加，不过也没多少个，所以还能接受这个笨办法。
以首屏为例，1 秒内占 72%左右，2 秒内占 19% 左右，若以 1.2 秒为边界的话，那优化的空间还是蛮大的。
初步排查后，发现主要慢在 DOM 解析，这让我蛮诧异的，经过 Chrome DevTools 的性能分析后，定位到了脚本尺寸上。
加载的脚本有点多，并且有一个 chunk-vendors.js 脚本还比较大，下载时间有点长。
因此在加载和运行时就会延长 DOM 的解析，影响白屏时间。
posted on
