code review通用流程规范

code review通用流程规范

code review通用流程规范... 1

1完整性检查... 2

1.1代码是否完全实现了设计文档中提出的功能需求... 2

1.2代码是否已按照设计文档进行了集成和Debug. 2

1.3 代码是否已创建了需要的数据库，包括正确的初始化数据... 2

1.4代码中是否存在任何没有定义或没有引用到的变量、常数或数据类型... 3

2 一致性检查... 3

2.1代码的逻辑是否符合设计文档... 3

2.2代码中使用的格式、符号、结构等风格是否保持一致... 3

2.3 系统交互合理性... 3

3 正确性检查... 3

3.1代码是否符合制定的标准... 3

3.2所有的变量都被正确定义和使用... 3

3.3所有的注释都是准确的... 3

3.4所有的程序调用都使用了正确的参数个数... 4

3.5 方法的边界条件有没有考虑等... 4

4 可修改性检查... 4

4.1代码涉及到的常量是否易于修改(如使用配置、定义为类常量、使用专门的常量类等)4

4.2代码中是否包含了交叉说明或数据字典，以描述程序是如何对变量和常量进行访问的... 4

4.3代码是否只有一个出口和一个入口（严重的异常处理除外）... 4

5 可预测性检查... 4

5.1代码所用的开发语言是否具有定义良好的语法和语义... 4

5.2是否代码避免了依赖于开发语言缺省提供的功能... 4

5.3代码是否无意中陷入了死循环... 5

5.4代码是否是否避免了无穷递归... 5

6 健壮性检查... 5

6.1代码是否采取措施避免运行时错误（如数组边界溢出、被零除、值越界、堆栈溢出等）... 5

7 结构性检查... 5

7.1程序的每个功能是否都作为一个可辩识的代码块存在... 5

7.2循环是否只有一个入口... 5

8 可追溯性检查... 5

8.1代码是否对每个程序进行了唯一标识... 5

8.2是否有一个交叉引用的框架可以用来在代码和开发文档之间相互对应... 6

8.3代码是否包括一个修订历史记录，记录中对代码的修改和原因都有记录... 6

8.4是否所有的安全功能都有标识... 6

9 可理解性检查... 6

9.1 注释是否足够清晰的描述每个子程序... 6

9.2是否使用到不明确或不必要的复杂代码，它们是否被清楚的注释... 6

9.3使用一些统一的格式化技巧（如缩进、空白等）用来增强代码的清晰度... 6

9.4是否在定义命名规则时采用了便于记忆，反映类型等方法... 7

9.5每个变量都定义了合法的取值范围... 7

9.6代码中的算法是否符合开发文档中描述的数学模型... 7

9.7 是否存在大量重复代码... 7

10可验证性检查... 7

10.1代码中的实现技术是否便于测试... 7

11  扩展性检查... 7

12. 性能开销检查... 7

附录：... 8

问题报告模板... 8

 

1完整性检查

1.1代码是否完全实现了设计文档中提出的功能需求

如果存在代码和设计有出入的地方需要问询为什么要变动，因为这些变动有可能是出于开发者在真正设计代码时候的深入考虑，或者是由于一时大意出现偏差

 

1.2代码是否已按照设计文档进行了集成和Debug

 

1.3 代码是否已创建了需要的数据库，包括正确的初始化数据

数据库字段的设计，数据库的设计是对实际业务的映射，我们要保证每一个字段的出现都反应实际业务并且经过合理性的验证，比如设计table1的时候A字段在table2中已经出现，并且A和B表有相应的关联，那么要注意A字段对于table1的冗余是否有合理性，如果没有合理的说服性可以去掉A，而节省对A字段的维护成本（存储空间，更新操作等）

 

1.4代码中是否存在任何没有定义或没有引用到的变量、常数或数据类型

 

2 一致性检查

2.1代码的逻辑是否符合设计文档

业务流程是否按照详细设计的流程走，不要出现原本是先A流程后B流程而设计的时候出现先B后A，或者丢失流程。

2.2代码中使用的格式、符号、结构等风格是否保持一致

 

2.3 系统交互合理性

系统交互是否合理，比如在代码设计的时候没有关注考虑系统交互的顺序而造成有些信息不能获取到；比如获取支付方式的费率信息必须要等待支付的时候才能拿到，那么获取这些信息就应该放在pay_trans的时候而不是create_trans，大多数这种问题其实都是详细设计时出现的，代码评审阶段比较少见。

