怎么对经理说?
技术复审是减少错误，提高开发速度的一条重要途径，随便找一些关于复审、审查或软件的开发程序的书看看，从中找些最新引证，应该可以让大多数经理认识复审的价值。然后你就可以把重构当作“将复审意见引入代码内”的方法来使用。

间接层的价值
允许逻辑共享。比如说一个子函数在两个不同的地点被调用，或superclass中的某个函数被所有subclasses共享。
分开解释"意图"和"实现"。你可以选择每个class和函数的名字，这给了你一个解释自己意图的机会。class或函数内部则解释实现这个意图的做法。如果class和内部函数又以“更小单元的意图”来编写，你所写的代码就可以“与其结构中的大部分重要信息沟通”。
将变化加以隔离。很可能我在两个不同地点使用同一对象，其中一个地点我想改变对象行为，但如果修改了它，我就要冒“同时影响两处”的风险。为此我做出一个subclass,并在需要修改处引用这个subclass。这样我就可以修改这个subclass而不必承担“无意中影响另一处”的风险。
将条件逻辑加以编码。对象有一种匪夷所思的机制：多态消息，可以灵活而清晰的表达条件逻辑。只要显式条件逻辑被转化为消息形式，往往便能够降低代码的重复，增加清晰度并提高弹性。
推测性设计总是试图在任何一行代码诞生之前就先让系统拥有所有优秀质量，然后程序员将代码塞进这个强健的骨架就行了。这个过程的问题在于：太容易猜错。如果运用重构，你就永远不会面临全盘错误的危险。
还有一种比较少见的重构游戏：找出不值得的间接层，并将它拿掉。这种间接层常以中介函数的形式出现，也许曾有有过贡献，但芳华已逝。它也可能是个组件，你本来期望在不同地点共享它，或让他表现出多态性，最终却只在一处使用之。如果你找到这种“寄生式间接层”，请把它扔掉。如此一来你会获得一个更有价值的程序，不是因为它取得了更多的四种优秀质量，而是因为它以更少的间接层获得一样多的优秀质量。
数据库
就算你非常小心的将系统分层，将database schema和对象模型间的依赖降至最低，但database schema的改变还是让你不得不迁移所有数据，这可能是件漫长而繁琐的工作。
修改接口
只有当需要修改的接口被那些找不到，即使找到也不能修改的代码使用时，接口的修改才会成为问题。这种接口被称之为“已发布接口”。比公开接口更进一步。接口一旦发布，你就再也无法仅仅修改调用者而能够安全的修改接口了。
如果重构手法改变了已发布接口，你必须同时维护新旧两个接口，直到你的所有用户都有时间对这个变化做出反应。幸运的是这不太困难。你通常都有办法把事情组织好，让旧接口继续工作。请尽量这么做：让旧接口调用新接口。当你需要修改某个函数名称时，请留下旧函数，让它调用新函数。千万不要拷贝函数实现码，那会让你陷入“重复代码”的泥淖中难以自拔。你还应该使用java提供的deprecated（反对）关键字，标记旧接口。这么一来你的调用者就会注意它了。
过渡强调代码拥有权的团队常常会犯过量发布接口的错误。除非真有必要，别发布接口。让每个人都可以修改别人的代码，以运应接口的改动。Pair Programming通常是个好主意。
对于会出现不可控异常的情况，通常可以在包中创建一个超类异常，然后让所有的public函数只在自己的throws 子句中声明这个异常。这样就可以随心所欲的定义子类异常，不会影响调用者。因为调用者永远只知道subperclass异常。
这里可以 写一个例子：
开始的时候，我的电脑只有键盘这种输入工具，所以我可以这样定义我的“电脑”类：

它会抛出键盘异常。后来，我的电脑又有了鼠标这种设备，所以要想保证鼠标的使用过程中所产生的错误是可控的，只能这样修改接口：

这样就导致了接口被修改，涉及这个接口的实现者需要作出修改，否则不能编译通过；但是不这样做的话，鼠标输入的异常就会变为不可控异常。所以书中提倡这样做：

其中InputDeviceException是所有输入设备异常的超类，这样既不用修改实现者的代码，也保证了这些异常是可控的。