【转】代码review注意事项

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

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

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

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

最近在看《大秦帝国》,其中有个部分,是讲卫鞅的老师公孙座在临死之前,将卫鞅推荐给魏王,魏王拒绝不用此人,原因是魏王觉得卫鞅之时中庶子小吏,无名无地位,也非师出名门,注:庞涓是师从鬼谷子的,故为重用。公孙座便建议魏王杀了卫鞅,以尽为国之职,但在弥留之际,公孙座还是叫卫鞅逃跑,以尽师徒之议。这一段,让我深为感动,古人尚且能够做到老师推荐弟子,而当今在这个知识无国界的当代,我们是否在分享知识方面比古人做得更好呢?题外话,扯远了。言归正传!

个人认为对于一个Team来讲,代码是公开的,同时,还需要定期地做代码Review,帮助每一个Team Member对于编写代码的能力的提高。

 

如果把一个大的系统比作为一个建筑物的话,那么系统架构就如同钢筋结构,而每一个行代码则是一砖一瓦,架构搭好了,砖瓦不行,系统还是不行。

 

做代码Review主要考虑:编码的规范、系统架构相关的规范、文档的规范和业务逻辑的一致(即能否满足业务需求)。有了这些,系统的整个开发的质量和代码的质量会上一个新的台阶。

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

(1)是否符合代码格式化标准(主要参考Sun代码格式化标准)
(2)是否有多余的import项 (如果多余,会耗费多余的资源)
(3)是否定义了多余的field 
(4)是否定义了多余的本地变量 
(5)是否定义了多余的私有方法 
(6)是否有可以重构的逻辑重复的代码 (如有,需要重构)
(7)方法/成员的public/private/static/final属性是否合理 
(8)调用静态常量是否使用类/接口名 
(9)是否所有实现了java.io.Serializable接口的类都有serialVersionUID (这个感觉很重要,曾经碰到过这样的问题,中间件服务器上的类和本地的类的编译的版本不一样,则报错,实现了Serializable则无此问题)
(10)类/接口/变量/参数名,命名是否规范 
(11)所有的if,for,while块内容是否都用{} 
(12)是否有功能复杂的语句 
(13)将url,文件路径等写死在程序里(硬编码,应用静态常量或Properties文件) 
(14)将中文写在程序里 (应用Properties)
(15)系统中使用到的非描述性字符串是否使用常量 
(16)系统中使用到的数字是否使用常量 
(17)常量是否有详细的注释 
(18)程序中是否存在System.out,System.err及Throwable.printStackTrace() 
(19)系统中打开的流/文件/连接等是否保证能正常并及时关闭 
(20)在输出日志时,低级别的输出一定要判断isXXEnabled 
(21)在生产环境中输出大量调试日志 
(22)注意使用对象的线程安全 
(23)大规模的string组装 
(24)递归方法的使用---尽量避免 
(25)本地线程对象是否导致memory leak 
(26)应用代码中严格禁止硬转 编码,只能在框架里做统一的处理 
(27)是否编译过正则表达式,是否有大规模的表达式 
(28)在出错路径上是否所有的资源(数据库连接,文件锁等)和引用都已经释放 
(29)在保证线程安全的同时,要注意避免过度使用同步,导致性能降低 
(30)同步对象上的锁是否按相同的顺序获得和释放以避免死锁,注意错误处理代码 
(31)所有的循环是否优化 
(32)如果调用了阻塞方法,是否考虑了保证性能的措施 
(33)方法(函数)方面检查安全

----代码是无私的,互相提高,互相进步,才是整个Team的进步和系统开发质量的提高之根本。

阅读更多
个人分类: JAVA
想对作者说点什么? 我来说一句

没有更多推荐了,返回首页

加入CSDN,享受更精准的内容推荐,与500万程序员共同成长!
关闭
关闭