有关Code Review的一些思考

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都可以参考其中的一些规则。