深入前端研发效能治理：数据化运营思路及其实践

Posted 2021-10-26 阿里云云栖号

简介： 数据中台前端研发无不让人厚重真实地感受到“唯一不变的是变化”。拿集团的数据资产服务平台来说，业务上经过两年的发展，已由单一的数据管理和使用平台发展成了集团具有一定规模和影响力的全域数据要素交易所，而从前端技术侧，仅从代码提交报表就能明显看到，今年的代码提交量平均是去年的 2-3 倍，可见其业务扩张速度之快。

作者 | 杭歌
来源 | 阿里技术公众号

一 背景

数据中台前端研发无不让人厚重真实地感受到“唯一不变的是变化”。拿集团的数据资产服务平台来说，业务上经过两年的发展，已由单一的数据管理和使用平台发展成了集团具有一定规模和影响力的全域数据要素交易所，而从前端技术侧，仅从代码提交报表就能明显看到，今年的代码提交量平均是去年的 2-3 倍，可见其业务扩张速度之快。

代码提交量暴涨的背后，是团队、技术和研发过程的发展。研发团队从最初的 2-3 人，发展到了如今约 10 人规模；项目的前端工程也经历了从常规的 React+TypeScript+数据流架构，到支持多独立业务模块的 Monorepo 微前端形式，再到 Pro-Code 与搭建结合的开发模式；流程上也经历过月级别的大迭代与周级别的敏捷开发，有过单人负责与多人协作开发，甚至与外包同学远程跨业务领域广泛协作，经历了不少难题。

1 为什么要数据化运营？

遇到的困难中，今日且不谈这些具体的难题，业务的增长带来技术和团队的种种变化，再平常不过了。不妨换个思路，跳出研究问题本身，先找一找问题产生的根本性原因：

• 觉得一天到晚都在处理代码评审，为什么？是业务需求多，节奏快，还是开发者的习惯或研发流程节奏出现了问题？
• 代码评审问题那么多，处理了两三天还不断有新的问题，为什么？是开发者代码水平问题还是自己评审的方式存在不妥的地方？
• 一个开发同学同样的问题每次总是出现，为什么？是业务逻辑本身限制还是编码流程和规范培训得不到位？

我们当然希望每个问题都能准确找到它们的根本原因，因此我们经常找开发同学寻求反馈，但反馈效果往往比较局限。例如，我不去问，对方不会反馈问题；我觉得不需要优化的点，对方觉得需要；我打算以某种方式解决某效率问题，但常常是解决得不彻底或者根本没有解决。

这个问题的根本原因在于，我们都是站在自己的视角来审视问题，而没有一个更高的俯视视角来帮助我们看清全局，甚至是洞察一些规律性、预测性的变化。越来越多的诉求指向了“数据化运营”这个概念。

2 明确目标

上面我们提到，希望通过研发效能的数据化运营思路，通过真实的研发效能数据来看清团队的整体大盘和明细指标，就能从更高的位置审视团队的业务研发，隐藏的问题就能够在数据中暴露，问题的原因就能够在数据中自现，从而使人更好地思考如何解决，更加准确定位到根本，最终使研发效能得到提升。

作为数据中台前端团队业务开发者与研发流程管控者中的一员，本次和大家分享在团队中我们如何运用数据化运营的思路来管理研发流程与研发质量，达到提升研发效能的目标。

二 研发效能数据化运营全链路

1 设计指标

要提升研发效能，我们需要定义出关键的数据指标。通常的研发效能指标涵盖了整个研发流程中的不同环节，相辅相成。如“代码质量分（代码 Lint 问题数）”“需求研发周期”“敏捷迭代交付周期”“研发活动效率”“发布耗时”等。

限于篇幅，本文以“研发活动效率”这一指标为研究对象，探讨结合团队实际情况，我们能做什么。

研发活动是团队平常进行最多的事，映射到具体的研发流程，则是代码 Commit 和提交代码评审。评审人负责代码评审的质量把控，并最终通过评审并合并代码到主分支，一次“研发活动”即告捷。经过团队大量实践表明，最能影响研发活动效率的是代码评审的提交频率和处理时间。

