Code Review 一般可以找到及移除约 65% 的错误，最高可以到 85%。

Code Review 最主要的功能是提高代码质量: 发现不合理的设计，明显的逻辑错误等。此外，Code Review 也能学习别人好的写法，熟悉其他的业务。

下文中的 CR 指 Code Review。

什么时候做 CR

很多团队，在新功能 或 修或将合并分支时前，负责人会做 CR。这要求每次合并的功能不能太多。对大规模的代码改动做 CR 很难。有些团队有会鼓励团队成员交叉做 CR。

还有一种是定期的 CR。小组开发成员在一起做 CR。组织者挑一些代码来做 CR。

CR 做什么

CR 主要是看对代码对功能实现的设计。关注：

  • 选择的数据结构和算法是否合适。
  • 后期改动的拓展性怎么样。
  • 代码性能和安全性方面的考虑。
  • 是否过度设计了。

细节方面，关注：

  • 代码是否健壮。异常的处理。边缘情况的处理。是否会影响已有代码。是否出现高耦合的情况。
  • 代码可读性的检查。命名是否合理。有没有魔法数字。是否有必要的注释和文档。

CR 不做什么

CR 时不做能用工具完成的检查。比如：

  • 代码风格的检查。用 Lint 工具来做这事。
  • 有些客观的代码质量原则。比如：条件语句最大分支数(圈复杂度)。用 Lint 工具来做这事。

思考

  • 在 CR 时，代码作者 和 reviewer 如果出现了冲突怎么处理？
  • 如何快速做 CR？ CR 太慢，会影响团队整体的进度。
  • 对大规模的代码改动做 CR？
  • 哪些情况下，需要放宽 CR 的标准？
  • reviewer 对于编码能力不是很强的开发者，需要哪些改动建议？
  • 如何写出让开发者容易接受的改动意见？

你们团队有做 CR 吗，是怎么做 CR 的，来分享一下吧~

参考文档