近期所带项目，由于人员素养良莠不齐，写出的代码质量不一，为了保证项目质量。不得不正确代码一行行进行审查。同一时候，为了对代码审查有个更深的了解及借鉴其他同行实践成果，在网上搜集了不少项目知识，以下是对这些知识做出的整理。
第1章前提
在 Wikipedia 上，对代码审查的定义是：代码审查（英语：Code Review）是指对计算机源码系统化地审查。经常使用软件同行评审的方式进行，其目的是在找出及修正在软件开发初期未发现的错误，提升软件质量及开发人员的技术。代码审查常以不同的形式进行，比如结对编程、非正式的看过整个代码，或是正式的软件检查。
1.1代码审查首先要求团队有良好的文化
团队须要认识到代码审查是为了提高整个团队的能力，而不是针对个体设置的检查“关卡”。
“A的代码有个bug被B发现，所以A能力不行。B能力更好”，这一类的陷阱非常easy被扩散从而影响团队内部的协作，因此须要避免。另外，代码审查本身能够提高开发人员的能力，让其从自身犯过的错误中学习。从他人的思路中学习。
假设开发人员对这个流程有抵触或者反感，这个目的就达不到。
1.2慎重的使用审查中问题的发现率作为考评标准
在代码审查中假设发现问题。对于问题的发现者来说这是好事。应该予以鼓舞。
但对于被发现者，我们不主张使用这个方式予以惩处。软件开发中bug在所 难免，过度苛求本身有悖常理。
更糟的是，假设造成參与者怕承担责任，不愿意在审查中指出问题，代码审查就没有不论什么的价值和意义。
第2章代码质量的属性
- 可理解性：代码须要在各个层面上可以被easy地理解。
理想情况下。软件应该很简单，并没有很明显的缺陷。
- 可測试性：代码须要被编写的很easy被測试。
- 正确性：代码须要满足功能和非功能性的需求。代码的行为是否与预期一致，其逻辑是否是正确无误的？被审查的代码是否与其它代码拥有类似的结构和功能？
- 有效性：代码须要有效的使用系统资源（内存，CPU。网络连接。等）。
第3章做代码审查的优点
- 更easy发现和架构以及时序相关等较难发现的问题。
- 帮助团队成员提高编程技能
- 统一编程风格
第4章代码质量低下的症状
- 全部事情都非常艰难
- 进度慢
- 測试套件执行缓慢
- 无法避免的缺陷
- 你的团队是消极的
- 知识缺乏共享
- 新开发者成长周期太长
第5章怎么审查
- 1个Review流程：先Review设计实现思路，然后Review设计模式，接着Review成形的骨干代码，最后 Review完毕的代码，如果程序复杂的话。须要拆成几个单元或模块分别Review。
- 尽可能的让不同的人Reivew你的代码：不要总是仅仅找一个人来Review你的代码。不同的人有不同的思考方式，有不同的见解。所以。不同的人能够全面的从各个方面评论你的代码，有的从实现的角度，有的从需求的角度。有的从用户使用的角度，有的从算法的角度，有的从性能效率的角度，有的从易读的角度，有的从扩展性的角度……这样以后会有很多其它的人帮你在日后维护你的代码。
- 保持积极的正面的态度：程序最大的问题就是“自负”，尤其当我们Reivew别人的代码的时候。所以，不管是代码作者，还是评审者。都须要一种积极向上的正面的态度。作者须要能够虚心接受别人的建议。由于别人的建议是为了让你做得更好；评审者也须要以一种积极的正面的态度向作者提意见。由于那是和你在一个战壕里的战友。
- 控制每次审查的代码规模：依据smartbear在思科所作的调查，每次审查200行-400行的代码效果最好。每次试图审查的代码过多，发现问题的能力就会下降。
- 要带着问题去做：我们在每次代码审查中，要求审查者利用自身的经验先思考可能会碰到的问题，然后通过审查工作验证这些问题是否已经解决。
一个窍门是，从用户可见的功能出发，如果一个比較复杂的使用场景，在代码阅读中验证这个使用场景能否够正确工作。使用这个技巧。能够让审查者有代入感，真正的沉浸入代码中。提高效率。
- 尽量使用静态代码分析工具以提高审查效率。
- 二八定律处理高风险代码：审查全部的代码并没有太大的意义，应该把审查的重点放在高风险的代码和easy引起高风险的改动或者重构的代码上。
旧而复杂、处理敏感数据、处理重要业务逻辑和流程、大规模重构以及刚增加团队的开发人员实现的代码都是审查的重点。
- 让原作者对发现的问题进行确认：这样做有两个目的，确认问题确实存在，保证问题被解决；让原作者了解问题和不足。帮助其成长。
- 自我审查：全部团队成员在提交代码给其它成员审查前，必须先进行一次审查。这次自我修正形式的审查除了检查代码的正确性以外，还能够完毕例如以下的工作：
- 对代码加入凝视，说明本次改动背后的原因，方便其它人进行审查。
- 修正编码风格。尤其是一些重要数据结构和方法的命名，提高代码的可读性。
- 从全局审视设计，是否完整的考虑了全部情景。在实现之前做的设计假设存在考虑不周的情况，这个阶段能够非常好的进行补救。
- 代码审查结束后的回想总结：成员在编码的时候应做随手记录。包含在代码中用凝视的方式表示，或者记录简单的个人文档。这样做有几个优点：
- 避免遗漏。在编码时将考虑到的不论什么问题都记录下来，在审查阶段再次检查这些问题都确认解决。
- 根据研究，每一个人都习惯犯一些重复性的错误。这类问题在编码是记录下来，能够在审查的时候用作检查的根据。
- 在重复记录笔记并在审查中发现类似的问题后，该类问题出现率会显著下降。
第6章实践要素
人员结构
在你的团队中有多少同事拥有足够的专业技能来担当合格的代码审查者？作者以前和多个开发团队沟通过。这些团队都声称本身仅仅有一个资深的开发者。假设让他来负责全部的代码审查工作，那么团队的核心开发就无法开展了。作者也遇到过类似的情况。在一个小规模团队里。资深的同事总是忙只是来，由于核心的工作都在等着他做。
地理位置
你的团队成员是怎样分布的？他们是否是分散在世界各地还是坐在同一个敞亮的办公室里？ 代码审查须要精力的专注和反馈。假设开发者可以面对面的沟通，那么审查工作会便于实施。而物理隔离的远程团队非常难达到代码审查的惬意结果。
所在领域
你所在的IT领域须要遵守如何的规则和约束呢？假设你在一个受到严格监管的行业，那么你必须遵循有关审计和报告的规则，这意味着你必须想办法跟踪代码审查的频率和质量。假设所在的领域把安全性作为重点。那么可能在代码审查过程中要引入安全审计。
复杂性
你的代码复杂性怎样？在代码审查时，须要多个不同专业技能的审查者吗？比如，游戏开发可能会引入很复杂的业务逻辑来处理文字交互和场景跟踪，同一时候还须要特定的动画处理和内存管理技术。在审查如此复杂的代码时，应该引入多个审查者从不同角度来检阅代码的质量。
第7章一个时间安排的样例
Eric Landes在一篇名为《敏捷技巧：什么时候以什么方式来进行代码评审》的文章中。提供了一个时间安排的样例：
- 概览本次代码评审的故事(10分钟)
- 讨论团队指标(10分钟)
- 强调评审的特别关注点(5分钟)
- 深入地评审代码(55分钟)
- 代码覆盖率
- 架构
- 深入的分析报告
- 总结并记录行动事项(10分钟)
第8章代码检查工具
第9章參考资料
