前言
让我们以一个研发团队的故事，来开始这个话题：
当一个团队成立始初，人数很少，而可做的事情很多。在项目初始，可能每个人每天提交的代码都以千为单位，其中大量的脚手架代码、大量的通用代码、大量的基础业务代码……几个人，在一张硕大的白纸上随意的涂鸦，每天都有重大的突破——今天讨论好架构，明天建好仓库，后天项目跑起来，大后天打印出hello world，每个人都激情澎湃，享受到原始的、高级的、创造的快乐之中。
随着项目的壮大，越来越多的人加入到团队之中。此时可以做的事情依旧很多，甚至更多了：除了基础的业务代码，CICD的建设开始被关注起来。因此除了实现业务代码，还有大量的人力投入到自动化流程、工具、效率的建设上。在这个阶段，一条条自动化测试、自动化静态代码检查、自动化部署、甚至自动化debug的流水线建设起来。每个人都乐意开发新工具，每个人也享受新工具带来的便利，而这进一步促进了新工具的开发，大家依旧能重复享受创造的快乐。
大概一两年之后，团队更加大了，一个人开始管不过来，需要进行多级分层的管理。另一方面，公司看到了业务的前景，也对团队加大招聘的投入。无论如何，团队有了更深的组织架构，更长的汇报线，领导头头再没精力去关注细节，只有时间去看看指标，看看数据大盘。
需要度量吗？
这让我想起来另一个话题，需要code review吗？我见过很多文章分享没有code review的研发团队，比如 No code reviews by default。code review、效能度量，都是需要团队的情况而酌情展开的。但是基本上而言，一个大型的团队+一个大型的项目，基本总是需要code review的，也总是需要效能度量的。
并不是说有code review和效能度量就是好，而是当了 项目 / 团队 到了一定规模之后，不得不做这些工作来保证质量。也并不是 项目 / 团队 达到某个程度之后，就必须有这些工作，事实上是一个越好越优秀的团队，越可以推迟这些工作的展开。打个比方，一个一般的团队，在10个人的时候，就需要展开这些工作。而一个优秀的团队，在30人的时候，才需要展开这些工作。
然而效能是出了名的难 度量，唾手可得的一些指标中，往往都和我们期望的结果没有直接的对应关系。举个例子：接入sonar的仓库比例。 接入sonar就代表用了sonar吗？大家可以理解sonar的ERROR、WARN背后的原因吗？接入sonar之后，我们就开发得更快了吗？
除了难度量，另一个方面的原因在于，软件开发行业是一个把人当人用的行业，而不是一个把人当机器用的行业。编码一个富有创建性的工作，类比建筑、绘画，有时候只需要神来一笔，就可以达到极好的效果。这其中的工作量，只是一笔。这其中的效果，却胜过无数笔。
我们要度量，不能只度量过程，更重要的是度量结果。
如何度量
因此，对于效能的度量，要从目的去审视过程，再去确定目标。而不能盯着过程，这样则会变成为了度量而度量。此外，还要关注到度量本身的局限性，有些事情本该如此，不值得专门为其去过度度量。
。而提高效能的目的非常简单和直接：提高开发效率。进一步拆解，可以拆分为
- 提高需求的开发速度（包括设计、编码、自测、联调、回归、上线）
- 减少变动带来的缺陷（变动包括新功能和debug；缺陷包括功能缺陷、性能缺陷、安全缺陷、部署缺陷、依赖缺陷等等）
- 减少其他事情的时间（包括写文档、沟通、处理坏心情、弥补加班带来的损伤、向上汇报等等）
以上是目的，为了实现这些目的，我们需要重新审视我们的流程，去分解目的，设计可实施的目标。目前在互联网公司中，常见的研发流程，写的细一点，包括：
- 需求确定
- 方案设计
- 方案评审（2-3循环）
- 编码，实现需求
- 需求自测，包括单元测试、API测试、集成测试、联调
- 需求提测 & debug（2-6循环）
- 需求上线（1-7循环）
具体指标的分析
单元测试 接入率 / 覆盖率
首先澄清：
- 这里提到的是单元测试，可以泛化为最低限度的测试，并不强调形式和定义。
- 这里是研发的白盒测试视角，对于QA同学而言，黑盒测试会有完全不一样视角，暂且跳过不谈。
测试的代码覆盖率和接入率，其实是一个非常具有迷惑性的指标。学术上讲的测试覆盖率，包括：
- 语句覆盖（行覆盖率）：使被测试程序的每条语句至少执行一次。
- 判定覆盖：使被测试程序的每一分支都至少执行一次。
- 条件覆盖：要求判定中的每个条件都按“真”“假”两种结果至少执行一次。
- 判定/条件覆盖：要求判定中的每个条件都取到各种可能的值，而且每个判定表达式也都要取到各种可能的结果。
- 条件组合覆盖：要求判定中每个条件的各种可能组合都至少出现一次。
通常我们以单元测试的行覆盖率作为项目的测试覆盖率，但是可以看到，行覆盖只是覆盖率中最简单，要求最低的一种指标。如果为了刷覆盖率而刷覆盖率的话，并不是太复杂，但是对效能提升的效果，则是非常有限了。真正有效果的条件覆盖（及其往上），往往需要大量的排列组合数据+表驱动测试，其也不会有更高的行覆盖率。
综上，常规的行覆盖率只能代表一定的测试覆盖率，并不能完全体现测试覆盖率。不过从其反面讲，一个行覆盖率低的项目，其质量大概率不太行。因此作为一个相对容易获得的指标，其和项目真正质量的关联程度大概是中等程度相关。测试接入率基本则关联性更低。
Code Review 时间 / 千行代码评论数 / 发现的问题数
先澄清概念
- Code Review时间：停留在Code Review页面上的时间
- 千行代码评论数：一段时间内，评论总数 / 修改代码千行数
- Code Review发现问题数：在评论之后，这段代码被修改的数量。其是评论数的子集（应小于评论数）
然后再澄清一些背景：
- 优秀的程序员往往会多次少量地提交代码，因此这些代码会被更快review，反之亦然。
- 优秀的程序员往往会在总量上写下更少的代码，反之亦然。
- 对于巨大的MR，有些Reviewer会把代码拉下来，在本地Review。
- 对于巨大的MR，有时会推荐进行线下Review，以节省时间
因此，这些指标也都不能体现Review的质量和效率，也不能体现最终的质量。不过如果某些指标过高和过低，则可以引导我们反思一些问题：
- Code Review时间太长：大家都把时间花在review上了？
- 所有指标太低：这个项目到底有没有Code Review？
因此，这些指标的和效能的关联度，也比较低。
Bug修复速度
Bug修复速度，是指已修复的Bug，从提出到解决所花费的时间。
细想一下就知道这个指标不太对劲。Bug也分等级，对程序员而言，多个事情也有优先级的先后。一个Bug修复时间长，不代表其就难修复，也可能只是这个Bug太不紧急了，而现在有其他更加紧急的事情要做。
因此，Bug修复速度和效能的关联度比较低。
对程序员问卷调查
这个我没列出具体的内容，但是我感觉，程序员对目前开发环境、开发流程、开发工具的满意程度，是和效能有比较紧密的正相关性的。在产品经理的“高压”下，还能拥有舒服的开发体验，那么一定说明效能做得还不错
\
