重构,小步进行曲
2010-11-13 16:00 横刀天笑 阅读(2434) 评论(22) 编辑 收藏 举报对于重构的重要性相信不需要再强调。在开发的过程中,随着代码的演进,需求的改变我们必须持续不断的对既有代码进行重构:重命名(以更精确地反映元素的职责),提取方法(用更具描述性的名字来归纳一段代码),提取基类(消除重复,提高抽象层次)等。如果我们只是一味的去开发新的代码,而对老代码不闻不问,以为只要它能工作就够了,总有一天我们会在这个上面栽跟头的,设计会慢慢的走向腐化。
好了,本文并不是想强调重构有多重要,因为那不用强调。我想说的是:重构,是小步进行曲。
在阅读Martin Fowler的《重构》时,几次都没有将全书读完,前面几章倒是读的大呼过瘾,不过后面的重构目录让我心生困惑:重构需要这么小的步骤么?连一个重命名都需要这么繁琐的进行。曾几时我还小人的想:老马是不是才思枯竭,没有什么写的了,但又不想出版这么一本薄薄的册子,如是故意弄的这么小步伐,凑篇幅。
不过现在我越来越觉得小步进行的重要性,如果我不能小步的重构一块代码,我甚至都不会去重构它。
在最近的结对编程中,经常碰到这样的场景:
我:这段代码太长了,我们重构一下吧
Partner:好
我:(鼠标键盘一起上了)
Partner:你这样不对(然后抢过键盘)
(实际上我们仅仅是为了想建立一个新类,然后将这个类里的一些方法移动到新的类里,这样原有类的代码就变短了,职责也清晰了,而新类也有很清晰的职责。)
我:(我的做法是,新建一个类,然后将方法copy过去)
Partner:(而搭档的做法是,新建一个类NewClass,然后在原有类里声明一个这个类的字段newClass,然后将要抽离的方法method的方法体再抽取一个方法internalMethod,然后将新方法internalMethod移动到NewClass中,这样method方法就变成newClass.internalMethod,而method的调用者没有任何变化,而在这中间的每一步都运行一下单元测试)
原有类:
1: public class OldClass{
2: //many other code
3: public void method(){
4: //many code
5: }
6: //many other code
7: }
第一步:
1: public class NewClass{
2: }
3:
4: public class OldClass{
5: private NewClass newClass = new NewClass();
6: //many other code
7: public void method(){
8: //many code
9: }
10: //many other code
11: }
第二步:
1: public class NewClass{
2: }
3:
4: public class OldClass{
5: private NewClass newClass = new NewClass();
6: //many other code
7:
8: //原方法继续在这里,保证测试仍然可以通过
9: public void method(){
10: internalMethod();
11: }
12: //many other code
13:
14: //使用IDE重构工具提取方法
15: public void internalMethod(){
16: //many code
17: }
18: }
第三步:
1: public class NewClass{
2: //使用IDE 移动方法重构
3: public void internalMethod(){
4: //many code
5: }
6: }
7:
8: public class OldClass{
9: private NewClass newClass = new NewClass();
10: //many other code
11:
12: //原方法继续在这里,保证测试仍然可以通过
13: public void method(){
14: newClass.internalMethod();
15: }
16: //many other code
17: }
在经过上面的三步后,移动方法重构就基本完成了,然后再进行一些重命名等工作,将代码重构的更好。
虽然我嘴上没说,但对这种小步进行的方式却很不以为然,我觉得这完全是在浪费时间,我们有能力控制重构过程的小混乱,然后让它恢复秩序。
日子就这么一天天的过去了,终于有一天,因为大部分人去参加了公司的会议,没有新的故事可以做了,如是我决定做一下有个模块的重构工作,为了确保万无一失,我还花了很长时间来绘制重构完成后应该有的类阶层次结构图,然后贴在电脑屏幕旁,然后还做了一个简单的计划,我应该从哪里入手,怎么做怎么做之类的。唯独我没有做到的是小步进行,当时只是为了能尽快的达到结构图的目的,大步进行,我甚至没有借助IDE提供的工具,靠人肉重构(如果你也在使用这种方式,请千万不要继续下去了,这是重构大忌)。我不仅忘记了使用IDE提供的重构工具,甚至还忘记了分步频繁提交的准则,实际上我一开始,这次重构之旅注定要失败。到了下午的时候,我看到测试类里满眼的红色标记(编译不通过),我都焦头烂额了,但是我甚至还一错再错将单元测试暂时屏蔽,以为我可以在重构完成后再回过头来修理测试。最后,我在没有测试的情况下,继续摸黑前行。最后,好不容易将功能代码能编译通过了,我舒了一口气,然后敲了几个命令编译-部署,去倒了一杯咖啡,我回来的时候刷新了一下页面,给了我当头一击,一个刺眼的错误页面展现在眼前。因为我已经走的太远,我都不知道如何去调查错误,这个错误是从几何时引入的。没办法,在下班前的一刻我将整天的工作全部rollback。
在日后的结对编程过程中,我仔细的观察了同事的重构过程,每一步都那么小,每一次都保证测试通过然后再进行下一步重构,每一次有意义的重构都赶紧提交代码,我明白了老马的用心良苦:
1、如果我们每一步都很小,我们就能在下次重构之前记住我们上一次干了啥,重构完成之后,运行测试发现测试未通过,我们就能很容易的定位错误,修正错误。
2、如果每一步都很小,我们在修改功能代码后,我们也能很容易的演进测试,让测试反应当前的变化,这样测试就会与功能代码共同演进。
3、如果每一步都很小,我们在跑完测试后可以马上提交代码,当我们发现重构发生问题时,我们可以回退到上一步,而不至于像我那样将整天的工作全部回滚。
4、如果每一步都很小,我们就可以借助IDE对重构提供的支持来安全的进行,因为IDE对步骤太大的重构支持并不好。
如果你也在重构,请谨记小步进行,让你的每一步都是安全的。请不要厌烦《重构》中重构目录的罗嗦,因为那才是重构的精髓所在。