代码评审（Code Review），主要检查代码和设计的一致性，代码对文档标准的遵循及代码的可读性，代码的逻辑表达式正确性，代码结构的合理性等方面。正式的Code Review是发现潜在缺陷最有效的手段之一，大部分的测试，发现的潜在缺陷率会在30%左右，Code Review一般可以找到及移除约65%的错误，最高可以到85%，找到bug只是其中的副产品，更重要的是能够确保代码库整体的健康程度随着时间的推移而不断改善，提高代码和产品的整体质量，同时可以达到知识共享。
代码审查已经被广泛的认可为一种非常好的做法，很多团队都在这样做，但是做得又好又有效的，不算多数。大多数是因为：
- 团队主要以业务为主，以上线为目的；
- 需求经常变动，代码的生命周期太短。
- 将代码评审作为一种教条，意义不大，有测试，只要不出错，就可以了。
- 评审流程不够完善，使得投入的成本和收获成反比，毕竟“结果更重要”。
- 人员态度，不想精益求精，只要干完活交差了事。
当然编写本文档并不是为了说明Code Review的重要性和怎么做会更好，而是希望通过规范达成共识，毕竟每个小组的情况不同，对Code Review的需求也不同。
公司体量和情况不同，对代码评审的需求也不同，所以在实践中，需要根据团队的实际情况进行调整。
- 代码只要能明显改进系统和改善系统的整体运行状况（功能完成性、可理解性、可维护性、可测试性···），即便不够完美，也应该批准
- 代码不能损害系统的整体质量
- 权衡项目进度和建议的重要性，适当放宽要求
- 紧急情况下，应该更加注重评审速度和代码的正确性(能否解决当前的紧急情况)
- 技术和数据高于意见和个人偏好
- 设计： 设计是否合理，是否适合当前系统
- 功能： 代码功能和业务功能是否一致，对用户和维护者是否友好
- 复杂性： 是否过度设计
- 测试： 测试代码是否正确有效
- 命名： 命名是否见名知意
- 注释： 注释的可读性，是否清晰有用？（不用写干了什么，而是写为什么这么写）
- 编码规范： 编码风格一致性
- 文档： 文档完备性
- 安全 保证系统安全
在做Code Review时，你需要注意以下：
- 代码设计良好。
- 代码功能对用户有用。
- 任何UI改动应当是深思熟虑过而且看起来不错的。
- 保证线程安全。
- 代码没有增加不必要的复杂性。
- 开发者没有写有些将来需要但现在不知道是否需要的东西。
- 代码有适当的单元测试。
- 测试逻辑设计良好。
- 开发者使用了清晰明了的命名。
- 注释清晰明了实用，通常解释清楚了为什么这么做，而不是做了啥。
- 代码又相应完善的文档。
- 代码风格符合规范。
- 持续优化团队开发新产品的速度，而不是优化单个开发人员编写代码的速度。个人开发的速度固然重要，但它没有团队整体的速度那么重要。
- 只有一种情况下，个人的速度要胜过团队速度：正在处理诸如编写代码之类的重要工作。
- 应当在一个工作日之内回应评审请求。
- 概述
- 编写目的
- 代码评审的定义
- 代码评审的价值和重要性
- 如何评审
- 参考资料 评审几种级别：1）可编译，2）可运行，3）可测试，4）可读，5）可维护，6）可重用。