读书笔记--《大话重构》

等一个故事 · 4 小时前

整体鸟瞰
最近小编读了一本书，叫做《大话重构》，这本书运用大量源于实践的示例，从编码、设计、组织、架构、测试、评估、应对需求变更等方面，深入而多角度地讲述了我们应该如何重构，建设性地提出了高效可行的重构七步。读完本书，实践重构不再卡壳，需求变更不再纠结。全面领悟重构之美，遗留系统不再是梦魇，自动化测试原来可以这样做。本书帮助程序员告别劣质代码步入精妙设计，让遗留系统的维护者逐步改善原有设计，指导重构实践者走出困惑步步坚定。同时，也为管理者加强软件质量的管理与监督，提供了好的方法与思路。
本书的最大价值在于两点： 
　　一，让读者明白真正的专业级软件开发是如何进行的； 
　　二，让读者明白真正的重构具体是一步步怎么做的。 
　　作者范钢老师将繁复冗长模糊不清的软件重构过程划分成明确而清晰的七个步骤。使初学者在面对实际中的软件重构时，不会卡壳。 
　　这本书所讲解的重构远远超越了代码级，充分渗透到软件系统与设计的各个层面，涵盖从代码、函数、类与对象，直至设计模式、分层架构、领域模型、软件测试的整个过程。 

