1、 编码规范方面检查项
2、面向对象设计方面检查项
- 类设计和抽象是否合适
- 是否符合面向接口编程的思想
- 是否采用合适的设计模式
3、性能方面检查项
- 对hashtable,vector等集合类数据结构的选择和设置是否合适
- 有无滥用String对象的现象
- 是否采用通用的线程池、对象池模块等cache技术以提高性能
- I/O方面是否使用了合适的类或采用良好的方法以提高性能（如减少序列化，使用buffer类封装流等）
- 同步方法的使用是否得当,是否过度使用
4、数据库处理方面
- 数据库资源是否正常关闭和释放
- 数据库访问模块是否正确封装，便于管理和提高性能
- 是否采用合适的事务隔离级别
- 资源泄漏处理方面检查项 cursor
5、通讯方面检查项
- socket通讯是否存在长期阻塞问题
6、重复代码
7、其他
- 日志是否正常输出和控制
- 配置信息如何获得,是否有硬编码
Code Review需要注意什么？
完整性检查（Completeness）
代码是否完全实现了设计文档中提出的功能需求
代码是否已按照设计文档进行了集成和Debug
代码是否已创建了需要的数据库,包括正确的初始化数据
代码中是否存在任何没有定义或没有引用到的变量、常数或数据类型
一致性检查（Consistency）
代码的逻辑是否符合设计文档
代码中使用的格式、符号、结构等风格是否保持一致
正确性检查（Correctness）
所有的变量都被正确定义和使用
所有的注释都是准确的
所有的程序调用都使用了正确的参数个数
可修改性检查（Modifiability）
代码涉及到的常量是否易于修改(如使用配置、定义为类常量、使用专门的常量类等)
代码是否只有一个出口和一个入口（严重的异常处理除外）
健壮性检查（Robustness）
可理解性检查（Understandability）
注释是否足够清晰的描述每个子程序
是否使用到不明确或不必要的复杂代码，它们是否被清楚的注释
使用一些统一的格式化技巧（如缩进、空白等）用来增强代码的清晰度
是否在定义命名规则时采用了便于记忆，反映类型等方法
每个变量都定义了合法的取值范围
代码中的算法是否符合开发文档中描述的数学模型
可验证性检查(Verifiability)
代码中的实现技术是否便于测试
什么是codeDiff
字面含义是 代码差异比较，一种补充测试的手段。
1、为什么要做Codediff？
确认需求实现——QA和DEV一起梳理对需求的实现情况
评估影响范围——评估本次实现的代码改动对整体业务的影响范围 和 本次测试需要花费的成本
补充测试点——根据开发的代码逻辑需要补充未覆盖的测试点，以及回归点
提前发现代码错误——业务逻辑缺失、代码语法bug、异常处理bug等
加深技术实现理解——更深入的了解需求实现的方式能够加大测试的深度
2、Codediff 开始前准备？
熟悉产品需求
了解系统的整体架构
思考如果是你怎么实现（自己要根据对业务和系统的掌握有大概的实现思路，然后diff的时候和开发的思路进行碰撞，找问题）
准备相关的diff工具
具备代码、数据库等基本知识技能
3、什么时候做 Codediff？
首次介入测试，进行整体代码diff
提交bug修复版本，进行增量代码diff
发布前整体在diff一下关键点
4、如何执行Codediff？
开发给QA讲如何实现，QA提问、找茬（有目的的问）
比如：
遇到多线程时，线程安全吗？需要加锁处理吗？加锁使用后解锁没？多线程处理的地方会不会死锁？
方法中参数为空、null或长度为0怎么处理的，是否会发生空指针异常？
数据库链接的释放超时处理，执行过程中会不会锁表？
重复复制代码的逻辑及参数是否正确？
依赖外部的配置文件是否有备份？
5、达成目标
能够从内到外的完全把控整个项目的质量，发布上线能够更靠谱，出现问题也能及时找到问题
