ode Review是一个老生常谈的话题，其作用及意义此处不多说，本文仅结合我过去的工作经历，总结下如何在实际工作中更有效的做起来CR。以下是几点思考，请大家批评指正。
一、需要工具的支撑。拉几个人坐一块讲讲代码，不是我理解的CR，只能算是代码讲解。我认为一次有效CR需要工具的支持，比如开源Review Board或者收费code collaborator等。
二、参与人员角色。参考cc中author\reviewer\observer的划分，我认为在实际执行中可以这么做：author即一次CR的发起者，选同组的两名开发人员作为reviewer，选测试人员、产品和研发负责人作为observer。reviewer必须要做出响应，observer可选。
三、一些基本的规则。
3.1 reviewer平均每分钟review的行数不能超过XX行
3.2 author提供必要的diff文件
3.3 一次CR不超过XX个文件
3.4 如果是修bug，那一次CR尽量控制在3个bug以内
3.5 如果是新的feature，那一次CR就对应一个feature
3.6 CR包括但不限于代码功能和规范
如果把CR的范围扩大一下到Peer Review，那么需求、设计、开发、测试等相关的doc和plan都可以参考其中的一些规则。
