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