首先，对开发者，代码评审需要规约。我们规定以 1 天或 2 天为代码评审提交周期，以每个 Aone 缺陷或需求为最小粒度，隔一段时间就提一个，否则会造成新开发代码量的积压，造成评审人压力过大，若是问题较多，或是逻辑出现方向性问题，更难以控制项目进度和风险；相反，如果频率过高，中途不断打断评审人正常的工作，也会对其造成困扰。

其次，对代码评审人，也需要一定的约定。例如代码评审提交过来，可能有些评审同学会忘记或暂时搁置，造成提交的代码久久无人处理，与此同时开发同学又提交了新的业务代码，就回到了上面提到的代码积压问题，造成评审阻塞的恶性循环。

聊到这儿，相信大家已经知道了团队的痛点：在 5+ 业务领域，8+ 需求并行，加以外包协作的 10 人（正式同学）前端研发团队中，我们明确代码评审暴露的问题，但我们不知道量化出来具体是怎么样的情况，到底耗时多久，也不知道是哪些开发同学或评审同学的节奏出现了异常，问题只有现象没有切入点。因此我们走一个数据化运营的完整流程，来尝试解决上述问题。

2 埋点上报

明确了要观察的指标，下一步是对整个指标进行拆解，确定在研发流程中需要上报哪些数据。对“代码评审处理时长和频率”，我们可以分解出如下信息：

• 代码评审提交时间
• 代码评审通过时间
• 代码提交人
• 代码评审人
• 该轮代码评审是否被合并
• 该轮代码评审的轮次
• 其他必要的信息，如提交的评审属于哪个分支，哪个需求，哪个项目等。

如何收集这些数据呢？

团队研发效能工具简介

得益于团队的研发效能基建（见上图），我们通过研发效能工具 DT-Hornet，实现了团队研发流程管控的“大一统”。

• 在调用自定义 NPM Script 的“req”（需求管理，requirements manage）命令进行分支创建和维护时，能够收集到分支和对应的需求相关信息，甚至让开发者预先填好需求的联调、提测、发布等时间节奏；

• 在调用“cr”（提交代码评审，code review）命令提交代码评审时，工具能够通过开发者所在的分支自动识别到其对应需求并自动确认目标分支，自动收集 Commit 信息，触发 Aone 相关提交逻辑，方便地创建代码评审并发送钉钉通知到群；
• 在调用“pub”（发布，publish）命令时通过自动识别到的开发者和需求信息，自动发布准确的预发环境（团队内是多套前端环境并存，互不干扰）。

CR命令层埋点逻辑

下面聊一些技术细节。当开发者提交 CR 时，经过如下步骤的自动化处理：

• 校验工作区是否干净，判断当前分支有效性；
• 找到对应需求，确认目标分支；
• 访问持久化数据，检查是否有前置 CR（即，前一次 CR 未合并，本次有新的 Commit，提交后仍然是同一个CR）；

• 查找是否有未上报的已完成 CR 信息，并收集其中有用的信息并上报：

  • 在此过程中，会计算前一次 CR 的最新 Commit ID 是否已经包含在目标远程分支的 Commit Log 集合中，若包含则表示代码已合并，即 CR 已完成；
  • 若有已完成的 CR 信息，则从持久化 CR 信息中取得 CR 提交时间，从目标分支的 Commit Log 中取得代码合并结点的提交时间作为代码合并时间，即可作为准确的 CR 通过时间；

• 代码检查，自动合并目标分支代码，若产生代码冲突则报错返回；
• 执行真正的提交 CR 逻辑，并将 CR 所有信息合在一起做数据上报和持久化存储，后续钉钉通知到群；
• 最后对 CR Commit 进行打标，方便后续通过 Tag 找到 Commit ID。

监控平台使用及技术层逻辑简介

在上述 CR 提交与埋点逻辑的基础上，借助集团监控平台ARMS的能力（封装了通用能力 Trace-SDK），我们能够轻易地上报数据。

