要资料 文章 文库 视频 Code iProcess 课程 认证 咨询 工具 火云堂 讲座吧   成长之路  
会员   
 
  
每天15篇文章
不仅获得谋生技能
更可以追随信仰
 
 
 
在代码重构中蜕变
 

2011-06-08 来源:网络

 

这几天,要对我半年前写的代码进行一些整理工作,在看代码时发现当时有很多地方写得不够好,俗称的有“坏味道”,呵呵,重构,必须的。

几年前通读过《重构,改善既有代码的设计》一书,虽然对各种重构模式或方法记忆有限,但精髓还是记住了:改代码而不改变软件的外在表现,循序渐进。

其实,重构是一个开发人员的基本工作内容,是在每天的开发过程中都要用到的。离开了重构和测试,代码质量是难有保障的。有人会说没有用到重构,其实最简单的例子,当你发现一个类中有几处用到了相同的代码,你把这几行代码提取到了一个私有函数中以供复用,这就是一次重构。所以说,别跟人炫耀你会重构,这是基本功。

好久没更新博客了,借此说说我的一点心得吧。

1.目的明确。代码是一种平衡的产物,很多地方都在保持着某种平衡,有功能与性能的平衡,有可靠性与可维护性的平衡等等,每一次动手,都要有一个目标,是想改进局部代码,还是想改进类结构,只有针对不同的目的才能实施不同的方法。

2.评估影响。改动前,最好能有个预估,对可能产生的影响做到心中有数,以免引起不必要的后果。在“坏味道”的代码中是很有可能牵一发而动全身的,要注意安全。如果只是对类的私有成员的改动,那通常影响的范围有限,如果涉及到对公有成员或保护成员的改动,那就要注意了,简单的评估方式是充分利用IDE的搜索、引用等功能,把引用过此成员的代码行全部找出来,看看影响的范围有多广,如果有些代码不在你的控制之内,那就要慎重考虑这个重构了。

3.慎改结构。设计人员或架构师在定义类结构的时候一定有他的综合考虑,在没有充分理解之前,请慎重吧。不要拿设计模式去套现有的结构,设计模式是个指导,如果学完设计模式还在硬用来套用,那这种僵化的思维还不如不学的好。所以,当想要做这样的重构时,请与你的设计师、架构师或有经验的同事协作,除非你自己就是设计师。

4.小步伐前进。每次改动尽量小,这样可以把影响限制到小范围。就像一个公式一样,如果同时改变其中的几个变量,那很难说是哪一个影响了结果,但如果一次只改变其中的一个,就可以确认其对结果的影响。尤其是当代码已经完成了用户需求,这时的重构只是为了让代码更好,切忌不要影响到已经得到用户确认的外在表现。

5.测试。无论你的开发是否是测试驱动,在重构时测试是保证代码正确的必要手段。修改-编译-测试,重复这个过程,直到达到目的。

当你花了几分钟或者几个礼拜,已经让代码大为清爽的时候,回过头来对比曾经的“坏味道”,我想,你会喜欢上代码的,重构会发生在你写下一行代码的时刻,变成了编码能力了。

少一行代码,就少一分出错的可能,别心疼你删除掉的代码,虽然那是你的心血,但那已经是历史,在重构代码中蜕变已经完成。



重构-使代码更简洁优美
Visitor Parttern
由表及里看模式
设计模式随笔系列
深入浅出设计模式-介绍
.NET中的设计模式
更多...   

相关培训课程

J2EE设计模式和性能调优
应用模式设计Java企业级应用
设计模式原理与应用
J2EE设计模式指南
单元测试+重构+设计模式
设计模式及其CSharp实现


某电力公司 设计模式原理
蓝拓扑 设计模式原理及应用
卫星导航 UML & OOAD
汤森路透研发中心 UML& OOAD
中达电通 设计模式原理
西门子 嵌入式设计模式
更多...   
 
 
 
 
 
每天2个文档/视频
扫描微信二维码订阅
订阅技术月刊
获得每月300个技术资源
 
 

关于我们 | 联系我们 | 京ICP备10020922号 京公海网安备110108001071号