重构概述——摘自《重构》

    Design Patterns 为 Refactoring 提供了目标。
    重构：在不改变代码外在行为的前提下，对代码做出修改，以改进程序的内部结构。
    重构是一种有纪律的，经过训练的，有条不紊的程序整理方法，可以将整理过程中不小心引入错误的几率降到最低。本质上说，重构就是“在代码写好之后改进它的设计”。
    差劲的系统是很难修改的，因为很难找到修改点。如果很难找到修改点，程序员就很有可能犯错，从而引入bugs。如果你发现自己需要为程序添加一个特性，而代码结构使你无法很方便地那么做，那就先重构那个程序，使特性的添加比较容易进行，然后再添加特性。
    重构第一笔，永远相同：为即将修改的代码建立一组可靠的测试环境。好的测试环境是重构的根本。花时间建立一个良好的测试机制是完全值得的。重构之前，首先检查自己是否有一套可靠的测试机制。这些测试必须有自我检验（self－checking）能力。
    重构技术是以微小的步伐修改程序。如果你犯下错误，很容易便可发现它。

    更改变量的名称是值得的行为吗？绝对值得。好的代码应该清楚表达出自己的功能，变量名称是代码清晰的关键。任何一个傻瓜都能写出计算机可以理解的代码。惟有写出人类容易理解的代码，才是优秀的程序员。
    在另一个对象的属性（attribute）基础上运用switch语句，不是什么好主意。如果不得不使用，也应该在对象自己的数据上使用，而不是在别人的数据上使用。
    同样完成一件事，设计不良的程序往往需要更多的代码，这常常是因为代码在不同的地方使用完全相同的语句做同样的事。因此改进设计的一个重要方向就是消除重复的代码（Duplicate Code）。如果消除重复代码，就可以确定代码将所有事物喝行为都只表述一次，惟一一次，这正是优秀设计的根本。
    良好设计是维持软件开发速度的根本。
    不应该为重构而重构，你之所有重构，是因为你想做别的什么事，而重构可以帮助你把那些事做好。
    何时重构？
    1、添加功能时一并重构；
    2、修补错误时一并重构；
    3、复审代码时一并重构。

    重构改变了“预先设计”的角色。如果没有重构，你就必须保证“预先设计”正确无误，这个压力太大了。这意味如果将来需要对原始设计做任何修改，代价都将非常高昂。因此你需要把更多的时间和精力放在预先设计上，以避免日后修改。
    如果你选择重构，问题的重点就转变了。你仍然做预先设计，但是不必一定找出正确的解决方案。此刻的你只需要得到一个足够合理的解决方案就够了。你很肯定地知道，在实现这个初始解决方案的时候，你对问题的理解也会逐渐加深，你能够会察觉最佳解决方案和你当初设想的有些不同。只要有重构这项武器在手，就不成问题，因为重构让日后的修改成本不再高昂。