1 什么叫做重构
重构是在不改变软件可观察行为的前提下改善其内部结构, 重构的本质就是在代码写好之后改进它的设计
2 为什么要进行代码重构
- 如果没有重构，程序的设计会逐渐 腐败变质
- 重构使软件 更容易理解，通过重构代码来协助开发人理解不熟悉的代码
- 如果对代码进行重构，就可以深入理解 代码的行为，重构帮助找到 隐藏BUG
- 完成同样一件事，设计不良的程序往往需要 更多的代码，这通常是因为代码在不用的地方使用完全相同的语句去做同样的事
- 归结为一点的话那就是：重构帮助你更快速的开发程序
3 何时重构
应该怎样安排重构时间表。是不是应该每两个月就专门安排两个星期来进行重构呢？作者提出的意见是：几乎任何情况下都反对专门拨出时间进行重构。重构本来就不是一件应该特别拨出时间来做的事情，重构应该随时随地进行。不应该为重构而重构，你之所以重构，是因为你想做别的什么事，而重构可以帮助你把那些事做好
3.1 三次法则
第一次做某件事时只管去做；第二次做类似的事会产生方案，但无论如何还是可以去做；第三次再做类似的事，你就应该重构简单理解：事不过三，三则重构
3.2 添加功能时重构
- 最常见的重构时机就是我想给软件添加 新特性 的时候。此时，重构的直接原因往往是为了帮助我理解需要修改的代码 - 这些代码可能是别人写的，也可能是我自己写的
- 无论何时，只要我想 理解代码所做的事，我就会问自己：是否能够对这段代码进行重构，使我能更快地理解它。然后我就会重构
- 之所以这么做，部分原因是为了让我 下次再看 这段代码时容易理解。但最主要的原因是如果再前进过程中把 代码结构理清，我就可以从中理解更多东西
3.3 修补错误时重构
调试过程中运用重构，多半是为了让代码更具有可读性3.4 复审代码时重构
- 很多公司都会做常规的 代码复查，因为这种活动可以改善开发状况
- 代码复查对于 编写清晰代码 也很重要。我的代码也许对于我自己来说很清晰，对他人则不然
- 针对与代码复查，个人觉得是很有必要的，可以通过 review 来对代码的 坏味道、个人不好的编码习惯及优化点 做出改良
4 何时不该重构
- 有时候你根本 不应该重构，例如当你应该重新编写所有代码的时候。有时候既有代码 实在太混乱，重构它还不如 重新写 一个来的简单
- 重写 (而非重构)的一个清楚讯号就是：现有代码根本不能正常运作。你可能只是试着做点测试，然后就发现代码中满是错误，根本 无法稳定运作。记住，重构之前，代码必须起码能够大部分情况下正常运作
- 另外在项目已经最后期限，你也应该避免重构。在此时机，从重构过程赢得的生产力只有在最后期限过后才能体现出来，而那个时候已经 为时晚矣
- 如果项目已经非常接近最后期限，你不应该再 分心于重构，因为已经没有时间了。不过多个项目经验显示：重构的确能够提升生产力。如果最后你没有足够时间，通常就表示你其实 早就该进行重构
5 重构与设计
- 重构肩负一项特殊使命：它和设计彼此互补。初学编程时候，我埋头就写程序，浑浑噩噩地进行开发。然后很快我便发现：事先做好设计可以让我节省返工的高昂成本
- 有一种观点认为：重构可以取代预先设计。这意思就是你根本不需要做任何设计，只需按照最初想法开始编码，让代码有效运作，然后再将它 重构成型。事实上这种办法真的可行。的确有人这么做，最后获得设计良好的软件。极限编程[Beck，XP]的支持者极力提倡这种办法
- 尽管如上所言，只运用重构也能收到效果，但这 并不是最有效的途径。是的，就连极限编程的爱好者们也会进行预先设计。关键在于：重构改变了预先设计的角色。如果没有重构，你就必须保证预先做出的设计正确无误，这个压力太大了。
如果你选择重构，问题的重点就转变了。你仍然预先设计，但是不必一定找出正确的解决方案。此时的你只需要得到一个足够合理的解决方案就够了
- 这种转变导致一个重要结果：软件设计向简化 前进了一大步。过去未曾运用重构时，总是力求得到灵活的解决方案。任何一个需求都提心吊胆地猜疑：在系统的有生之年，这个需求会导致怎样的变化？由于 变更设计的代价非常高昂，所以我希望建造一个 足够灵活、足够可靠 的解决方案，所需的成本难以估算
- 有了重构，你就可以通过一条不同的途径来应对变化带来的风险。你 仍旧需要思考潜在的变化，依旧需要考虑灵活 的解决方案。但是你不必再逐一实现这些解决方案，而是应该问问自己：“把一个简单的解决方案重构成这个灵活的方案有多大的难度？”如果答案是“相当容易”（大多数时候都如此），那么你就只需要实现目前的简单方案就行了
- 重构可以带来更简单的设计，同时又 不损失灵活性，这也 降低了设计过程的难度，减轻了设计压力。一旦对重构带来的简单性有更多感受，你甚至可以不必再预先思考前述所谓的灵活方案，一旦需要它，你总有足够的信心去重构。是的，当下只管建造可运行的最简化系统，至于灵活而复杂的设计，唔，多数时候你都不会需要它
6 金玉良言
懒惰是程序员的美德之一，绝不要因为《重构改善既有代码的设计》让你变得勤快
在设计前期使用设计模式常常导致过度工程，良好的程序设计是维持软件开发速度的根本
以重构方式改进软件质量
重构有风险，修改需谨慎
任何一个傻瓜都能写出计算机可以理解的代码。唯有写出人类容易理解的代码，才是优秀的程序员
