代码评审（Code Review）是保障代码质量中一个非常重要的环节，也是保证项目交付质量的关键一环。代码评审的开展对于产品质量提升、工程素养提升、研发团队的技术分享交流，或是完善团队代码规范，都能起到重要的促进作用。所以代码评审也是研发效能度量中重要的一环。同时，代码评审的度量结果也可以反映出团队在需求拆分、代码提交等方面的规范是否合理。而且对代码评审进行度量最重要的优点在于，代码评审的度量指标通常是与团队的行为直接相关的，可以直接从度量分析结果中发现团队提质增效的明确方向。
目前思码逸的研发效能度量分析平台DevInsight 已经支持对代码评审进行度量、分析，并提供了相应的分析看板。
思码逸DevInsight中的代码评审度量与分析
近期思码逸DevInsight 新增了度量代码评审的对应指标与看板。那么思码逸DevInsight 是如何度量代码评审的呢？
思码逸DevInsight是从项目角度对代码评审这个领域进行度量的。在开发过程中，提PR是常规操作，但要保证PR能够被及时合并，合并时间不能过长。所以第一类指标是PR合并的效率和时间，包括 PR 的数量、合并时长等；第二类指标是代码评审的质量和过程，例如每次 PR 的大小，这部分我们可以通过代码当量来进行度量，会比代码行数更科学；第三类指标是需要度量代码评审中是否存在瓶颈，是否存在代码评审的积压。综上来讲，我们可以大致总结为以下指标：
1. 项目中开发者提交、处理代码变更的速度如何？（速率、吞吐率类指标）
-
PR 的创建数量
-
PR 的完成数量
-
PR 的合并时长
2. 项目代码评审的质量如何？
-
PR 的大小
-
PR 合并/拒绝 占比
-
已合并但未评审的 PR 数（占比）
3. 代码评审的流程中是否存在瓶颈？
-
未完成 PR 数
-
PR 的合并时长
-
编码时长
-
响应时长
-
评审时长
-
总流转时长（需要支持 DORA）
通过这些指标，我们不仅可以分析团队在代码评审环节中的表现，还可以通过这些数据看出团队在代码评审之前的其他研发环节中是否有需要改进的地方。例如，当我们发现有较多的 PR 堆积，等待评审，那可能说明研发团队在最初拆分需求的时候，需求颗粒度拆分得比较大，或每个PR 提交的长度较大（具体观察代码当量或行数指标）。团队就需要优化需求颗粒度的拆分，或规范提交 PR 的长度。另外，很多大公司都比较看中代码评审环节，那么团队可以利用“评审深度”指标或“已合并但未评审的 PR 数”指标来观察团队对代码审核的认真程度，从而保证项目质量。
如果我们基于上述几类指标进行度量，那么我们在思码逸DevInsight 中会得到这样的看板（如下图所示）。我们在「吞吐率」的看板中，可以看到每个步长新建、合并、拒绝合并和未处理的 PR 数量；在 「PR 合入时长」看板中分析目前平均每个步长 PR 合并的数量，了解 PR 合并的效率。
同时，思码逸DevInsight 还提供了看板来度量分析合并/拒绝的 PR 占比、已合并但未评审的 PR 数量与占比，以及评审深度。在「已合并但未评审的 PR」看板中，如果发现有一个步长出现了大量该类型的 PR，可以点击进去，进行下钻分析，查看具体有哪些 PR，避免出现影响项目质量的风险。
在后续的版本中，DevInsight 还将可以从团队、个人两个视角进行度量，包含 PR 的通过率、PR 的质量、团队中不同角色对代码评审的响应速度、评审深度等指标。以上例举的都是基础指标，我们支持不同规模、不同业务类型的团队，根据自身情况，结合更多指标进行更深度的度量与分析。大家如果对该功能感兴趣，可以申请试用思码逸DevInsight，在产品中自行尝试，也可以在官网联系我们官方咨询师进行演示和讲解。
121
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
