敏捷团队中的代码审查

读了这篇文章，[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排查会更方便
• 推动全员参与，养成习惯，但要注意“过犹不及”，开发人员的时间宝贵，记得协调