### 怎么对经理说？
「该怎么跟经理说重构的事？」这是我最常被问到的问题之一。如果这位经理懂技术，那么向他介绍重构应该不会很困难。如果这位经理只对质量感兴趣，那么问题就集中到了「质量」上面。此时，在复审过程中使用重构，就是一个不错的办法。 大量研究结果显示，「技术复审」是减少错误、提高开发速度的一条重要途径。随便找一本关于复审、审査或软件开发程序的书看看，从中找些最新引证，应该可以让大多数经理认识复审的价值。然后你就可以把重构当作「将复审意见引入代码内」的方法来使用，这很容易。
当然，很多经理嘴巴上说自己「质量驱动」，其实更多是「进度驱动」。这种情况下我会给他们一个较有争议的建议：不要告诉经理！
这是在搞破坏吗？我不这样想。软件开发者都是专业人士。我们的工作就是尽可能快速创造出髙效软件。我的经验告诉我，对于快速创造软件，重构可带来巨大帮助。如果需要添加新功能，而原本设计却又使我无法方便地修改，我发现先「进行重构」再「添加新功能」会更快些。如果要修补错误，我需得先理解软件工作方式，而我发现重构是理解软件的最快方式。受进度驱动的经理要我尽可能快速完事，至于怎么完成，那就是我的事了。我认为最快的方式就是重构，所以我就重构。
**间接层和重构（Indirection and Refactoring）**
——Kent Beck
「计算机科学是这样一门学科：它相信所有问题都可以通过多一个间接层（Indirection）来解决。」——Dennis DeBruler
由于软件工程师对间接层如此醉心，你应该不会惊讶大多数重构都为程序引入了更多间接层。重构往往把大型对象拆成数个小型对象，把大型函数拆成数个小型函数。
但是，间接层是一抦双刃剑。每次把一个东西分成两汾，你就需要多管理一个东西。如果某个对象委托（delegate)另一对象，后者又委托另一对象，程序会愈加难以阅读。基于这个观点，你会希望尽量减少间接层。
別急，伙计！间接层有它的价值。下面就是间接层的某些价值：
- 允许逻辑共享〔To enable sharing of logic）。比如说一个子函数（submethod）在两个不同的地点被调用，或superclass的某个函数被所有subclass共享。
- 分开解释「意图」和「实现](To explain intention and implementation separately）。你可以选择每个class和函数的名字，这给了你一个解释自己意图的机会。class或函数内部则解释实现这个意图的作法。如果class和函数内部又以「更小单元的意图」来编写，你所写的代码就可以『与其结构中的大部分重要信息沟通」。
- 将变化加以隔离（To isolate change）。很可能我在两个不同地点使用同一对象，其中一个地点我想改变对象行为，但如果修改了它，我就要冒「同时影响两处」的风险。为此我做出一个subclass，并在需要修改处引用这个subclass。现在，我可以修改这个subclass而不必承担「无意中影响另一处」的风险。
- 将条件逻辑加以编码（To encode conditional logic）。对象有一种匪夷所思的机制：多态消息（polymorphic messages），可以灵活弹性而清晰地表达条件逻辑。只要显式条件逻辑被转化为消息（message [2])形式，往往便能降低代码的重复、增加清晰度并提髙弹性。
[2]译注：此处的「消息」（message）是指面向对象古典论述中的意义。在那种场合中，「调用某个函数（method）」就是「送出消息（message）给某个对象（object）」。
这就是重构游戏：在保持系统现有行为的前提下，如何才能提高系统的质量或降低其成本，从而使它更有价值？
这个游戏中最常见的变量就是：你如何看待你自己的程序。找出一个缺乏「间接层利益」之处，在不修改现有行为的前提下，为它加入一个间接层。现在你获得了一个更有价值的程序，因为它有较髙的质量，让我们在明天（未来）受益。
请将这种方法与「小心翼翼的事前设计」做个比较。推测性设计总是试图在任何一行代码诞生之前就先让系统拥有所有优秀质量，然后程序员将代码塞进这个强健的骨架中就行了。这个过程的问题在于：太容易猜错。如果运用重构，你就永远不会面临全盘错误的危险。程序自始至终都能保持一致的行为，而你又有机会为程序添加更多价值不菲的质量。
还有一种比较少见的重构游戏：找出不值得的间接层，并将它拿掉。这种间接层常以中介函数（intermediate methods）形式出现，也许曾经有过贡献，但芳华已逝。它也可能是个组件，你本来期望在不同地点共享它，或让它表现出多态性（polymorphism），最终却只在一处使用之。如果你找到这种「寄生式间接层」，请把它扔掉。如此一来你会获得一个更有价值的程序，不是因为它取得了更多（先前所列）的四种优秀质量，而是因为它以更少的间接层获得一样多的优秀质量。
- 译序 by 侯捷
- 译序 by 熊节
- 序言
- 前言
- 章节一 重构，第一个案例
- 起点
- 重构的第一步
- 分解并重组statement()
- 运用多态（Polymorphism）取代与价格相关的条件逻辑
- 结语
- 章节二 重构原则
- 何谓重构
- 为何重构
- 「重构」助你找到臭虫(bugs)
- 何时重构
- 怎么对经理说？
- 重构的难题
- 重构与设计
- 重构与性能（Performance）
- 重构起源何处？
- 章节三 代码的坏味道
- Duplicated Code（重复的代码）
- Long Method（过长函数）
- Large Class（过大类）
- Long Parameter List（过长参数列）
- Divergent Change（发散式变化）
- Shotgun Surgery（散弹式修改）
- Feature Envy（依恋情结）
- Data Clumps（数据泥团）
- Primitive Obsession（基本型别偏执）
- Switch Statements（switch惊悚现身）
- Parallel Inheritance Hierarchies（平行继承体系）
- Lazy Class（冗赘类）
- Speculative Generality（夸夸其谈未来性）
- Temporary Field（令人迷惑的暂时值域）
- Message Chains（过度耦合的消息链）
- Middle Man（中间转手人）
- Inappropriate Intimacy（狎昵关系）
- Alternative Classes with Different Interfaces（异曲同工的类）
- Incomplete Library Class（不完美的程序库类）
- Data Class（纯稚的数据类）
- Refused Bequest（被拒绝的遗贈）
- Comments（过多的注释）
- 章节四 构筑测试体系
- 自我测试代码的价值
- JUnit测试框架
- 添加更多测试
- 章节五 重构名录
- 重构的记录格式
- 寻找引用点
- 这些重构准则有多成熟
- 章节六 重新组织你的函数
- Extract Method（提炼函数）
- Inline Method（将函数内联化）
- Inline Temp（将临时变量内联化）
- Replace Temp with Query（以查询取代临时变量）
- Introduce Explaining Variable（引入解释性变量）
- Split Temporary Variable（剖解临时变量）
- Remove Assignments to Parameters（移除对参数的赋值动作）
- Replace Method with Method Object（以函数对象取代函数）
- Substitute Algorithm（替换你的算法）
- 章节七 在对象之间搬移特性
- Move Method（搬移函数）
- Move Field（搬移值域）
- Extract Class（提炼类）
- Inline Class（将类内联化）
- Hide Delegate（隐藏「委托关系」）
- Remove Middle Man（移除中间人）
- Introduce Foreign Method（引入外加函数）
- Introduce Local Extension（引入本地扩展）
- 章节八 重新组织数据
- Self Encapsulate Field（自封装值域）
- Replace Data Value with Object（以对象取代数据值）
- Change Value to Reference（将实值对象改为引用对象）
- Replace Array with Object（以对象取代数组）
- Replace Array with Object（以对象取代数组）
- Duplicate Observed Data（复制「被监视数据」）
- Change Unidirectional Association to Bidirectional（将单向关联改为双向）
- Change Bidirectional Association to Unidirectional（将双向关联改为单向）
- Replace Magic Number with Symbolic Constant（以符号常量/字面常量取代魔法数）
- Encapsulate Field（封装值域）
- Encapsulate Collection（封装群集）
- Replace Record with Data Class（以数据类取代记录）
- Replace Type Code with Class（以类取代型别码）
- Replace Type Code with Subclasses（以子类取代型别码）
- Replace Type Code with State/Strategy（以State/strategy 取代型别码）
- Replace Subclass with Fields（以值域取代子类）
- 章节九 简化条件表达式
- Decompose Conditional（分解条件式）
- Consolidate Conditional Expression（合并条件式）
- Consolidate Duplicate Conditional Fragments（合并重复的条件片段）
- Remove Control Flag（移除控制标记）
- Replace Nested Conditional with Guard Clauses（以卫语句取代嵌套条件式）
- Replace Conditional with Polymorphism（以多态取代条件式）
- Introduce Null Object（引入Null 对象）
- Introduce Assertion（引入断言）
- 章节十一 处理概括关系
- Pull Up Field（值域上移）
- Pull Up Method（函数上移）
- Pull Up Constructor Body（构造函数本体上移）
- Push Down Method（函数下移）
- Push Down Field（值域下移）
- Extract Subclass（提炼子类）
- Extract Superclass（提炼超类）
- Extract Interface（提炼接口）
- Collapse Hierarchy（折叠继承关系）
- Form Template Method（塑造模板函数）
- Replace Inheritance with Delegation（以委托取代继承）
- Replace Delegation with Inheritance（以继承取代委托）
- 章节十二 大型重构
- 这场游戏的本质
- Tease Apart Inheritance（梳理并分解继承体系）
- Convert Procedural Design to Objects（将过程化设计转化为对象设计）
- Separate Domain from Presentation（将领域和表述/显示分离）
- Extract Hierarchy（提炼继承体系）
- 章节十三 重构，复用与现实
- 现实的检验
- 为什么开发者不愿意重构他们的程序？
- 现实的检验（再论）
- 重构的资源和参考资料
- 从重构联想到软件复用和技术传播
- 结语
- 参考文献
- 章节十四 重构工具
- 使用工具进行重构
- 重构工具的技术标准（Technical Criteria ）
- 重构工具的实用标准（Practical Criteria ）
- 小结
- 章节十五 集成
- 参考书目