### 这场游戏的本质 以下面介绍的重构手法中，你肯定会注意到一件事：重构步骤的描述，不再如前面 那么仔细。这是因为在大型重构中，情况有很多变化，我们无法告诉你准确的重构步骤；如果没有看到实际情况，任谁都无法确切知道该怎么做。当你为某个函数添加参数时，作法可以很仔细而清楚，因为重构范围（作用域）很清楚。但是当你分 解一个继承体系时，由于每个继承体系都是不同的，所以我们无法告诉你确切的重构步骤。 另外，对于这些大型重构，还有一件事需要注意：它们会耗费相当长的时间。第6 章至第11章所介绍的重构手法，都可以在数分钟（至多一个小时）内完成，但是我们曾经进行过的一些大型重构，却需要数月甚至数年的时间。如果你需要给一个运行中的系统添加功能，你不可能说服经理把系统停止运行两个月让你进行重构； 你只能一点一点地做你的工作，今天一点点，明天一点点。 在这个过程中，你应该根据需要安排自己的工作，只在需要添加新功能或修补错误 时才进行重构。你不必一开始就完成整个系统的重构；重构程度只要能满足其他任务的需要就行了。反正明天你还可以回来重构。 本章范例也反映出这样的哲学。如果要向你展示本书中所有的重构，轻易就能耗去上百页篇幅。我们很清楚这一点，因为Martin 的确尝试过。所以，我们把范例压缩至「数张概略图」的尺度。 由于大型重构可能需要花费相当长的时间，因此它们并不像其他章节介绍的重构那样，能够立刻让人满意。你必须有那么一点小小的信仰：你每天都在使你自己的程序世界更安全。 进行大规模重构时，有必要为整个开发团队建立共识；这是小型重构所不需要的。大型重构为许许多多的修改指定了方向。整个团队都必须意识到：有一个大型重构正在进行，每个人都应该相应地安排自己的行动。说到这里，我想给大家讲个故事。 两个家伙的车子在山顶附近抛锚了，于是他俩走下车，一人走到车的一头，开始推车。经过毫无成果的半小时之后，车头那家伙开口说道：『我从来不知道把车推下山这么难！』另一个家伙答道：『嘿，你说「推下山」是什么意思？难道我们不是想把车推上山吗？』我猜你一定不想让这个故事在你的开发团队中重演，对吧！ 大型重构的重要性 我们已经看到，使那些小型重构突显价值的质量（可预测的结果、可观察的过程、 立竿见影的满足等等〕，在大型重构中往往并不存在。既然如此，为什么大型重构还那么重要，以至于我们想要把它们放进本书？那是因为如果没有它们，我们就可能面临这样的风险：投入了大把时间学习重构，在实际工作中却无法获得实在的利益。这对我们来说是非常糟糕的，我们不能容忍这种事情发生。 更重要的是，你之所以需要重构，决不会是因为它很好玩，而是因为你希望它能对你的程序有所帮助，让你能够做一些重构之前无法做的事情。 正如水草会堵塞河道一样，在一知半解的情况下做出的设计决策，一旦堆积起来，也会使你的程序陷于瘫痪。通过重构，你可以保证随时在程序中反映出自己对于「应该如何设计程序」的完整理解。正如水草会迅速蔓延一样，对系统理解不够完整的设计决策，也会很快地将它们的影响蔓延到整个程序中。要根除这种错误，一 个、两个、甚至十个单独的行为都是不够的，只有持续而无处不在的重构才有可能竟其功。 四个大型重构 本章之中，我们将介绍四个大型重构实例。这些仅仅是例子，我们并没有打算覆盖所有领域。迄今为止，绝大多数关于重构的研究和实践都集中于比较小的重构手法上，以这种方式谈论大型重构，是一种非常新鲜的作法，这主要来自于：Kent 的经 \验。在大规模重构方面，Kent 的经验比其他所有人都要丰富。 Tease Apart Inheritance 用于处理混乱的继承体系——这种继承体系往往以一种令人迷惑的方式组合了数个不同方面的变化（variations）。Convert Procedural Design to Objects可以帮助你解决一个「古典」问题：如何处理程序性代码（procedural code ）？许多使用面向对象语言的程序员，其实并没有真正理解面向对象技术，因此你常会需要使用这项重构。如果你看到以传统的双层结构（two-tier， 用户界面和数据库）方式编写的代码，你能需要使用Separate Domain from Presentation 将业务逻辑（business logic）与用户界面（user interface ）隔离开来。经验丰富的面向对象开发人员发现：对于一个长时间、大负荷运转的系统来说，这样的分离是至关重要的。Extract Hierarchy 则可以将过于复杂的class 转变为一群subclass ，从而简化系统。