　　我们听过或许没有听过那些术语和概念，多少明白或完全不明白的技术和方法，知道却没用过或完全不知道的工具和软件，这些之前各玩各的的独立散碎，在这本书中被榫卯成一个强韧的整体。你会明了它们中每一个的作用，应被安插到的位置，并见识它们各就各位时所发挥出的能量。头脑从未有过的清醒，我们理解了以前所不理解的，今天这篇博文，小编就来简单的介绍一下大话重构的故事，为什么小编会有一种大话西游的感觉呢？`(*∩_∩*)′

何为重构？
要想理解重构首先要充分的理解重构的定义。重构（Refactoring）就是通过调整程序代码改善软件的质量、性能，使其程序的设计模式和架构更趋合理，提高软件的扩展性和维护性。
重构的定义：对软件内部结构的一种调整，目的是在不改变”软件之可察行为“前提下，提高其可理解性，降低其修改成本。重构就是在代码写好之后改进它的设计。重构和添加新功能并不冲突，但是当开发者身份在两者之间切换时候，不能混淆在一起。

重构，是一把双刃剑，开发人员不要轻易使用。举个例子来说，你现在正在从事某个行业的工作，但有人告诉你另外一个行业赚钱多而且快，于是你就很纠结，到底要不要改行呢？不改行吧，钱挣得少；改行吧，自己又是新手，对那个行业又不熟悉。这种心理状态其实就是开发人员对于重构的态度，可以用“进退维谷”来形容。

为什么要重构？

由于原程序结构不能满足用户的新需求、原程序有漏洞（bug）、原程序执行效率低下，性能不足以满足用户要求。所以要而且必须要进行重构。但是重构不能随随便便的进行重构，重构是要按照一定的原则来进行的，重构的原则：小步快跑（一次一小步的修改模式，每次修改一点点进行一个测试，再修改一点点再测试）；两顶帽子（一顶是只重构原代码而不增加新功能，一顶是增加新功能以实现新需求）。

一个软件总是为解决某种特定的需求而产生，时代在发展，客户的业务也在发生变化。有的需求相对稳定一些，有的需求变化的比较剧烈，还有的需求已经消失了，或者转化成了别的需求。在这种情况下，软件必须相应的改变。
考虑到成本和时间等因素，当然不是所有的需求变化都要在软件系统中实现。但是总的说来，软件要适应需求的变化，以保持自己的生命力。
这就产生了一种糟糕的现象：软件产品最初制造出来，是经过精心的设计，具有良好架构的。但是随着时间的发展、需求的变化，必须不断的修改原有的功能、追加新的功能，还免不了有一些缺陷需要修改。为了实现变更，不可避免的要违反最初的设计构架。经过一段时间以后，软件的架构就千疮百孔了。bug越来越多，越来越难维护，新的需求越来越难实现，软件的架构对新的需求渐渐的失去支持能力，而是成为一种制约。最后新需求的开发成本会超过开发一个新的软件的成本，这就是这个软件系统的生命走到尽头的时候。
重构就能够最大限度的避免这样一种现象。系统发展到一定阶段后，使用重构的方式，不改变系统的外部功能，只对内部的结构进行重新的整理。通过重构，不断的调整系统的结构，使系统对于需求的变更始终具有较强的适应能力。
重构可以降低项目的藕合度，使项目更加模块化，有利于项目的开发效率和后期的维护。让项目主框架突出鲜明，给人一种思路清晰，一目了然的感觉，其实重构是对框架的一种维护。

总的数来，对于程序来说，重构就相当于做一次大的手术，因此一定要认真对待。贯穿整个重构过程的是不断地测试、测试、再测试。我们需要不断地实践才能够对整个重构的流程得心应手。因此从“小步快跑”和“两顶帽子”两个重要的重构思想，再到系统重构六步骤：分解大函数、拆分大对象、提高代码复用率、发现扩展点、减低依赖度、分层，这些都是重构很重要的部分。在重构时要放弃大布局，采用小设计。这种说法很有意思，感觉有点不符合我们平时正常的思维习惯，错误发现得越早就越利于修正错误。如果布局太大，错误被发现的可能会越迟，这样修正起来也更加复杂。重构时如果步子走的太大，其实花费在设计上面的时间也越多，开发周期也越长。因为考虑的太多，会导致各种各样的问题出现。 所以采用小步快跑的方式来进行重构，由于每次只关注其中的一部分功能，这样不论从设计还是开发，测试的角度来说，都是非常有利的。因为我们采用的是"小步快跑"的方式去重构，即使中间我们犯了一些错误，还是非常容易地被发现，修正。这极大的减少了我们的工作量。

什么时候重构？
重构是一种习惯，一种编程习惯。这种习惯让我们迅速由菜鸟转变为大牛，可以编写出高质量、优秀的程序。问题的关键就是降低修改成本与风险的方法，而这个方法就是系统重构。走出重构的第一步对每一个人来说都是一次心灵的考验，甚至许多人总是徘徊于路口踌躇不前，但一旦跨出去了，它将成为你生命的一部分。
没有经过重构的，原生态的代码是没办法复用的，当我们发现代码需要复用时，切忌不要使用过去那种简单粗暴的复制黏贴，合理运用重构方法，加之以仔细、认真、即时的测试，就可以保证既有代码的正确，并使整个系统合理地复用起来，以提高系统的可维护性，关键是你有没有这样的意识。
添加新功能前线重构原系统，其目的有两个：
a、 软件的设计总是与软件的复杂度有关的，原有的设计师在原有需求不复杂的条件下做出的，但随着新功能的加入，软件复杂度在发生着变化，因此必须调整原有的设计。
b、为了提高软件的可维护性与易变更性，添加新功能应遵循OCP原则。系统重构是我们维护处高质量遗留系统的有效工具。

在紧急变更任务中，时间就是金钱，我们要用最省时省力的方法解决问题，这里的差别就是怎样去重构？——做完整的设计， 但只做重构中最紧急的部分。

如何重构？
第一步：从分解大函数开始 随着业务逻辑越来越复杂，程序员总是就着原有的程序结构不断的添加新的代码。原有的清晰而简单的程序，随着新代码的不断添加，因此，大多数软件企业的遗留系统中，超级大函数就变成了一种通病。因此重构的第一步就是要从分解大函数开始。所以寻求一个系统的切入点，归纳整理大函数的各司逻辑，运行重构"抽取方法"进行函数分解化为多个不同逻辑的函数，从而优化原有的系统结构，提高了阅读的方便性。
第二步：拆分大对象，分解了大函数，滞留的是被分解的上百上千的方法或函数，接下来就是对大对象的分解。利用重构”抽取类”将分解的函数或方法进行整合至对象中，同时保证单一职责原则，一个对象或类完成一项业务逻辑职责。最后进行类的归并。
第三步：提高代码复用率 分解过大函数、拆分大对象，系统重构从无序的乱码变得有序井然，系统的逻辑流程也清楚明白，接下来做的就是对代码的优化，遵循”DRY”原则，同一对象中存在重复逻辑代码，运用”重构方法”抽取为对应的逻辑名函数；不同对象中村子啊重复逻辑代码，运用”抽取类”将重复部分抽取为一个公用类，方便其他类调用。当重复的所在类具有并列关系，运用”抽取父类”将相同代码抽取为共有的父类。
第四步：发现程序可扩展点 系统能应对业务多变的需求变更，提高系统的易变更性，也是重构系统的目的之一。系统应保证一般性原则：预见性可扩展设计尽量不要太多；”两顶帽子”设计模式—一顶是系统重构，一顶是面对新需求实现功能。遵循”OCP原则(开放-关闭原则)”也是可扩展点的前提根本。
第五步：降低程序依赖度 降低系统的依赖度是重构系统的最根本方法。减少功能逻辑之间的联系度，新需求建立独立的功能逻辑，满足了系统功能的耦合度，达到了系统开发低耦合高内聚。
第六步：分层 分层结构是系统开发前期所设计的系统架构，默认的架构是三层架构：数据层、业务逻辑层、应用层。分层的意义在于独立各功能逻辑关系，在面对业务需求变更时，以改变原逻辑最小的代价，提高了系统代码质量。

第七步：领域驱动设计：按照职责原则对系统进行领域划分形成领域模型。原程式结构与现程式结构大相径庭，并不是抛弃原有系统结构，只是通过”小步快跑”一点一点的演变而来，再次保证代码的质量水平和阅读、维护、变更。这就是重构的完整过程。

小编寄语：该博文，小编简单的介绍《大话重构》，博文分别从，整体把控整本书、何为重构、为什么要重构、什么时候重构、如何重构五个方面进行归纳总结，重构的重点，不在于如何重构，而在于重构释义过程的美学显现。