【转】代码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的进步和系统开发质量的提高之根本。