读了这篇文章，[Google是如何做代码审查的？]（http://blog.jobbole.com/96110/)，结合自身的工作经历，这里谈一点体会。
代码审查的效益？
- 结对编程的一种改进
- 提升团队编码质量改进意识
- 技术影响力的传播
- 肉眼快速定位bug
- 提升编码质量
- 建立团队技术氛围
代码审查的开展？
-
规范化
- 需要一份针对各种编程语言的编码检视表（checklist），这份checklist可以在全员参与头脑风暴完成，可持续完善，也可以借鉴其他公司现有的；
- 编码checklist应该包含：语言规范、编码习惯、典型错误、功能或性能注意事项等
- 知识普及，面向代码审核参与人员进行checklist培训，讲解最好能结合现有的代码实例，举一反三；
- 根据培训反馈评估效果，需要把握培训的时机，未雨绸缪比亡羊补牢要更有效，建议在正式编码前进行checklist实训；
- 确定一整套完善review的流程，包括工具的使用方法、review响应处理、review考核标准
-
制度化
- 推广阶段，邀请leader参与推广，效果更佳
- 建立奖励机制，不妨对积极参与并有卓越贡献者进行一些简单的激励，对代码质量优秀的开发人员进行奖赏
- review流程的维护者，充当组织者，负责维护review平台，并定期发布review统计结果，能做到代码质量可视化更佳，数据要面向leader
- 前期可以加入一些硬性的措施，比如：未经有效审核的代码不允许上库，上库后发现未合理review的代码追溯对应责任人（尽管看起来很不人性，但一个专业的团队应该会很少出现违例）。
- 定期交流，知识和经验传播的有效途径
代码审查的参与者？
-
测试人员的角色
- review流程的创建者、review平台的维护者，需要熟悉checklist，具有较多的编码经验，可以对工具进行个性化改进，具有一定的文档编写能力、技术培训能力；
- 代码质量的验收和统计，辅助项目经理进行代码质量的衡量和考核
-
编码人员的角色
- checklist的贡献者，检查项来自于他们的编码经验的沉淀
- 代码贡献者，兼任代码审查者，负责审核其他开发人员提交的代码
- 知识传播者
-
Leaders
- 架构师，一般负责编码能力的培训
- 项目经理，代码质量的考核人
- 主管，代码审查制度化的推动者
代码审查的注意事项？
- 明确目的，不是为了纠错、批评，而是为了提升代码质量
- 注意措辞，以理服人
- 主要挑bug，当然其他问题也可以适当提建议，以对方不反感为前提
- 稳定的结对，根据开发模块合理的安排结对关系，有利于相互熟悉代码，bug排查会更方便
- 推动全员参与，养成习惯，但要注意“过犹不及”，开发人员的时间宝贵，记得协调