要使用监控平台，需要在其中注册一个应用，获得一个 PID 唯一标识。在埋点上报逻辑中，在 Trace-SDK 实例化时传入该 PID，埋点处调用其 log API 即可完成上报。如下代码展示了效能工具内核如何调用 Trace-SDK 来声明其通用埋点上报逻辑。

/** 效能工具内核类声明（与埋点上报监控平台相关的部分） */
class HornetCore {
  /** 监控单实例声明 */
  private static traceInstance: TraceSdkType = null;

  /** HornetCore 监控初始化 */
  public static initTrace = (): void => {
    HornetCore.traceInstance = new TraceLiteSdk({ pid: '<研发效能工具PID>' });
  };

  /** 上报参数给监控平台 */
  public static sendTraceLog = async (
    /**
     * 上报类型
     */
    type: string,
    /**
     * 上报的参数
     */
    params?: TraceLogParamType,
  ): Promise<void> => {
    try {
      // 操作人工号
      const uid = DYNAMIC_NAMES.ADMIN_WORK_ID;

      // 操作人
      const c1 = DYNAMIC_NAMES.ADMIN_NAME;

      // 应用名
      const c2 = DYNAMIC_NAMES.PROJECT_NAME;

      // 分支名
      const c3 = DYNAMIC_NAMES.BRANCH_NAME;

      let c4: any;
      let c5: any;
      let c6: any;
      let c7: any;
      let c8: any;

      // 工具是否最新版
      const c9 = HornetCore.isLatestVersion.toString();

      // 工具内核版本号
      const c10 = HornetCore.version;

      switch (type) {
        case TRACE_LOG_TYPE.CR: {
          const { targetBranch, crAdmins, crAdminCnt, currentReqName, crSequence } = params || {};
          [c4, c5, c6, c7, c8] = [targetBranch, crAdmins, crAdminCnt, currentReqName, crSequence];
          break;
        }
        case TRACE_LOG_TYPE.CR_HANDLING: {
          const { targetBranch, currentReqName, crCount, crStartTime, crEndTime } = params || {};
          [c4, c5, c6, c7, c8] = [targetBranch, currentReqName, crCount, crStartTime, crEndTime];
          break;
        }
        default:
          [c4, c5, c6, c7, c8] = [null, null, null, null, null];
      }

      const logParams = { type, uid, c1, c2, c3, c4, c5, c6, c7, c8, c9, c10 };

      return HornetCore.traceInstance.log(logParams);
    } catch (e) {
      BasicMessage.error(`上报数据错误: ${SPLIT_VALUE.BREAK}${e}`);
      return Promise.reject();
    }
  };
}

如代码所示，工具组织各个不同的 C 字段（自定义上报字段）来搭配不同的上报类型进行上报，在 CR 上报的场景中，需要两种类型，CR 用来上报按“次”来计算的 CR 的详细信息，而 CR_HANDLING 用来上报计算后的按“轮”来计算的 CR 信息，一“轮” CR 中可能包含多“次” CR。

在监控平台侧，对应地配置了上报类型和 C 字段的别名，方便后续的数据拉取和处理。如下图所示。

埋点上报数据即发送请求。一般是请求服务端某个 1*1 像素的图片，并在请求发送时带上所有需要上报的信息。这里除了 CR 信息，还包括一些通用的系统层面的信息。

监控平台接收到数据，将数据通过日志服务存储到 HBase 集群，数据在 ARMS 平台即可通过即席查询获取到。

3 数据处理

归功于 ARMS 监控平台，上述步骤已完成了数据的采集和存储，接下来要进行数据的同步回流和初步处理等操作。每天上报到监控平台的实时数据将存储到相应的离线小时表中，我们申请对应表的权限，通过查询表的视图，能够获取到效能工具 PID 下采集的所有明细数据。

离线数据同步

由于监控平台存储成本有限，只能保留近 30 天的数据，且原表包括了监控平台中所有 PID 上报的数据，数据量非常大，造成视图查询较慢，且查询时若条件不严格，很容易因资源不足而发生查询错误。因此我们考虑在 Dataworks 上建立一个周期任务，将我们需要的数据定期同步到自己创建的表中，即可解决问题。

