如何利用Checklist做好Code Review?
极客时间编辑部
讲述：丁婵大小：6.74M时长：04:55
你好，欢迎收听极客视点。
对于很多团队来说，Code Review 通常充满争议。即使团队知道 Code Review 很值得，但他们仍然难以使之奏效。最近，软件工程师丹·戈斯伦（Dan Goslen）发文分享了他们团队利用 Checklist 进行 Code Review 的方法。公众号“高可用架构（ID：ArchNotes）”翻译了它，供你参考。
Checklists 如何工作
创建和维护一个 Checklist 可以让团队不会因为 Code Review 感到情绪紧张。我们都知道什么是 Checklist。NASA 将 Checklist 提升到了另一个层次，他们为太空飞行中涉及的每一个过程定义了 Checklist。
吉恩·克兰兹（Gene Krantz）的《失败不是一种选择》（Failure Is Not an Option）一书，就是他从头开始帮助 NASA 建立任务控制的回忆录。在书中，克兰兹讨论了他在 NASA 的职业生涯中所经历的失败和成功。其中的关键是吃一堑，长一智，从每次失败 / 成功中总结经验教训，而他们总结这些教训的方式是调整每个过程的 Checklist。有了这些 Checklist 后，他们不仅更容易做出“去或不去”的决定，而且还有信心做出正确的决定。
Code Reviews 也很重要
让我们先说清楚：Code Review 并不像将人送入太空的决定那样紧张。
然而，Code Review 是很重要的。软件已经延伸到各个领域，如医学、金融、驾驶、航天等等。你所处的行业可能不需要像上面列出的一些行业那样有严格的要求，然而你写的代码会影响到人，甚至会影响到世界。
作为软件工程师，我们需要尽早承担起自己作为软件工程师的责任。我们不能成为懒惰的开发人员，我们不能在没有测试验证修改的情况下就批准代码上线，我们不能在最后期限内忽略了代码变坏的明显迹象。
你需要一个 Checklist。
如何开始？
你可能疑惑，怎么才能弄清楚哪些是在 Checklist 上，哪些不是？
你可以去写一份入门 Checklist，其中包含对你在 Review 中的要求。在你 Review 的过程中亲自参考你的这个 Checklist，并密切关注你 Review 的代码。随着时间的推移，对它进行细化和增减。
一旦你使用了几次个人 Checklist，就把它向你的团队开放。不要把它强行塞给任何人，也不要强制要求使用它，只需把它作为共享资源即可。然后你的队友会帮助你完善它，并加入自己的想法 / 观点。即使他们会在一些事情上不同意你的观点，但如果你在其中花了心思，他们也很有可能会赞赏并使用它。
一旦每个人都开始使用它，那么就可以把它做成一个 Google Doc，在每次 Code Review 时，你都会把它放在每个开发人员面前。同时，确保它和你团队的入职指南放在一起，要保证每个人都知道 Checklist 的存在并能随时找到它。
举个例子
万事开头难，我不一定能帮你完成，但希望我可以帮助你开始。
我们的 Code Review Checklist 相当短。某些应用程序中有一些针对特定问题的附加项，这些问题通常会被遗漏。我不能分享我们使用的 Checklist 的这些细节，但它的基础部分看起来是这样的：
这些代码更改是否符合业务需求？
这些代码更改是否符合团队的编码质量要求？
这些代码更改是否有相关的测试？
这些代码更改是否有截图或用户界面更改？
是否为这些代码更改更新了变更日志？
是否为这些代码更改更新了应用文档？
这个 Checklist 并不关注细节，比如 “我的变量是否被正确命名”，因为这些包含在第二项中。它关注代码 Review 的核心，也就是理解。
Checklist 可长可短，建议越短越好，就像没有人想成为 Code Monkey 一样，也没有人想成为 Code Review Monkey（指按照 Checklist 做机械检查）。让你的 Checklist 专注于帮助作者和审查者思考经常被遗忘的事情，这对你的团队会有很大的帮助。
以上就是今天的内容，你的团队有哪些特别的 Code Review 方式呢？欢迎分享。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
该免费文章来自《极客视点》，如需阅读全部文章，
请先领取课程
请先领取课程
免费领取
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(2)
- 最新
- 精选
978!6《清单革命》可以看看1
慕容飘这个节目挺不错
收起评论