3 正确性检查

3.1代码是否符合制定的标准

 

3.2所有的变量都被正确定义和使用

 

3.3所有的注释都是准确的

 

3.4所有的程序调用都使用了正确的参数个数

某些传入参数是否合理：判断某些接口的参数输入是否是冗余的，比如输入A字段可以满足A接口里面的所有操作，那么多输入一个B就冗余的。

 

3.5 方法的边界条件有没有考虑等

4 可修改性检查

4.1代码涉及到的常量是否易于修改(如使用配置、定义为类常量、使用专门的常量类等)

 

4.2代码中是否包含了交叉说明或数据字典，以描述程序是如何对变量和常量进行访问的

 

4.3代码是否只有一个出口和一个入口（严重的异常处理除外）

 

5 可预测性检查

5.1代码所用的开发语言是否具有定义良好的语法和语义

 

5.2是否代码避免了依赖于开发语言缺省提供的功能

 

5.3代码是否无意中陷入了死循环

某些判断是否合理，比如某些参数的输入金额是否可以为0的判断等等。

5.4代码是否是否避免了无穷递归

 

6 健壮性检查

6.1代码是否采取措施避免运行时错误（如数组边界溢出、被零除、值越界、堆栈溢出等）

是否有异常处理机制，一个好的代码设计应该考虑各种异常并对相应的异常做出合理的处理，比如接口的可重入，当代码检测到有重入的这种情况，怎样去做这种异常处理使得调用方能捕捉的这些异常而进行后面的处理。

7 结构性检查

7.1程序的每个功能是否都作为一个可辩识的代码块存在

 

7.2循环是否只有一个入口

 

8 可追溯性检查

8.1代码是否对每个程序进行了唯一标识

 

8.2是否有一个交叉引用的框架可以用来在代码和开发文档之间相互对应

 

8.3代码是否包括一个修订历史记录，记录中对代码的修改和原因都有记录

 

8.4是否所有的安全功能都有标识

 

9 可理解性检查

9.1 注释是否足够清晰的描述每个子程序

关注代码注释：我们在编写函数和进行逻辑判断的时候最好要标注一下这个函数或者这段判断是用来做什么的；做了这种注释的好处，一来当别人阅读这段代码的时候看到你的注释以后就会根据你的思路快速理解代码，甚至不阅读直接跳过；二来防止自己由于长时间不阅读代码而忘记这段代码的用途。

9.2是否使用到不明确或不必要的复杂代码，它们是否被清楚的注释

关注繁琐的逻辑：如果一个简单的功能却对应大篇幅的代码，要考虑一下是不是有比较简单的实现方式，因为过于复杂的代码会给后来者的维护带来麻烦；如果没有简略的办法，一定要把注释写好。

9.3使用一些统一的格式化技巧（如缩进、空白等）用来增强代码的清晰度

 

9.4是否在定义命名规则时采用了便于记忆，反映类型等方法

关注命名规范：虽然我们有自己的编码规范，但是这种规范只是限制了使用驼峰命名法还是其他命名法；而好的命名风格应该是看到变量或者函数名字就能“望文生义”，毕竟我们不能把自己写的所有代码都做注释。

9.5每个变量都定义了合法的取值范围

 

9.6代码中的算法是否符合开发文档中描述的数学模型

9.7 是否存在大量重复代码

关注重复代码：如果出现大量的重复性代码，要考虑将这些代码抽象出公用函数，以减少代码量并增强代码可读性。

 

10可验证性检查

10.1代码中的实现技术是否便于测试

 

11 扩展性检查

我们的业务在不断的发展，每一个项目设计都会影响后续业务的拓展，一个好的设计应该考虑到后续业务的发展，而尽量避免定制化的设计。

 

12. 性能开销检查

当我们设计代码的时候如果能用上系统提供的函数那么最好不要自己去写，比如自己实现一个链表的时候是否可以想到用系统库提供的list_head以确保链表结构的正确性；

某些设计如果能套用设计模式会让设计更加美观也让阅读者更加明了；出于对系统性能的考量，我们要关注编写代码对系统的开销，包括使用的算法是否合理，以及对某些比较耗时的操作比如数据库的操作要加以关注。

考虑大数据量、大并发量下的性能下sql是否有问题？是否会有内存泄露？死锁等

 

 

附录：

问题报告模板

示例如下：