标签：
整体鸟瞰我们听过或许没有听过那些术语和概念，多少明白或完全不明白的技术和方法，知道却没用过或完全不知道的工具和软件，这些之前各玩各的的独立散碎，在这本书中被榫卯成一个强韧的整体。你会明了它们中每一个的作用，应被安插到的位置，并见识它们各就各位时所发挥出的能量。头脑从未有过的清醒，我们理解了以前所不理解的，今天这篇博文，小编就来简单的介绍一下大话重构的故事，为什么小编会有一种大话西游的感觉呢？`(*∩_∩*)′
重构，是一把双刃剑，开发人员不要轻易使用。举个例子来说，你现在正在从事某个行业的工作，但有人告诉你另外一个行业赚钱多而且快，于是你就很纠结，到底要不要改行呢？不改行吧，钱挣得少；改行吧，自己又是新手，对那个行业又不熟悉。这种心理状态其实就是开发人员对于重构的态度，可以用“进退维谷”来形容。
由于原程序结构不能满足用户的新需求、原程序有漏洞（bug）、原程序执行效率低下，性能不足以满足用户要求。所以要而且必须要进行重构。但是重构不能随随便便的进行重构，重构是要按照一定的原则来进行的，重构的原则：小步快跑（一次一小步的修改模式，每次修改一点点进行一个测试，再修改一点点再测试）；两顶帽子（一顶是只重构原代码而不增加新功能，一顶是增加新功能以实现新需求）。
一个软件总是为解决某种特定的需求而产生，时代在发展，客户的业务也在发生变化。有的需求相对稳定一些，有的需求变化的比较剧烈，还有的需求已经消失了，或者转化成了别的需求。在这种情况下，软件必须相应的改变。
考虑到成本和时间等因素，当然不是所有的需求变化都要在软件系统中实现。但是总的说来，软件要适应需求的变化，以保持自己的生命力。
这就产生了一种糟糕的现象：软件产品最初制造出来，是经过精心的设计，具有良好架构的。但是随着时间的发展、需求的变化，必须不断的修改原有的功能、追加新的功能，还免不了有一些缺陷需要修改。为了实现变更，不可避免的要违反最初的设计构架。经过一段时间以后，软件的架构就千疮百孔了。bug越来越多，越来越难维护，新的需求越来越难实现，软件的架构对新的需求渐渐的失去支持能力，而是成为一种制约。最后新需求的开发成本会超过开发一个新的软件的成本，这就是这个软件系统的生命走到尽头的时候。
重构就能够最大限度的避免这样一种现象。系统发展到一定阶段后，使用重构的方式，不改变系统的外部功能，只对内部的结构进行重新的整理。通过重构，不断的调整系统的结构，使系统对于需求的变更始终具有较强的适应能力。
重构可以降低项目的藕合度，使项目更加模块化，有利于项目的开发效率和后期的维护。让项目主框架突出鲜明，给人一种思路清晰，一目了然的感觉，其实重构是对框架的一种维护。
总的数来，对于程序来说，重构就相当于做一次大的手术，因此一定要认真对待。贯穿整个重构过程的是不断地测试、测试、再测试。我们需要不断地实践才能够对整个重构的流程得心应手。因此从“小步快跑”和“两顶帽子”两个重要的重构思想，再到系统重构六步骤：分解大函数、拆分大对象、提高代码复用率、发现扩展点、减低依赖度、分层，这些都是重构很重要的部分。在重构时要放弃大布局，采用小设计。这种说法很有意思，感觉有点不符合我们平时正常的思维习惯，错误发现得越早就越利于修正错误。如果布局太大，错误被发现的可能会越迟，这样修正起来也更加复杂。重构时如果步子走的太大，其实花费在设计上面的时间也越多，开发周期也越长。因为考虑的太多，会导致各种各样的问题出现。 所以采用小步快跑的方式来进行重构，由于每次只关注其中的一部分功能，这样不论从设计还是开发，测试的角度来说，都是非常有利的。因为我们采用的是"小步快跑"的方式去重构，即使中间我们犯了一些错误，还是非常容易地被发现，修正。这极大的减少了我们的工作量。
在紧急变更任务中，时间就是金钱，我们要用最省时省力的方法解决问题，这里的差别就是怎样去重构？——做完整的设计， 但只做重构中最紧急的部分。
第七步：领域驱动设计：按照职责原则对系统进行领域划分形成领域模型。原程式结构与现程式结构大相径庭，并不是抛弃原有系统结构，只是通过”小步快跑”一点一点的演变而来，再次保证代码的质量水平和阅读、维护、变更。这就是重构的完整过程。
小编寄语：该博文，小编简单的介绍《大话重构》，博文分别从，整体把控整本书、何为重构、为什么要重构、什么时候重构、如何重构五个方面进行归纳总结，重构的重点，不在于如何重构，而在于重构释义过程的美学显现。
标签：
原文地址：http://blog.csdn.net/u010850027/article/details/51570648
