Code review 对于软件项目来说是一个经常听到的词，大家都在强调质量左移，Code review 既是质量的一道门禁，也是知识分享的一个很好途径。那么如何保证 review 的质量？

首先我们要在团队的技术能力的不同阶段采用不同的 review 策略。比如团队稳定，编码规范掌握的比较好，使用的语言也是熟悉的语言，那么可能 review 的重点就会放到业务逻辑方面；目前本人所参与的项目则采用此方式，团队成员技术成熟，基于 GO 语言编码业务，多人参与 Sprint 迭代一个用户故事开发，若开发完成，则由用户故事开发负责人进行 review 其他人实现该用户故事的代码，没问题后提测，即 Code Done 的 DOD 包括 code review 通过。如果团队新成立，还在磨合，可能编码规范就需要多注意；如果是团队新换了一门编程语言，那么语法本身可能也会是 review 的重点。如果是这种场景，本人参与项目的做法是由架构师组织团队成员线下 review 会议，会议上架构师说下项目代码写得优雅的地方以及需要改进的地方。

在公司业务发展的不同阶段也需要采用不同的 review 策略。比如 To B 的业务在稳定推进，那么 Code review 可能需要更加仔细严格，保证质量和代码的可读性可维护性；但是如果是在互联网行业，业务发展初期，在快速试错阶段，那么 Code review 需要 Technical leader 去平衡 review 力度和业务交付的要求。

需要团队里有开放的文化和心态，Code review 有时会被团队成员认为是挑毛病，但是通过 review 达到团队代码层面的 bug 数越来越少，并且互相 review 也可以提升编码能力，逐渐让大家意识到是代码 review 是一个必不可少的质量保证过程，同时也是一个互相学习的过程。但是我们也要注意控制每次需要 Review 的代码量。如果一次提交大量的代码进行 review，帮助做 Review 的人一个是时间上很难一次性拿出这么多的时间，另外一个是也很容易抓不到重点。同时提交代码的人在 commit note 中应该写清楚提交代码的目的：实现的是什么功能？做的是什么优化？修改的是什么 bug？这样 review 的人才能有的放矢，清楚代码改动的上下文。

最后要让 Code Review 变成一种习惯，工作中的一部分，那么就需要对 Review 者的时间有所保证，建议 Sprint 计划会上团队预估时的时候考虑到 code review 的时间，可以参考之前几个迭代 review 的时间作为 buffer 预留在迭代中，这样 review 才能作为一个日常任务被执行，同时把 code review 作为用户故事 DoD 的一部分。