正视代码Review，养成良好的编程习惯

本文主要是介绍正视代码Review，养成良好的编程习惯，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

代码review是指在软件开发过程中，通过对源代码进行系统性检查来确认代码实现的质量保证机制

总而言之目的是查找系统缺陷，保证软件总体质量和提高开发者自身水平，使项目代码更加容易维护。

在代码提交之前如果有很多双眼睛盯着看可以发现bug，这是代码审查最广为人知的好处。（人们的确可以在代码审查中发现bug，但是这些bug大部分都是显而易见的小bug，开发者分分钟可以发现，而那些真正需要花时间发现的bug通常是在代码审查中发现的）
代码审查最大的好处是纯社会性的。（如果你编程的时候知道你的同事将要看你的代码，你的编程方式会不一样，你的代码会写的更整洁，注释更加清楚，组织得更好。因为你知道其他人会看你的代码，他们的意见是你需要关注的。如果没有审查，你虽然知道人们最后会去看你的代码，但是那样不会给你一种紧迫感，也不会给你同样的个人评判的感觉。）
还有一个更大的好处就是代码审查可以传播知识。（在很多开发小组里，每个人都负责某一个核心组件，专注于自己的这一块，只要其他同事的模块不会破坏自己的代码就不会去关注，这种模式导致一个模块只有一个人熟悉对应的代码，如果一个人请教或者离职，其他人对他负责的模块将一无所知。如果采用代码审查，那么至少有两个人熟悉代码-作者和审查者。审查者知道的代码不如作者多，但是他们都熟悉代码的设计和结构，这意义重大）

重视代码review
(Code Review人员是否理解了Code Review的概念和Code Review将做什么如果做Code Review的人员不能理解Code Review对项目成败和代码质量的重要程度，他们的做法可能就会是应付了事。)
代码是否已经正确的build，build的目的使得代码已经不存在基本语法错误
(我们总不希望高级开发人员或是主管将时间浪费在检查连编译都通不过的代码上吧。 )
代码执行时功能是否正确
(Code Review人员也不负责检查代码的功能是否正确，也就是说，需要复查的代码必须由开发人员或质量人员负责该代码的功能的正确性。 )
开发人员是否对代码做了单元测试
(这一点也是为了保证Code Review前一些语法和功能问题已经得到解决，Code Review人员可以将精力集中在代码的质量上。 )

完整性检查（Completeness）
- 代码是否完全实现了设计文档中提出的功能需求
- 代码是否已按照设计文档进行了集成和Debug
- 代码是否已创建了需要的数据库,包括正确的初始化数据
- 代码中是否存在任何没有定义或没有引用到的变量、常数或数据类型
一致性检查（Consistency）
- 代码的逻辑是否符合设计文档
- 代码中使用的格式、符号、结构等风格是否保持一致
正确性检查（Correctness）
- 所有的变量都被正确定义和使用
- 所有的注释都是准确的
- 所有的程序调用都使用了正确的参数个数
可修改性检查（Modifiability）
- 代码涉及到的常量是否易于修改(如使用配置、定义为类常量、使用专门的常量类等)
- 代码是否只有一个出口和一个入口（严重的异常处理除外）
健壮性检查（Robustness）
可理解性检查（Understandability）
- 注释是否足够清晰的描述每个子程序
- 是否使用到不明确或不必要的复杂代码，它们是否被清楚的注释
- 使用一些统一的格式化技巧（如缩进、空白等）用来增强代码的清晰度
- 是否在定义命名规则时采用了便于记忆，反映类型等方法
- 每个变量都定义了合法的取值范围
- 代码中的算法是否符合开发文档中描述的数学模型
可验证性检查(Verifiability)
- 代码中的实现技术是否便于测试

1、编码规范方面检查项

2、面向对象设计方面检查项

- 类设计和抽象是否合适

- 是否符合面向接口编程的思想

- 是否采用合适的设计模式

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），那么您就可以开发自己的个人检查表
确认缺陷得到了修复