在周期任务中，我们通过 INSERT OVERWRITE 语句，按照 ds 字段规定的分区范围，每天向表 source_table 中写入数据，且不会产生重复数据。将该任务发布后，它每天就会生成一个周期实例，稳定地为我们提供所需的监控数据。

数据分析 SQL 设计

我们利用 FBI 平台来做数据分析。在 FBI 数据集编辑中，我们可以方便地基于刚才创建的 ODPS 表声明 SQL，进一步解析自己想要的字段。

我们将 C 字段全部语义化，并运用简单的内置函数，对数据进行空值处理或格式化处理，以备进一步利用。代码评审数据明细分析表、代码评审处理数据明细分析表和代码评审汇总分析表分别声明如下：

/*
  代码评审数据明细分析表
*/
SELECT
  a.stat_date,
  a.ds,
  a.log_day,
  substr(a.log_hour, 9) as log_hour,
  substr(a.log_time, 9) as log_time,
  substr(a.log_second, 9) as log_second,
  a.c1 as admin_name,
  b.c2 as project_name, -- 项目中文名信息由维表提供
  a.c2 as project_en_name,
  a.c3 as branch_name,
  a.c4 as target_branch,
  a.c5 as cr_admins,
  substring_index(c5, ',', 1) as cr_first_admin, -- 取得第一个评审人为主要评审人信息
  a.c6 as cr_admin_cnt,
  a.c7 as cur_req_name,
  concat(c4, ' ', c7) as cur_branch_and_req_name,
  a.c8 as cr_sequence,
  a.c9 as latest_version_flag,
  a.c10 as cur_version
FROM
  source_table a
  LEFT OUTER JOIN (
    SELECT
      code,
      c1,
      c2
    FROM
      source_table_dim -- 维表存储不经常更改的维度信息
  ) b ON a.c2 = b.c1
WHERE
  a.code = 'code_review'
  AND b.code = 'project_name'
  AND a.c4 != 'develop' -- 过滤掉提交到主发布分支的 CR，因为其不是关键信息
  AND a.ds > 20210630; -- 限定有数据的 ds 范围，增加查询性能

/*
  代码评审处理数据明细分析表
*/
SELECT
  a.stat_date,
  a.ds,
  a.log_day,
  substr(a.log_hour, 9) as log_hour,
  substr(a.log_time, 9) as log_time,
  substr(a.log_second, 9) as log_second,
  a.c1 as admin_name,
  b.c2 as project_name,
  a.c2 as project_en_name,
  a.c3 as branch_name,
  a.c4 as target_branch,
  a.c5 as cur_req_name,
  concat(a.c4, ' ', a.c5) as cur_branch_and_req_name,
  concat(b.c2, ' ', a.c5) as cur_project_and_req_name,
  c.c1 as cur_req_admin_name,
  a.c6 as cr_count,
  a.c7 as cr_start_time,
  a.c8 as cr_end_time,
  datediff(
    to_date(a.c8, 'yyyy-mm-dd hh:mi:ss'),
    to_date(a.c7, 'yyyy-mm-dd hh:mi:ss'),
    'mi'
  ) as cr_duration, -- 使用 datediff 函数来计算CR处理时长
  a.c9 as latest_version_flag,
  a.c10 as cur_version
from
  source_table a
  LEFT OUTER JOIN (
    SELECT
      code,
      c1,
      c2
    FROM
      source_table_dim
    WHERE
      code = 'project_name' -- 关联项目名称信息
  ) b ON a.c2 = b.c1
  LEFT OUTER JOIN (
    SELECT
      distinct code,
      c1,
      c2,
      c3,
      c4
    FROM
      source_table
    WHERE
      code = 'requirements' -- 关联需求信息
  ) c ON a.c5 = c.c4
WHERE
  a.code = 'code_review_handling'
  AND a.c4 != 'develop'
  AND a.c8 IS NOT NULL -- 没有CR结束时间的定义为废弃CR，此处过滤掉
  AND a.c8 != 'null'
  AND a.ds > 20210720;

