代码评审（Code Review，以下简称CR）是指通过阅读代码来检查源代码与编码标准的符合性以及代码质量的活动。其目的是帮助提高代码质量，尽早发现由于编码习惯而造成的缺陷，重新梳理思路，最重要的是促进团队沟通共享，共同识别优秀的习惯和模式，把代码评审活动看做一种 学习活动而非批判活动。
内容
- 编码风格、文档与注释
- 代码结构
- 工具框架的使用
- 功能和业务逻辑、异常处理
- 安全性、性能
- 可测性
- 工具扫描出的违规项和编译器警告
形式
- 交叉评审（代码走查）：团队成员互相检查代码
参与者：可以是任意两个组员，或开发组长分别与每个组员结对进行
代码作者讲解如何以及为何这样实现、评审者提出问题和建议。
记录问题和建议。每次不超过400行。 - 会审：以项目为单位，召开专门的代码评审会议
参与者：包括项目组全体成员，其它组的开发组长也应尽量参加
会前准备工作：选择评审范围、每人都提前阅读和记录问题。 - 守护者评审：”Component Guardian”来自于诺基亚西门子的内部敏捷实践，即每个模块有1个主要负责人，其他人都可以贡献代码，但必须由守护者评审后才能提交，确保质量和风格结构一致。类似于Github的
Pull Request模式，企业内部可以基于此形成内部开源社区。
议程
- 整体介绍、展示规范和参照
- 轮流主持，跟踪上次的改进项
- 依次讲解根据评审标准事先发现的问题
- 对每个问题不超过10分钟讨论
- 有时间再进行地毯式讲解，或讨论性能、安全性等专题
- 记录作为会后改进项。也可对评审会本身进行回顾
反馈
最近 @申导 以敏捷教练的身份带几个团队做了Code Review活动，收集到一些实际反馈。
- 学到了不知道的知识和习惯，不再踩别人踩过的坑
- 促进团队内的沟通，避免重复劳动
- 引发更多的新思考和新尝试
- 有人看自己的代码，敦促自己写的更好些
- 讲一遍自己的代码更加深印象
- 相关人来参加则效果比较好
- 可以先讲讲背景，便于大家代入
- 有投影可以让大家都看清
- 集体评审的话人们时间不一定能凑齐，两两结对评审更灵活
Reference:
- 想要进一步了解敏捷工程实践，关注Certified Scrum Developer国际认证课程