[译] 如何让高效的代码评审成为一种文化

时间 2019-11-08

标签如何高效代码评审成为一种文化繁體版

原文原文链接

原文地址：Effective code review

原文做者：Bryan Liu

译文出自：掘金翻译计划

本文永久连接：github.com/xitu/gold-m…

译者：子非

校对者：7Ethan, smallfatS

如何提高代码质量常常在某一段时间成为开发团队工做的重点，咱们积极地讨论如何提高单元测试的效率，如何增长测试的代码覆盖率。然而好景不长，你们各忙各的，提高代码质量的热情也就慢慢降温了。可是，但不超过一年，历史又将重演，人们又将重提类似的观点。个人名字叫 Bryan Liu，目前是在 LINE 从事自动化测试的一名质量工程师，我想分享在 LINE Taiwan 我是如何帮助改进单元测试和代码评审进程的。html

单元测试和代码评审

正如在职培训上 CTO 在向咱们解释的同样，同行代码评审是 LINE 工程师文化的一部分。Facebook 指出开发过程当中最重要的三件事 —— 代码评审、代码评审和代码评审。是的，解决单元测试和改进代码质量的惟一方法是使单元测试成为咱们工程师文化的一部分，而这就是代码评审帮到咱们的地方。前端

针对代码的童子军规，来自 {codemotion}android

请遵循这个童子军规，该规则建议评审人检查单元测试是否支持在评审期间补充新代码和修复 bug，经过持续执行此操做，代码覆盖率应该扩展或至少维持不变。举个例子，若是代码覆盖率降低，则评审人应向团队解释他/她遇到的困难以及不添加更多测试的缘由。若是全部人都承认该解释而且没提出新问题，他/她能够继续，不然，评审人应予以解决！ios

有效的代码评审小贴士

最高效的代码评审方式是结对编程，不过若是 GitHub 的 PR（Pull Request）适用于你的团队，那么 PR 一样可行。为了搞定代码评审，我指的是彻底搞定，咱们首先应该尝试提升代码评审流程的效率；咱们的想法是把评审人当作稀缺的资源，由于咱们的主要职责并非代码评审，对不对？！git

如下是有效并高效的代码评审的一些提示：github

每次提交的改动尽可能小

Cisco System 编程团队的一项研究代表，对 200 到 400 LoC（代码行）进行 60 到 90 分钟的长时间评审能够发现 70—90% 的缺陷。把每次 PR 的内容当作一个独立单元处理（功能，bug 修复）或有意义的相关性强的想法。想了解为何单次 Pull Request 提交大量代码弊病繁多以及 Pull Request 的最佳量级，请看此处。web

代码评审，来自于 Twitter @iamdeveloper 与缺陷密度 vs LoC，来自于 Cisco 研究案例。算法

常常评审并缩短评审时间

以合理的量级，较平稳的速度及利用有限的时间内进行代码评审，能够获得最有效的评审结果。超过 400 LoC，发现缺陷的能力会下降。低于 300 LoC/hr 时检验效率是最好的。编程

缺陷密度与检验效率，来自于 Cisco 研究案例。后端

尽早发送 Pull Request 以供评审

为了得到有价值的代码评审，在细化实现前发起讨论并尽可能避免提交很是大段的改动。将不一样的想法分红不一样的 PR，而且根据须要分配给不一样的评审人，将大问题分红较小的问题并一次解决一个小问题。

若是在代码评审的最后一分钟发现架构/设计问题，该如何应用应急办法，来自于 Twitter @isoiphone。

提供足够的背景信息使 Pull Request 旨意更明确

评审人资源能作的十分有限，请明智地对待。

为了帮助评审人快速进入问题背景，提供足够的信息很是重要，例如改动的缘由和方案，以及潜藏的问题和须要关注的点。想要激发高效的讨论，这些信息是必不可少的催化剂。做为额外的好处，做者一般会在评审开始以前发现其余错误。虽然不是每一个 PR 都值得写出这样的细节，可是你能够简单地注释已经完成和测试的内容或者评审人应该更加关注哪一个部分！

GitHub Issue 和 Pull Request 模板可能会有所帮助。另外，附上截图来描述您达成的效果是一个好主意！下面是几个关于使用 PR 模板为代码评审和进一步 QA 验证提供有意义背景的例子。

Github PR 模板示例

Linting 和编码风格检查

让机器使用 SonarQube 和 ESLint 等工具进行静态代码分析和编码风格检查，为业务逻辑和算法等重要环节节省注意力。这些代码扫描工具、类型检查工具和 linting 工具能够报告错误，code smells 和漏洞，使用好的测试套件确定能够提升代码可靠度。

在 SonarQube 中发现问题，图片来自于 SonarQube 站点

代码评审中最重要的部分之一是奖励开发人员的成长和努力，所以请提供尽量多的赞美。

最后，若是你没法理解部分代码，则没法进行适当的评审。若是你的讨论彷佛是反复的，那就面对面地完成这部分讨论，那样会更有成效。

