根据定义，重构是指在不改变外部行为的前提下，改变程序内部的实现结构。人们经常会在程序的非功能的属性进行重构，从而提高代码的可读性以及可维护性。即便是经验丰富的敏捷开发者，在进行大规模的重构时也是如履薄冰。敏捷社区对处理大规模重构的几种方式进行了讨论。

在最近的讨论中，Andreas想知道处理大规模重构的三种可能方式之外最好的方式。他的方式包括：

1. 一次完成：定义最终状态的结构，然后将代码一次完成。
2. 化整为零：将一大堆烂泥般的代码划分为两块，然后继续划分下去，直到完成为止（注:有点类似递归的味道）。
3. 持续抑制(Strangling): 抑制类（注：感觉有点别扭）

大多数的调查对象都认为一次性完成基本没有成功的。Aaron Digulla 建议他在整个职业生涯中使用的持续抑制的方法。这种方法就是持续的将不好的代码转化为可以测试的优质代码。这种策略的好处是，由于你是从很小的代码片段开始，所以风险一般很小。David Hall and Shane MacLaughlin强调了对于化整为零的方法，对于所涉及代码的场景，要编写足够多的测试是非常重要的。也有人建议完整的重写得了，但是这种方式也有自己的挑战。

Sibylle Peter and Sven Ehrke提到他们遵循的方法：先进行评估，然后指定一个大规模网站重构的计划。然后对于重构的每一步，他们遵循以下三个步骤：

1. 分析：定义期望的结果以及如何实现
2. 实现：应用重构的技术，相应得完善代码
3. 稳定化：应用一些方法，来验证实现的结果是稳定的。

另外一种对大规模系统进行重构的方法是天皇法，Daniel Brolund and Ola Ellnestam 将天皇法和工作联系在一起，并且根据天皇游戏 来命名之。（注：这里有天皇游戏的中文介绍： 天皇游戏）根据这种方法：

     代码变动就像天皇游戏。当你打算对代码库做修改的时候，你几乎不可能立刻完成按照你期望的改变。你不得不准备一些东西、移动代码、扩展类等等。第一步就拿到天皇是几乎不可能的。通常的情况是，在重构天皇（Refactoring Mikado）可行之前，你需要做一系列的移动，从而到达牌的底部，直到实现目标。

天皇方法开始于你将目标牢记在心。对于每个需要重构的代码库，创建一个以最终目标为起点的依赖图，下面一步是确认直接的依赖点或者先决条件，直到到达一个没有依赖或者先决条件的节点（我们称之为叶子）。叶子节点是开始重构的最好的起点。一旦依赖图完成，我们要做的就是从叶子节点开始，一步步的直到达到目标。这种方法非常强调“UN-DO”的重要性，因为有了“Un-do”，team就不会会回滚或者丢弃改动而担心了。它还建议不要优柔寡断，要从最基本的步骤开始，然后理清推论。天皇法这本书的draft copy可以在这里获取、

目前为止，尽管大规模重构很难实现，它的关键在于确认好起点，然后沿着目标逐步前进。

原文：http://www.infoq.com/news/2010/08/large-scale-refactoring

注：个人认为，大规模重构最重要的就是不要想着一口吃成胖子，定义好一个大的目标，然后从最基本的if else 开始，不求快，只求稳，逐步接近目标即可。