/*
  代码评审汇总分析表
*/
SELECT
  stat_date,
  project_name,
  project_name_and_req_name,
  cur_req_name,
  admin_name,
  COUNT(admin_name) as cr_cnt -- 统计CR提交次数
FROM
  (
    SELECT
      a.stat_date,
      a.ds,
      a.log_day,
      substr(a.log_hour, 9) as log_hour,
      substr(a.log_time, 9) as log_time,
      substr(a.log_second, 9) as log_second,
      a.c1 as admin_name,
      b.c2 as project_name,
      a.c2 as project_en_name,
      a.c3 as branch_name,
      a.c4 as target_branch,
      a.c5 as cr_admins,
      substring_index(a.c5, ',', 1) as cr_first_admin,
      a.c6 as cr_admin_cnt,
      a.c7 as cur_req_name,
      concat(b.c2, ' ', a.c7) as project_name_and_req_name,
      a.c8 as cr_sequence,
      a.c9 as latest_version_flag,
      a.c10 as cur_version
    FROM
      source_table a
      LEFT OUTER JOIN (
        SELECT
          code,
          c1,
          c2
        FROM
          source_table_dim
      ) b ON a.c2 = b.c1
    WHERE
      a.code = 'code_review'
      AND a.c4 != 'develop'
      AND a.ds > 20210715
      AND b.code = 'project_name'
  )
GROUP BY -- 选择日期、项目名称、需求名称、开发者等维度
  stat_date,
  project_name,
  cur_req_name,
  admin_name,
  project_name_and_req_name;

4 设计报表

产出了分析数据，接下来就可以进行报表设计与搭建了。FBI 平台提供了丰富的图表可供选择，在使用时需要明确它们的含义。

围绕着代码评审，我们设计了以下总体和细分指标的报表。

代码活动总览报表

• CR 平均处理时长及健康状况，认为 24 小时以下为健康；

• CR 平均频次及健康状况，认为每人每天 1-3 次为健康；

• CR 平均处理时长按开发者、需求的排行榜；

• CR 平均频次按开发者的排行榜（为避免内卷，当频次由高到低排列时，只展示超出健康度范围外的数据）。

代码活动明细报表

• 项目粒度的代码活动健康度（CR 平均处理时长、CR 平均频次）；

• 项目下各需求 CR 占比；

• 项目 CR 提交时间分布；

• 项目粒度的需求 CR 流转情况（需求-开发者-主要评审人）；

• 项目下各开发者的 CR 提交频数与负责需求数对比等。

除此之外，报表页面还搭建了查询详细数据的明细列表，支持搜索各项维度数据，如项目名称、开发者等。

5 问题洞察与解决

经过以上的报表搭建和优化，我们能初步解决首要的“看数”问题——不再担心代码评审产生的成本无法量化，能够明确代码评审具体耗时多久，也能从报表中发现和洞察潜在的问题。

案例一：总览分析

从有数据记录以来，发现从 7 月初到 9 月初，团队的代码活动明显提升，若项目是固定的，CR 频数却上升了，则说明需求量可能有上升趋势，再对比 CR 涉及的项目数趋势，跟 CR 提交趋势线基本吻合，说明有更多的项目利用效能工具的能力，而需求研发可以认为对于项目粒度的研发是表现正常的，但整体趋势是项目增多，也要关注团队同学们的业务压力。

获得了上述信息后，结合团队中实际研发的项目，可逐一观察项目粒度的明细报表数据，进一步了解业务研发情况。

案例二：异常洞察

研发效能管理者和项目负责人会关注一些异常的数据，例如超出健康度的 CR 处理时长、CR 频次等信息。项目负责人可以立即提醒相应的开发同学或需求的对应负责人，让其关注项目的进展情况，使该项目需求研发回到健康的状态。

案例三：项目级效率研判

项目负责人也可以关注自己项目的代码活动健康状况。上图中 A 项目 CR 平均处理时长在 4 小时左右，基本上当天问题能够当天解决，且 CR 平均频次为 1.8 次，说明该项目的代码评审基本能够无问题通过，或者一次把问题解决。项目的健康度较高。

