大约是工作三年后,职业倦怠毫无征兆的袭击了我,我莫名的感到:这一辈子就这样了,每天的工作就是写相同的代码,要命的是,自己在一个领域越精通,别人就越希望自己写同样的模块——再快一点。使我渡过这段时光的,是一些编程行业的老书,对于一个原本追求时髦技术的程序员来说,这样的反转令自己也很惊讶,其中就有这本《重构》,多年后,再次捧读,希望自己如《黑客帝国》里的neo,回到源码,去理解为何重构即不是传说中的银弹,却又如此重要。本篇为第一部分,先来说说看待重构的三心。
抛掉对重构的敬畏之心
1. 重构给出了具体的操作方法。
重构不是建立在空中的构建思想,而是从实践中归纳出来的操作手册。比如书中提到的要点之一:
事不过三,三要重构。
这条规则给出了重构时机的具体判断方法:一个值,一段代码,相同的功能,如果重复出现了 两次以上,就要提取为宏,变量,方法,或模块,以方便重用。这不是建议,从代码质量来说,这是要求,也是开发者从小工到专家的必由之路,事实上,除此之外,我不知道还有别的编写代码的方法。
2. 重构早已在开发者身边。
几乎所有开发工具(Eclipse、Xcode...)都内置重构工具,他们的使用与代码编辑器一样简单。
如果你是一名iOS开发者,请参阅Xcode8 五分钟重构起步
要对重构有耐心
由于重构不改变程序的外在表现,换而言之,即没有加入任何新功能,因此项目经理和老板不会主动要求开发者重构,甚至开发者提出时,会招来反对:这个项目还剩一个星期,还有N个需求未实现,现在你请求花费两天时间,什么都不做。开发者几乎都承担不了这样的压力,但是,比延误工期更严重的是,一个臃肿的,不易修改的项目,最终将面临添加需求困难,运行效率低下,以致达不到可用的性能,项目被砍掉,失败几乎不可避免。
那么作为开发者,应该怎么处理这个矛盾呢?一个可行的方法是,把重构当做开发的一部分,一边开发一边重构,先快速的堆叠代码,实现功能,然后在功能不变的基础上(写好单元测试),逐步重构。
对于吹嘘重构有戒心
不要对别人吹嘘重构
重构是一系列技法,就如一个优秀木匠不会吹嘘自己的刀法一样,他表现自己的,永远是作品,开发者的作品就是程序,可扩展,少改动,高效,稳健的程序,如果团队里有人说:我现在不重构就没法写代码。大概他就真的只是不会写代码而已。
本人面试过一些刚毕业的开发者,在最后的提问环节,他提出的问题是:你们用什么开发环境?接着他还进一步强调自己一定要使用**Source Insight
**(一种Windows平台流行的开发集成环境,基于代码语义管理代码),否则就无法写代码。当时我有点错愕,面对了解公司环境的宝贵机会,不问福利待遇,不问升职通道,却纠结一个开发工具。后来我发现,很多初学者(也包括我自己)对工具有种痴迷,这当然也不是坏事,但对自己用的开发工具夸夸其谈,只能说明开发者的眼界不够开阔,水平有局限。
当听到有人将重构奉为灵丹妙药,要格外小心,对此保持警惕。
有的技术领导人,动不动就说“下面我们进入重构阶段了”,仔细观察发现:每每他提出的时机,都是项目无法按时完成,某些功能实现不了时,公司领导还无法反驳,懂点技术的都明白重构的重要性。
那么,如何鉴别这种拿重构“忽悠”的行为呢?可以从以下几点:
- 检查要进入重构阶段的团队有没有写好对应的单元测试,这些测试是否自动测试。
- 是否为重构的项目新开版本管理库,如果是,那这不是重构,而是 重写。
- 最终确认最开始要求添加的需求是否被完成。
最后这点看起来有点二,但实际中常常发生,团队说,我开始重构啦,于是在大汗淋漓的两周后,团队只能保证“重构”后的项目勉强运行,项目进入了新阶段——bug修复,然后就再也没人提最初提出的新功能新需求了。
对于第一点,我们要理解重构的目标是
不改变代码外在行为的前提下,对代码进行修改,以改进程序的内部结构。
如何保证代码外在行为没有改变?就得靠单元测试了,这里将单元测试作为代码或重构的质量标准,谁也不想一个正在运行的程序,被修改后引入一堆Bug。
既然重构讲究的是小步修改
,每次改完后都要通过单元测试,那么第二点也很好理解了,重建版本库则意味着大段地搬移代码,这个过程很难保证代码质量,得到的很可能是 未经验证 的代码。
既然重构是一种编程手法,那么实践中的重构是如何操作的?该如何避免重写而**优雅地重构呢?
下篇将通过一个具体的例子,体会重构的过程,请关注我的简书。