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的一部分。
文章来源如何做code review
