https://www.jianshu.com/p/6324361d1ab1
Code Review需要注意什么？
- 完整性检查（Completeness）
- 代码是否完全实现了设计文档中提出的功能需求
- 代码是否已按照设计文档进行了集成和Debug
- 代码是否已创建了需要的数据库,包括正确的初始化数据
- 代码中是否存在任何没有定义或没有引用到的变量、常数或数据类型
- 一致性检查（Consistency）
- 代码的逻辑是否符合设计文档
- 代码中使用的格式、符号、结构等风格是否保持一致
- 正确性检查（Correctness）
- 所有的变量都被正确定义和使用
- 所有的注释都是准确的
- 所有的程序调用都使用了正确的参数个数
- 可修改性检查（Modifiability）
- 代码涉及到的常量是否易于修改(如使用配置、定义为类常量、使用专门的常量类等)
- 代码是否只有一个出口和一个入口（严重的异常处理除外）
- 健壮性检查（Robustness）
- 可理解性检查（Understandability）
- 注释是否足够清晰的描述每个子程序
- 是否使用到不明确或不必要的复杂代码，它们是否被清楚的注释
- 使用一些统一的格式化技巧（如缩进、空白等）用来增强代码的清晰度
- 是否在定义命名规则时采用了便于记忆，反映类型等方法
- 每个变量都定义了合法的取值范围
- 代码中的算法是否符合开发文档中描述的数学模型
- 可验证性检查(Verifiability)
3、性能方面检查项
- 对hashtable,vector等集合类数据结构的选择和设置是否合适
- 有无滥用String对象的现象
- 是否采用通用的线程池、对象池模块等cache技术以提高性能
- I/O方面是否使用了合适的类或采用良好的方法以提高性能（如减少序列化，使用buffer类封装流等）
- 同步方法的使用是否得当,是否过度使用
4、数据库处理方面
- 数据库资源是否正常关闭和释放
- 数据库访问模块是否正确封装，便于管理和提高性能
- 是否采用合适的事务隔离级别
- 资源泄漏处理方面检查项 cursor
5、通讯方面检查项
- socket通讯是否存在长期阻塞问题
6、重复代码
7、其他
- 一次评审量要低于 200–400 行代码缺陷密度 就是每 1000 行代码之中所发现的错误（bug）数
这里写图片描述 - 每小时低于 300–500 LOC 检查率的目标
这里写图片描述 - 花足够的时间进行适当缓慢的评审，但是不要超过 60-90 分钟
但反过来说，评审代码所花的时间不得低于五分钟，就算代码只有一行也是如此。通常来说，单行的代码也会影响到整个的系统，所以花上五分钟时间去检查更改可能造成的结果是值得的 - 确定在评审开始之前代码开发者已经注释源代码了
这里写图片描述 - 使用检查表，因为它能极大地影响代码开发者和评审者的结果
另外一个有用的概念就是 个人检查表 。每个人一般都会犯 15-20 个错误（bug）。如果您注意到了一些典型的错误（bug），那么您就可以开发自己的个人检查表 - 确认缺陷得到了修复
作者：IT_xiao小巫
链接：https://www.jianshu.com/p/6324361d1ab1
来源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
若有收获，就点个赞吧
0 人点赞
