重构

在《重构》第二版发售前，有幸获得了抢先体验的资格，现把阅读过程中的一些心得和一些书摘整理下来。

抢读

重构的原则

何谓重构

重构这个词，既可以做名词，也可以做动词。
重构（名词）：对软件内部结构的一种调整，目的是在不改变软件可观察行为的前提下，提高其可理解性，降低其修改成本。
重构（动词）：使用一系列重构手法，在不改变软件可观察行为的前提下，调整其结构。
重构的关键在于，运用大量微小且保持软件行为的步骤，一步步达成大规模的修改。
如果有人说他们的代码在重构的过程中有一两天的时间不可用，基本上可以确定，他们在做的事不是重构。
“可观察行为”不变，指的是整体而言，经过重构之后的代码所做的事应该与重构之前大致一样。就用户应该关心的行为，不应该有任何改变。当然，如果重构过程中发现了bug，是可以改掉的。
重构与性能优化有很多相似之处，两者都需要修改代码，并且两者都不会改变程序的整体功能。两者的差别在于其目的：重构是为了让代码“更容易理解，更易于修改”，这可能会使程序运行得更快，也可能使程序运行得更慢。性能优化，只是为了让程序运行得更快，最终得到的代码有可能更难以理解和维护。

添加新功能和重构

Kent Beck的"两顶帽子"的比喻：有些时候我们是在添加新的功能（添加功能帽子），而另外一些时候我们是在改善既有代码的质量（重构帽子）。

• 添加新功能时，不应该修改既有代码，只管添加新功能。
• 重构时，不应该添加新功能，只管调整代码结构。

为何重构

• 重构帮助找到bug。
  重构可以加深对代码的理解，可以帮我们找到bug。
• 重构提高编程速度。
  良好的设计可以在添加功能时使用已有功能快速构建新功能。

何时重构

三次法则
三次法则的要求是，允许按需直接复制粘贴代码一次，但如果相同的代码片段重复出现三次以上的时候，将其提取出来做成一个子程序就势在必行。

简单来讲就是：事不过三，三则重构。

预备性重构：让添加新功能更容易

重构的最佳时机就在添加新功能之前。
其次就是修复bug时重构。

帮助理解的重构：使代码更易懂

当阅读代码时需要思考“这段代码到底在做什么”，这时就要思考，能不能重构这段代码？
可以从修改变量名称开始。
一次次的细微调整，就像是扫去窗上的尘埃。

捡垃圾式重构

当我已经理解代码在做什么，但发现它做的不好。这时，需要有一个取舍。
如果很容易重构，那就马上重构它，如果重构需要花一些经历，可能需要拿一张便笺记录下来，完成当前的任务后再回落重构它。

有计划的重构和见机行事的重构

重构不是与编程割裂的行为。你不应该专门安排时间重构，正如你不会专门安排时间写if语句。
肮脏的代码必须重构，但漂亮的代码也需要很多重构。
长久以来，人们认为编写软件是一个累加的过程：需要添加新功能，我们就应该增加新代码。但是优秀的程序员知道，添加新功能最快的方法往往是先修改现有的代码，使新功能容易被加入。每当需要新能力时，软件就应该做出相应的改变。越是在已有代码中，这样的改变就越显重要。
有计划的重构并不是错的。如果团队过去忽视了重构，那么常常会需要专门花一些时间来优化代码库，以便更容易添加新功能。

长期重构

大多数重构可以在几分钟到几小时内完成。但有些大型的重构可能需要几个星期。这样的情况下，可以让团队达成共识，在未来的几周里逐步解决这个问题。

Code review时重构

和代码原作者坐在一起，一边浏览代码一边重构，体验是最佳的。这种方式很自然的导向了结对编程：在编程的过程中不断的进行代码审核。

如何向经理解释重构

如果经理懂技术，能理解“设计耐久性假说”，那么说明重构意义应该不会太困难；
如果经理不懂技术，那就不告诉经理。

何时不应该重构

如果丑陋的代码隐藏在API之下，那可以容忍。只有当需要理解其工作原理时，对其重构才有价值。
另外，如果重写比重构还容易，那就别重构了。