公司内部有Code Review,感觉不得要领，在网上找了一份CheckList用来作为Review的标准。原文链接
0.Code Review的好处
0.1 知识传播
相信很多人第一次提交Code Review都有类似的经历：短短几百行代码，却被提了密密麻麻几十条 comments，更新了十多次代码，才最终被accept。其实当代码被accept，提交代码的工程师通过这次review就学习到了代码规范和很多好的实践。同时，通过review更资深工程师的代码，年轻的工程师也更直观地学习架构和编码；另外，工程师之间也可以通过review代码来共享项目知识，看代码实现在绝大多数时候是了解项目的最好方式。
0.2 增进代码质量
这点也很容易理解，有经验的工程师可以在架构设计、代码细节等各个方面帮助到初学者。不同工程师也会有知识盲点，互相review进步也很快。另外，被review的代码质量更高还有一个很多人注意不到的心理因素：在状态不佳的时候，工程师难免会匆忙写些“潦草”的代码，但是当你知道自己的代码会被review的工程师提交comment打回来，自然会更仔细些 : -)
0.3 找出潜在的 bug
这是大部分团队进行Code Review的目的。就像上面提到的，Code Review在这方面效果不错。其实我认为大部分代码bug应该由单元测试，功能测试，性能测试和回归测试来保障。不过由于静态分析不理解业务，另外有些bug在测试中并不容易复现，这两种情况下，经验丰富的工程师来review代码就尤其重要了
1.Code Review的前提
进入Code Review需要检查的条件如下：
1.1 Code Review人员是否理解了Code Review的概念和Code Review将做什么。
如果做Code Review的人员不能理解Code Review对项目成败和代码质量的重要程度，他们的做法可能就会是应付了事。
1.2 代码是否已经正确的build，build的目的使得代码已经不存在基本语法错误
我们总不希望高级开发人员或是主管将时间浪费在检查连编译都通不过的代码上吧。
1.3 代码执行时功能是否正确
Code Review人员也不负责检查代码的功能是否正确，也就是说，需要复查的代码必须由开发人员或质量人员负责该代码的功能的正确性。
1.4 Review人员是否理解了代码
做复查的人员需要对该代码有一个基本的了解，其功能是什么，是哪一方面的代码，涉及到数据库或是通讯，这样才能采取针对性的检查
1.5 开发人员是否对代码做了单元测试
这一点也是为了保证Code Review前一些语法和功能问题已经得到解决，Code Review人员可以将精力集中在代码的质量上。
2.Code Review 需要做什么
Code Review主要检查代码中是否存在以下方面问题：
代码的一致性、编码风格、代码的安全问题、代码冗余、是否正确设计以满足需求（性能、功能）等等
2.1 完整性检查（Completeness）
代码是否完全实现了设计文档中提出的功能需求
代码是否已按照设计文档进行了集成和Debug
代码是否已创建了需要的数据库，包括正确的初始化数据
代码中是否存在任何没有定义或没有引用到的变量、常数或数据类型
2.2 一致性检查（Consistency）
代码的逻辑是否符合设计文档
代码中使用的格式、符号、结构等风格是否保持一致
2.3 正确性检查（Correctness）
代码是否符合制定的标准
所有的变量都被正确定义和使用
所有的注释都是准确的
所有的程序调用都使用了正确的参数个数
2.4 可修改性检查（Modifiability）
代码涉及到的常量是否易于修改(如使用配置、定义为类常量、使用专门的常量类等)
代码中是否包含了交叉说明或数据字典，以描述程序是如何对变量和常量进行访问的
代码是否只有一个出口和一个入口（严重的异常处理除外）
2.5 可预测性检查（Predictability）
代码所用的开发语言是否具有定义良好的语法和语义
是否代码避免了依赖于开发语言缺省提供的功能
代码是否无意中陷入了死循环
代码是否是否避免了无穷递归
2.6 健壮性检查（Robustness）
代码是否采取措施避免运行时错误（如数组边界溢出、被零除、值越界、堆栈溢出等）
Error handling是否都处理完毕(例如空指针检查、应该catch哪些异常)
2.7 结构性检查（Structuredness）
程序的每个功能是否都作为一个可辩识的代码块存在
循环是否只有一个入口
2.8 可追溯性检查（Traceability）
代码是否对每个程序进行了唯一标识
是否有一个交叉引用的框架可以用来在代码和开发文档之间相互对应
代码是否包括一个修订历史记录，记录中对代码的修改和原因都有记录
是否所有的安全功能都有标识
2.9 可理解性检查（Understandability）
注释是否足够清晰的描述每个子程序
是否使用到不明确或不必要的复杂代码，它们是否被清楚的注释
使用一些统一的格式化技巧（如缩进、空白等）用来增强代码的清晰度
是否在定义命名规则时采用了便于记忆，反映类型等方法
每个变量都定义了合法的取值范围
代码中的算法是否符合开发文档中描述的数学模型
2.10可验证性检查(Verifiability)
代码中的实现技术是否便于测试
2.11 效率
代码效率包括读代码的效率与执行代码的效率，如何尽量减小算法复杂度、减少临时对象等等。
番外1
##code review常规项目
代码是否符合公共的编程规范？包括变量名，函数名，缩进，格式和注释。
是否有被注释掉的代码或者调试代码？
代码书写是否简单明了？
是否存在多余的或是重复的代码？
代码是否尽可能的模块化？
循环是否设置了长度和正确的终止条件？
是否有可以被库函数替代的代码？
是否进行异常处理？
是否有更好的处理方法？
有没有遗漏任何corner case?
文件组织，函数是不是应该放到其他lib或库中？
是否应该使用继承保持风格统一?
##线程是否安全？
是否可以使用更好的设计模式？
扩展性是否良好？
番外2
Code Review Checklist
网友评论