大道化简,重构的艺术

这个题目貌似很大,有成为标题党人的嫌疑。其实我想说的是一些小事,就是我小时候经常去小渠里抓鱼。而抓鱼的方式也很简单,就是拿砖块,泥巴把小渠的两头堵起来,然后把中间的水舀出去。

 

软件为什么要重构?那是因为你感觉不够好。之所以感觉不够好,原因可能会很多。我想,最严重的一个可能就是设计混乱。设计混乱牵扯的方面很多,有依赖上的,有调用上的。也有根本实现不了目的,或者很难扩展。有很多人重构时候干脆就是把代码重写一遍,这种方式固然是好,但是成本太高。有时候无法接受重新梳理一遍代码的工作周期。

 

如何渐进地进行重构不得不摆在我们面前,而我没有珍惜,等............

 

对于依赖关系错误的重构是最为复杂的。这个复杂表现在必须重新理顺依赖关系,然后得出解决的方案。而代码调用让人头疼的地方,我想主要在于,没有重用和过度重用两种。扩展上的问题需要重新梳理业务规则,才能制定方案。

 

毛病很多,头疼医头,脚疼医脚,还真是麻烦。其实最根本的方法还在于学会养生,修炼内功。但路总要一条一条走,饭要一口一口吃啊。遇到这么多复杂的问题,还需要化繁为简。这里的化繁为简在我看来和我小时候抓鱼差不多,需要能够对大量的工作进行截断,一个阶段一个阶段地进行重构。这样才能达成渐进的重构目的。

 

如何进行工作量的切断,方法很多,但是有个根本的思想在于理清依赖。比如,类B调用了类A,那么B就对A产生了依赖。现在需要对A进行调整,那么就有很大可能对B的正常运行产生影响。如何能隔离B和A,这就需要给A定义规范。这也就是对A进行抽象,提炼出接口IA,那么不管你A怎么变,你符合IA接口的话,就可以给B使用。IA就像我抓鱼时候筑的那条小坝,虽然很小,却很能解决问题。

 

为什么这样可以解决问题?这就在于,任何一个消费者不会需要知道生产者的一切东西。那么只要把消费者需要的东西拿到就可以。MVC,MVP,三层架构都是大坝,是水渠的两边。而大半框架都是进行水平的划分,垂直的划分一般是以业务来划分。所以,如果软件已经实现了水平的划分,重构起来要轻松很多。那样只需要对业务的垂直划分进行逐步的改造。而如果水平划分没有做,那就惨了,理清头绪都不是件容易的事情。

 

事实上,重构远没有上面描述的那么简单。比如,以前项目中一直使用ExtJS进行界面的开发,现在想减小JS的比重,因此想改用JQuery+HTML+CSS来替换Ext的控件,那改造起来也是很复杂的事情。一次性全部更新的代价很高,出错机会很大,并且不容易形成规范。需要像国家改革一样形成试点,逐步推广。从这里也可以看出,重构不一定是OO的重构,除非你达到了一切皆是OO的境界。

posted @ 2010-02-10 19:10 Birdshover 阅读(...) 评论(...) 编辑 收藏