Chapter 2. Principles in Refactoring

重构是啥： 改变代码的内部结构（internal structure）使其易于后续开发和维护，重构不能改变代码的外现（observable behavior）。重构前后该“黑盒”的输入输出不能改变。

总之Any user, whether an end user or another programmer, cannot tell that things have changed.（搞性能优化的重构例外）

两顶帽子：开发时肯定要加入代码（函数、文件等），还有就是审时度势的重构，保障代码的clean，帽子要经常换着带哦。Clean这个词在这用的比较传神，既有文本层面的整洁之意，也有架构或逻辑上清晰简单的感觉。

重构的好处：

Refactoring Improves the Design of Software

Refactring Makes Software Easier to Understand

Refactoring Helps You Find Bugs

Refactoring Helps You Program Faster

经过长时间增量的开发，原本健壮的软件/模块可能已经开始腐烂，（毕竟不能保证每次都由模块的最初设计者来进行开发），给后面的开发或维护带来了风险和困难，及时重构尽可能地消除它们。良好的设计是基础，及时的重构是保障。

什么时候进行重构？ 有个事不过三法则：第一次肯定是新创造，无所谓；第二次产生重复或觉得别扭时，可能由于时间紧或什么原因也就凑合过去了；但第三次再出现类似问题时一定要停下，对代码进行重构，保持clean。

作者认为1-加入新功能时、2-修复bug时，3-代码检视时。重构是自发地不受特定时间限制的，不是说写完代码专门花2周时间进行重构，而是边开发边重构。修复bug时看看bug产生的原因，是否可以重构减少某些陷阱的存在。检视嘛，大家集思广益，不过个人觉得多人检视开发前的设计文档更重要一些，减少无谓的反工，让新代码尽量完美.....

最近的感悟是现在软件开发都在追求敏捷，小步快跑，当一上午写完几个功能函数后就可以回顾看一下新代码与老代码的结合，是否存在能够进行重构而提高效率或使代码更易懂的地方，不是只有架构上重来才叫重构，函数的重命名，改变参数返回值等都可以，不积跬步，无以至千里。

这里还提到了一些开发时准则，单一职责，依赖抽象等，直接去看设计模式等类的书吧。

重构的难题，DB和UI等，DB和表项的设计绝对是大师才能干的，UI就仁者见仁了。还提到了接口的重构，不要随意或急于发布接口，否则死得很惨，新接口成熟后，再进行替换，或直接是老接口内部封装新接口，改动最小。

最后强调了重构是为了提高代码的质量，如果现有时间紧迫，或基本质量都得不到保证时，不要进行重构。

重构与设计：大部分人认为有了设计后，coding就是体力活，不需要什么重构了。作者引用了Alistair Cockburn某大师一句话："With design I can think very fast, but my thinking is full of little holes." 感觉在说设计也不是完美的，依然会在coding时发现哪哪又设计的不对了，呼唤重构。

XP极限编程的爱好者认为，俺们不需要设计，直接开编，随时重构。也有这样开发出优秀软件的例子。不过这个还是建立在牛人的基础上吧.....对大部分人老说，设计的准备还是很重要的。不过设计时也不用用力过猛，谁也不知道coding时会遇到什么问题，或者方案有什么漏洞需要变更，就是说注意弹性（flexibility）。

性能重构：绝大部分软件性能差都是由于10%的模块导致的，优化时务必找准要害，不要轻易全部推到重来。其它的建议个人现在还理解不了，就不写了。