代码review理解

极限编程里提到结对编程和代码Review,凡是稍微懂编程的人看了都会赞成。这也体现了代码Review的重要性和必要性。但是，在实际的执行过程中，代码Review往往很难得到很好的执行。主要原因可能包含以下几点：

(1) 对自己编写的代码的不够自信，害怕别人找到问题；

(2) 对于自己的编写的代码过于自信，不觉得需要代码Review；

(3) 对于自己的代码过于封闭，不愿意与别人分享代码编写经验，害怕教会徒弟打师傅；

个人认为对于一个Team来讲，代码是公开的，同时，还需要定期地做代码Review，帮助每一个Team Member对于编写代码的能力的提高。 如果把一个大的系统比作为一个建筑物的话，那么系统架构就如同钢筋结构，而每一个行代码则是一砖一瓦，架构搭好了，砖瓦不行，系统还是不行。 做代码Review主要考虑：编码的规范、系统架构相关的规范、文档的规范和业务逻辑的一致（即能否满足业务需求）。有了这些，系统的整个开发的质量和代码的质量会上一个新的台阶。

从编码的规范方面，经过查询资料，总结了下列注意事项：

（１）是否符合代码格式化标准（主要参考Sun代码格式化标准）

（２）是否有多余的import项 （如果多余，会耗费多余的资源）

（３）是否定义了多余的field

（４）是否定义了多余的本地变量

（５）是否定义了多余的私有方法

（６）是否有可以重构的逻辑重复的代码 （如有，需要重构）

（７）方法／成员的public/private/static/final属性是否合理

（８）调用静态常量是否使用类／接口名

（９）是否所有实现了java.io.Serializable接口的类都有serialVersionUID （这个感觉很重要，曾经碰到过这样的问题，中间件服务器上的类和本地的类的编译的版本不一样，则报错，实现了Serializable则无此问题）

（１０）类／接口／变量／参数名，命名是否规范

（１１）所有的if,for,while块内容是否都用{}

（１２）是否有功能复杂的语句

（１３）将url，文件路径等写死在程序里（硬编码，应用静态常量或Properties文件）

（１４）将中文写在程序里 （应用Properties）

（１５）系统中使用到的非描述性字符串是否使用常量

（１６）系统中使用到的数字是否使用常量

（１７）常量是否有详细的注释

（１８）程序中是否存在System.out,System.err及Throwable.printStackTrace()

（１９）系统中打开的流／文件／连接等是否保证能正常并及时关闭

（２０）在输出日志时，低级别的输出一定要判断isXXEnabled

（２１）在生产环境中输出大量调试日志

（２２）注意使用对象的线程安全

（２３）大规模的string组装

（２４）递归方法的使用－－－尽量避免

（２５）本地线程对象是否导致memory leak

（２６）应用代码中严格禁止硬转 编码，只能在框架里做统一的处理

（２７）是否编译过正则表达式,是否有大规模的表达式

（２８）在出错路径上是否所有的资源（数据库连接，文件锁等）和引用都已经释放

（２９）在保证线程安全的同时，要注意避免过度使用同步，导致性能降低

（３０）同步对象上的锁是否按相同的顺序获得和释放以避免死锁，注意错误处理代码

（３１）所有的循环是否优化

（３２）如果调用了阻塞方法，是否考虑了保证性能的措施

（３３）方法（函数）方面检查安全 ----代码是无私的，互相提高，互相进步，才是整个Team的进步和系统开发质量的提高之根本。