重构的认知

在不改变软件可观察行为的前提下改善其内部结构这是重构的最基本定义。

重构并不是重做系统。

当你面对一个最需要重构的遗留系统时，其规模之大、历史之久、代码质量之差，常会使得添加单元测试或者理解其逻辑都成为不可能的任务。此时你唯一能依靠的就是那些已经被证明是行为保持的重构手法：用绝对安全的手法从“坑”中整理出可测试的接口，给它添加测试，以此作为继续重构的立足点。

“不改变软件行为”只是重构的最基本要求，要想真正让重构技术发挥威力，就必须做到“不需要了解软件行为”--听起来很荒谬，但事实如此。如果一段代码能让你容易了解其行为，说明它还不是那么迫切需要被重构。那些最需要重构的代码，你只能看到其中的坏味道，接着选择对应的重构方法来消除这些坏味道，然后才有可能理解它的行为。

在设计前期使用设计模式常常导致过度工程，这是一个残酷的现实，单凭对完美的追求无法写出使用的代码，而“使用”是软甲压倒一切的要素。

重构具有风险，它必须修改运作中的程序，这可能引入一些不易察觉的错误。如果重构方式不当，可能毁掉你数天甚至数星期的成果。如果重构时不做好准备，不遵守规则，风险就更大了。你挖掘自己的代码，很快发现了一些值得修改的地方，于是你挖得更深。挖得更深，找到的重构机会越多，于是你修改的也越多......最后你给自己挖了个大坑，缺爬出去了。为了避免自掘坟墓，重构必须系统化进行。