关于重构

 

对于影响面比较小的重构，比如代码优化等，可以穿插在业务功能开发中完成。

而大规模重构，意指内部对整个系统进行架构、甚至核心代码的重写，但是外部功能不发生改变。

此时面临两大挑战：

1. 保证业务功能保持不变-无功能遗漏，并且无功能改变。
2. 新老系统是否需要并行运行一段时间，如果需要，如何做。

通常存在三种重构方式：

1. 一次完成——定义最终状态的结构，然后将代码一次完成。
2. 分而治之——将一大团乱七八糟的代码分为两段，然后重复这样的操作，直至完成……
3. 压制（Strangling）—压制类

无论那种方式，都可以按照如下步骤进行循环优化

1. 分析： 定义 想要的结果，并找到达到目的的方法。
2. 实现： 应用重构技术 来相应地改变代码。
3. 稳定： 应用一些方法， 确保实现的结果是 持久的。

另外就是天皇牌”（Mikado）方法

修改代码就像进行天皇牌游戏一样。当你想要对代码库做出修改时，几乎无法以正确的方式做出准确的修改 你需要做些准备、移动代码、抽取类等等。我们很少会第一次就抓到天皇牌。 更多的是，在“重构天皇”可用之前，你需要做一系列的变动，有条不紊地向你的牌堆的底部进发，以达到目的。

使用天皇牌方法，首先要记住最终的目的。对于任何需要重构的代码，我们首先要创建一幅依赖图，在上面写下最终的目标。下一步是识别出想要达到目标所需要的直接前提，然后以这种方式继续识别依赖关系，直到达到没有任何前提或者依赖的叶子节点。 这可能是开始重构最好的方式。一旦有了依赖关系图，那么核心思想就是从叶子节点一步一步回溯，直到达到目标。

这种方法强调了撤销操作的重要性，团队不应该害怕因为回退而抛弃一些改变。他还建议不要停止分析，而应该从最基本步骤开始，然后理解顺序。现在他们已经提供了关于“天皇牌”方法的书的草稿版本。