重构,真的不是万灵丹
由上可见,我们至少可以得出一些简单结论:
1.重构,即使成功,它也不会带来什么直接效益,它只对开发者有用,而对项目的其它环节则没有;
2.重构带来的这些好处,说实在的,很多也只是出于开发者主观的看法:好懂、清晰都不是客观存在,难以界定和衡量,所以很多时候,很难证明这到底是真的对开发有帮助,还是只是开发者的个人臆想。
(关于MF等人总结出来的 一些“代码坏味道”以及相应的解决方法,后续将有专门论述,论述其中一些处理手法其实没有本质帮助——比如对含有大量局部变量和全局变量采用 方法提升为类 时,把局部变量提升为类的变量的办法,来减少提取后的新方法之间传递的参数减少,但实际上,这些变量仍然混杂在类内部,和一个小模块或者长函数中的全局变量没有太大区别,个人认为,这种转变,意义不大。)
3.要进行重构并不容易,比如准备完善的测试(尤其需要自动化测试)就是一道很大的关卡,此外,它需要重新投入相应的人力、时间、测试资源,也会对这些方面新添压力。
4.在真正了解项目代码,尤其是涉及的业务之前,进行重构是非常危险的,可能会摧毁已有的成果,这在职场和商业上是难以容忍的。
然而,很多时候,重构本身就有助于阅读和理解代码(或者说这是重构的一个目的,Martin Follwer 和 Michael Feather均表现出这种倾向)。
可以说这是一个典型的 鸡生蛋蛋生鸡的困境,这种困境唯一的解决方案就是,以其中一个为准绳,基准,而这一次,我们很可能必须接受 先理解再重构,因为,不理解就重构,风险更大,后果难以承担。
与此类似的,还有添加测试的困境。在Michael Feather的经典著作《修改代码的艺术》一书中提到,遗留代码可以定义为缺乏测试的代码,而为了给这些遗留代码添加测试,很多时候需要首先做重构,来解开难以测试的部分。
又是一个鸡生蛋蛋生鸡的困境。
好吧,不得不承认,这才是真正的软件世界。