而 B 项目的数据相对一般，CR 平均处理时长超过了 1 天，且平均每轮 CR 频次达到了 5.5 次，不是一个健康的状态。这时项目负责人就需要引起关注，深入项目中寻找是什么因素导致了异常，并对项目未来的进展做一些研判和决策：

• 项目排期是否正常？
• 项目开发者是否遇到了困难？
• 开发习惯和模式是否需要调整？等等。

三 思考：如何利用数据化运营解决问题？

1 数据化运营的本质是沉淀或验证经验

当我们接触一个新的领域，或者对于某些业务逻辑、用户体验不知道当前的产品设计能否真正服务到客户，就可以尝试用数据化运营来帮助观测效果，沉淀经验，知道什么样的设计是好的，什么样的设计并没有价值。

或者，借助埋点上报的真实统计数据，我们可以更客观地验证产品设计的价值。例如，某个数据表配置页面，一开始用户需要一个一个配置，效率很低；后续经过用户调研，设计添加了一个自动同步元数据的按钮，一键添加即可，用户可能只需要修改部分字段的信息即可提交。我们通过埋点观察用户从打开编辑页面到点击保存按钮的时间间隔变化趋势，即能够验证该优化的价值所在。

2 避免过度依赖数据的误区

数据化运营的优点可见一斑，但也需要避免一刀切地过度使用和依赖数据。当我们熟悉了所在的业务领域，通过多次的数据验证形成经验后，再遇到类似的场景，即可快速高效地决策。

3 数据化运营能给研发效能治理带来什么

研发效能治理是一个长期的、持续的过程。随着团队支持的业务日新月异千变万化，我们也多次迭代了效能工具来通过技术手段间接地支持着业务。

现阶段，团队所有业务的前端研发都采用现行的研发效能工具体系和数据化运营方案。搭建的数据报表主要解决“看数”的问题，可以从中主动发现异常并找到问题的根源，但数据化运营提供的能力不仅于此。

自动化信息同步机制

以往发布需求，发布负责人会运行效能工具的功能命令来打印出将要发布的需求信息，这个流程需要手动操作，且算上规范化流程中的“新建发布计划文档”“新建自测报告文档”等操作，流程成本较高。

利用数据化运营，将创建的需求信息上报到监控平台，即可利用数据进行每周定期群播报，在上线时间准确的情况下，能够让所有开发同学看到待上线的需求，做到信息同步。再通过周期任务机制自动化创建相应发布日期的文档，发布流程上的成本即可大大降低。

工程化串联

研发效能报表能做的内容远不止 CR 效率。结合工程化整体流程，我们能够加入需求、构建、发布、效能工具使用等相关指标，建设为报表站点。我们借此对整个工程化体系进行数据化运营，不断优化体验，例如提升构建速度、发布效率等，跳出研发流程管控本身，放眼更全局的视角。

实时告警和跟进

我们可以通过实时告警进一步提升主观能动性，例如当开发者合并代码出错时，立即实时上报错误，项目负责人就能第一时间知道是代码冲突、权限还是其他原因，并敦促需求负责人和开发者高效解决，避免阻塞项目进度。

当效能工具、工程化框架本身出现逻辑错误时，也能够通过实时告警及时通知到工具开发人，无需用户反馈即可排查和解决工具 Bug。

效能工具无人值守

进一步地，利用数据化运营，我们能够找出最经常出现的问题，沉淀出自查文档，在效能工具运行报错的 catch 逻辑中为用户提示出文档链接，帮助其自主解决问题。经过一段时间到沉淀，效能工具即可做到无人值守的运营，更加提升研发效能。

综上，我们以代码评审效率洞察的例子了解了如何通过数据化运营的手段管控研发效能，它能够做到平时开发准确记录，发现问题及时解决；在解决问题的同时对团队未来研发效能发展趋势有了新的思考和规划。

还是那句话，研发效能治理是一个长期的、持续的过程，我们希望能运用类似数据化运营这样的有效方法，广泛地实践研发流程，深入地定义、了解、克服其中遇到的问题，使团队研发犹如常青藤一般持续健康地发展壮大。

原文链接
本文为阿里云原创内容，未经允许不得转载。