您的位置:知识库 » 软件工程

代码重构

发布时间: 2010-05-29 11:53  阅读: 14260 次  推荐: 2   [收藏]  

  四、重构(Refactoring)与设计

  「重构」肩负一项特别任务:它和设计彼此互补。初学编程的时候,我埋头就写程序,浑浑噩噩地进行开发。然而很快我便发现,「事先设计」(upfront design)可以助我节省回头工的高昂成本。于是我很快加强这种「预先设计」风格。许多人都把设计看作软件开发的关键环节,而把编程(programming)看作只是机械式的低级劳动。他们认为设计就像画工程图而编码就像施工。但是你要知道,软件和真实器械有着很大的差异。软件的可塑性更强,而且完全是思想产品。正如Alistair Cockburn所说:『有了设计,我可以思考更快,但是其中充满小漏洞。』
  有一种观点认为:重构可以成为「预先设计」的替代品。这意思是你根本不必做任何设计,只管按照最初想法开始编码,让代码有效运作,然后再将它重构成型。事实上这种办法真的可行。我的确看过有人这么做,最后获得设计良好的软件。极限编程(Extreme Programming)【Beck, XP】 的支持者极力提倡这种办法。
  尽管如上所言,只运用重构也能收到效果,但这并不是最有效的途径。是的,即使极限编程(Extreme Programming)爱好者也会进行预先设计。他们会使用CRC卡或类似的东西来检验各种不同想法,然后才得到第一个可被接受的解决方案,然后才能开始编码,然后才能重构。关键在于:重构改变了「预先设计」的角色。如果没有重构,你就必须保证「预先设计」正确无误,这个压力太大了。这意味如果将来需要对原始设计做任何修改,代价都将非常高昂。因此你需要把更多时间和精力放在预先设计上,以避免日后修改。
  如果你选择重构,问题的重点就转变了。你仍然做预先设计,但是不必一定找出正确的解决方案。此刻的你只需要得到一个足够合理的解决方案就够了。你很肯定地知道,在实现这个初始解决方案的时候,你对问题的理解也会逐渐加深,你可能会察觉最佳解决方案和你当初设想的有些不同。只要有重构这项武器在手,就不成问题,因为重构让日后的修改成本不再高昂。
  这种转变导致一个重要结果:软件设计朝向简化前进了一大步。过去未曾运用重构时,我总是力求得到灵活的解决方案。任何一个需求都让我提心吊胆地猜疑:在系统寿命期间,这个需求会导致怎样的变化?由于变更设计的代价非常高昂,所以我希望建造一个足够灵活、足够强固的解决方案,希望它能承受我所能预见的所有需求变化。问题在于:要建造一个灵活的解决方案,所需的成本难以估算。灵活的解决方案比简单的解决方案复杂许多,所以最终得到的软件通常也会更难维护 — 虽然它在我预先设想的方向上,你也必须理解如何修改设计。如果变化只出现在一两个地方,那不算大问题。然而变化其实可能出现在系统各处。如果在所有可能的变化出现地点都建立起灵活性,整个系统的复杂度和维护难度都会大大提高。当然,如果最后发现所有这些灵活性都毫无必要,这才是最大的失败。你知道,这其中肯定有些灵活性的确派不上用场,但你却无法预测到底是哪些派不上用场。为了获得自己想要的灵活性,你不得不加入比实际需要更多的灵活性。

  有了重构,你就可以通过一条不同的途径来应付变化带来的风险。你仍旧需要思考潜在的变化,仍旧需要考虑灵活的解决方案。但是你不必再逐一实现这些解决方案,而是应该问问自己:『把一个简单的解决方案重构成这个灵活的方案有多大难度?』如果答案是「相当容易」(大多数时候都如此),那么你就只需实现目前的简单方案就行了。
  重构可以带来更简单的设计,同时又不损失灵活性,这也降低了设计过程的难度,减轻了设计压力。一旦对重构带来的简单性有更多感受,你甚至可以不必再预先思考前述所谓的灵活方案 — 一旦需要它,你总有足够的信心去重构。是的,当下只管建造可运行的最简化系统,至于灵活而复杂的设计,唔,多数时候你都不会需要它。

  劳而无获— Ron Jeffries
  Chrysler Comprehensive Compensation(克莱斯勒综合薪资系统)的支付过程太慢了。虽然我们的开发还没结束,这个问题却已经开始困扰我们,因为它已经拖累了测试速度。
  Kent Beck、Martin Fowler和我决定解决这个问题。等待大伙儿会合的时间里,凭着我对这个系统的全盘了解,我开始推测:到底是什么让系统变慢了?我想到数种可能,然后和伙伴们谈了几种可能的修改方案。最后,关于「如何让这个系统运行更快」,我们提出了一些真正的好点子。
  然后,我们拿Kent的量测工具度量了系统性能。我一开始所想的可能性竟然全都不是问题肇因。我们发现:系统把一半时间用来创建「日期」实体(instance)。更有趣的是,所有这些实体都有相同的值。
  于是我们观察日期的创建逻辑,发现有机会将它优化。日期原本是由字符串转换而生,即使无外部输入也是如此。之所以使用字符串转换方式,完全是为了方便键盘输入。好,也许我们可以将它优化。
  于是我们观察日期怎样被这个程序运用。我们发现,很多日期对象都被用来产生「日期区间」实体(instance)。「日期区间」是个对象,由一个起始日期和一个结束日期组成。仔细追踪下去,我们发现绝大多数日期区间是空的!
  处理日期区间时我们遵循这样一个规则:如果结束日期在起始日期之前,这个日期区间就该是空的。这是一条很好的规则,完全符合这个class的需要。采用此一规则后不久,我们意识到,创建一个「起始日期在结束日期之后」的日期区间,仍然不算是清晰的代码,于是我们把这个行为提炼到一个factory method(译注:一个著名的设计模式,见《Design Patterns》),由它专门创建「空的日期区间」。
  我们做了上述修改,使代码更加清晰,却意外得到了一个惊喜。我们创建一个固定不变的「空日期区间」对象,并让上述调整后的factory method每次都返回该对象,而不再每次都创建新对象。这一修改把系统速度提升了几乎一倍,足以让测试速度达到可接受程度。这只花了我们大约五分钟。
  我和团队成员(Kent和Martin谢绝参加)认真推测过:我们了若指掌的这个程序中可能有什么错误?我们甚至凭空做了些改进设计,却没有先对系统的真实情况进行量测。
  我们完全错了。除了一场很有趣的交谈,我们什么好事都没做。
  教训:哪怕你完全了解系统,也请实际量测它的性能,不要臆测。臆测会让你学到一些东西,但十有八九你是错的。

2
0
标签:重构

软件工程热门文章

    软件工程最新文章

      最新新闻

        热门新闻