使之融入咱们的工程师文化

有人说“文化是即便没人监督也会天然为之的事”。在跳过代码评审过程时，你是否仍会为代码编写足够的测试？不容易吧？但它仍然值得尝试！若是您的项目采用了敏捷开发模式，请考虑如下因素，以使您的团队文化能自我导向，不断改进和学习：

自治：团队成员以他们喜欢的方式承担责任和工做（例如：Scrum，结对编程）
提高：持续执行良好的编码实践并经过代码评审相互学习，最终能够提升我的编码技能
目标：代码质量是咱们的最终目标，应该在早期发现错误而不是在生产中灭火

所以，为了促进团队文化建设，我开始尝试如下两个项目：

加强技能

是的，为了深刻开展这项工做，开发人员还须要有全面的概念和完整的知识，才能在平常工做中达到团队不断增加的共识（实践）。为了帮助开发人员，咱们请来本地培训机构开展有关单元测试，重构和 TDD（测试驱动开发）的培训。

咱们在研讨会上讨论了如下主题（列出但不限于此）：

单元测试
- 设计测试用例用来展现目的，而不是测试代码的实现
- 须要识别并隔离依赖
- 引入抽取和覆盖以及依赖注入方法
- 解释 stub 和 mock 框架及断言库
- 练习重构技巧，如抽取方法，内联变量等等。
Kata（编程）着手于
- 需求分析、优化方案并找出关键示例
- 编码设计和实现
TDD 和重构
- Demo 重构，标识 code smells 及移除相关方法
- 使用 TDD 方法进行实时编码（例如：小步前进，红绿灯）
- 着手实践

研讨会期间的照片

评估进度

若是你不了解进度，你就无从评估进度，更没法提高进度！

咱们运用公示屏展现分析结果并经过消息通知持续推送最新进度，强大的视觉效果增长了你们的参与度，为了同一个目标咱们共同努力。位于门口的大型公示屏会循环展现以下信息。

SonarQube 项目公示板

全部的静态代码分析数据来自于 SonarQube，直接连接到生产服务的代码仓库应该在这里发布报告。

基于团队的代码覆盖率

基于团队的代码覆盖率图表显示了团队中每一个仓库的覆盖趋势，所以无需导航到每一个 SonarQube 项目页面。经过将这种类型的图表并排放置，能够很容易地比较不一样团队的表现。

PR 的大小与解决时间

DevOps 的核心思想是如何将软件变动频繁地发布到生产中，同时保证质量。使每一个部署单元变小是这里的诀窍。大型 PR 不只没法进行良好的代码评审，并且还会增长在代码质量和发布周期成本，所以对于 DevOps 将任务/变动作小是行之有效的技能。咱们尝试使用如下“分辨率时间与 PR 大小”图表来推动这一理念：

气泡大小：更改设置大小（代码行）
解决时间：PR 建立时间到 PR 合并时间
#n：PR 号

这些图表持续提醒每一个人采用良好实践和追求目标的进度。这些只是咱们在这里作的一些例子。想一想你本身能够直观地向别人展现你的意图。顺便说一下，这些对于月度会议期间总结进展也颇有用。

PR 评论通知

提交给 PR 的每次提交都会触发一个 webhook 来发布 github 评论，以下所示。这是为了提醒 PR 建立者添加测试并修复在此 PR 内部发现的新漏洞，这比在两周后把更改发布到生产中更为有效。为了提升质量指标，评审人还应该帮助找出被评审人遇到问题的缘由。

最新 n 次提交的平均值: 展现每种指标的趋势
xxx 次问题：发现的 bug，漏洞和 code smells 的数量
代码覆盖率：执行单元测试的 LoC 百分比

总结与将来计划

为了给代码评审讨论提供很好的环境，知晓如何编写整洁的代码以及如何识别 code smell 并删除相当重要，只有团队真正下功夫解决这些常见问题，文化才能随之培养。

另外一方面，没用的指标不须要跟踪；显示数据随时间变化的趋势很重要，它提供给咱们作出相应措施的背景。看看上图中显示的趋势线随着进展而变化。此外，咱们还考虑添加更多公示板展现如下内容：

质量：开启/关闭的 bug 数，同时展现严重性和缺陷密度
速度：部署频率，生产前导时间，修改失败率和平均恢复时间（MTTR）

参考

若是发现译文存在错误或其余须要改进的地方，欢迎到掘金翻译计划对译文进行修改并 PR，也可得到相应奖励积分。文章开头的 本文永久连接 即为本文在 GitHub 上的 MarkDown 连接。

掘金翻译计划是一个翻译优质互联网技术文章的社区，文章来源为掘金上的英文分享文章。内容覆盖 Android、iOS、前端、后端、区块链、产品、设计、人工智能等领域，想要查看更多优质译文请持续关注掘金翻译计划、官方微博、知乎专栏。