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

简介：数据中台前端研发无不让人厚重实在地感触到“惟一不变的是变动”。拿团体的数据资产服务平台来说，业务上通过两年的倒退，已由繁多的数据管理和应用平台倒退成了团体具备肯定规模和影响力的全域数据因素交易所，而从前端技术侧，仅从代码提交报表就能显著看到，往年的代码提交量均匀是去年的 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 逻辑中为用户提醒出文档链接，帮忙其自主解决问题。通过一段时间到积淀，效力工具即可做到无人值守的经营，更加晋升研发效力。

综上，咱们以代码评审效率洞察的例子理解了如何通过数据化经营的伎俩管控研发效力，它可能做到平时开发精确记录，发现问题及时解决；在解决问题的同时对团队将来研发效力发展趋势有了新的思考和布局。

还是那句话，研发效力治理是一个长期的、继续的过程，咱们心愿能使用相似数据化经营这样的无效办法，宽泛地实际研发流程，深刻地定义、理解、克服其中遇到的问题，使团队研发犹如常青藤个别继续衰弱地发展壮大。

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