系统重构是个什么玩意儿

如题，系统重构是一个什么玩意儿呢？大家可能有很多的不同看法：

1.系统重构是那些系统架构师、技术大牛玩的高端玩意儿，跟咱普通屌丝不懂，跟咱没啥关系。

2.系统重构就是改代码，大改特改那种，整个重来一遍，这个比较邪恶，比较容易改出事儿，还是不要轻易尝试。

3.我知道系统重构，也知道它能改善遗留系统，但我还是不敢轻易尝试，因为改出问题来怎么办，还是算了吧。

然而我认为，现在我们对系统重构有太多的误解，以至于我们还不怎么了解它，就已经将它拒之门外。什么是系统重构呢？我认为，不同的人、不同的角色在看待这个问题时，答案是不一样 。

作为普通程序员，纯屌丝，重构不是一个阳春白雪的高级玩意儿，它是一种习惯，一种良好的编程习惯。这种习惯让我们迅速由菜鸟转变为大牛，可以编写出高质量、优秀的程序。怎么这样说呢？举几个例子吧。

假如你在实现某个功能的时候，发现与之前已经写好的某个功能相似或者相近，你应该怎么办呢？相信你下意识的动作是ctrl+C，然后是ctrl+V。复制一段代码是简单的，但你知道吗，这样做将给系统带来多大的隐患。它将使系统日后的维护变得困难，因为这段代码如果被复制了数遍，一旦日后需要变更，所有被复制的代码都必须要变更。散落一地的被复制代码将会使我们的系统日后越来越难于维护，而你千万不要成为造成这一切的恶人。

然而，实现代码复用并不容易，最关键是，原有的代码并不能立即为你的新程序所利用，因为它们往往是与其它代码耦合在一起。情况往往是这样，你发现既有的某段代码你可以利用，但这段代码是在某个类、某个函数中的一个部分，而这个类或函数的其它部分不是你需要的。这时候，如果你是一个优秀的编程人员，你应当运用重构中“两顶帽子”的设计模式设计：先不要添加新功能，而是重构原有代码，以适应新需求，然后在此基础上添加新功能。

具体怎么做呢？你可以有两个选择，抽取工具类与抽取父类：

抽取工具类。第一步，运用重构中的“抽取方法”，将你需要的代码抽取到另一个工具类中，形成一个公用方法，让原程序变为对该方法的引用；第二步，在你的新功能中引用该方法。

抽取父类。首先还是运用重构中的“抽取方法”，将你需要的代码抽取出来，放到一个新函数中，放在原有的类中。然后对该类抽取出父类来，将这个需要公用的新函数升级至父类中，这样“两顶帽子”的第一步完成；将你的新类设计成这个父类的子类，实现你需要的新功能。

再假如，你现在拿到一个新需求，是在原有功能的基础上实现的功能扩展，你应当怎样做呢？下意识地，你拿着原有代码就开始改了，是不是？把原有代码用if语句框起来，然后将这些代码copy到if语句的另一端，然后开始改。我们常常骂别人代码写得烂，不要把编写很烂代码的责任都推给别人，其实自己也是烂代码的作者。正是我们对不正确编码的懵懂无知，不良习惯的听之任之，才使我们的系统越维护越烂，最后落到谁见谁头大的地步。

如果你是一个优秀的程序猿，你应当怎样做呢？好的代码设计，在添加新的功能时应当符合“开发-封闭原则（OCP）”。开发-封闭原则是这样描述的：我们开发的软件系统，对于功能扩展是开放的（Open for extension） 。这就意味着，当系统需求发生变更时，我们可以对软件功能进行扩展，使其满足新的需求。同时，我们对软件代码的修改应当是封闭的（Close for modification）。这意味着我们在修改软件的同时，不会影响到系统原有的功能。毫无疑问，这里的重点在于后一句话。

软件总是在功能扩展，这是不争的事实。然而需要满足封闭原则，即我们在添加新功能的同时不能修改既有代码，这怎么可能呢？怎么可能在添加新功能的时候不修改既有代码呢？许多人在看到这一点时就晕菜了。然而它是可能的，当我们做出合理设计时。是的，当我们做出合理设计时，准确地说是适时地设计出可扩展点时，我们就可以做到只添加新代码而不修改既有代码。但是，能实现OCP原则的前提是我们已经做出了可扩展设计，因此我们开始走向另一个极端，我们开始不节制地进行可扩展设计，即使这些可扩展点从来没有被扩展，因而形成过度设计。

过度设计使我们坠入了另一个轮回：期望的变更没有发生，而不期望的变更却发生了。期望的变更没有发生，使毫无价值的设计白白耗费我们的资源；不期望的变更却发生却使我们悴不及防，最终陷入绝望的境地。

运用重构方法解决了我们的问题，改变了我们的设计思路。我们不再需要为不确定的未来而埋单，我们只需要活在当下。我们不再需要做那么多的设计，我们只需要做现在需要的设计，让我们的设计尽量简单。那么当日后需求变更真正到来时怎么办呢？不要惊慌，当需求变更真正到来时，运用重构方法，重构原有的代码，设计出可扩展点，然后再按照OCP原则添加新的功能。重构原有的代码时，我们改变了我们的代码，但我们系统原有的功能没有变，因此我们可以有效地测试原有功能。然后添加新功能，因为有了可扩展点的设计，我们能符合OCP的设计，保证我们的设计质量，问题得到解决。

然而，也许你还是一头雾水，不知道具体该怎么做？没关系，饭要一口一口吃，路要一步一步走，至少我们开始明白，写出好的代码不容易，需要我们去学习，而系统重构就是实现这一目标的捷径。（续）

相关文档
遗留系统：IT攻城狮永远的痛
需求变更是罪恶之源吗？
系统重构是个什么玩意儿
我们应当改变我们的设计习惯
小步快跑是这样玩的（上）
小步快跑是这样玩的（下）
代码复用应该这样做（1）
代码复用应该这样做（2）
代码复用应该这样做（3）
做好代码复用不简单（1）

特别说明：希望网友们在转载本文时，应当注明作者或出处，以示对作者的尊重，谢谢！

工具方法共用好，不同业务就是有相同的调用，也还是分开好。
要是几不同个业务，在某处共用了相同代码。哪天需求一变更，头就大了。

代码复用以后的变更，这确实是一个问题，却不是一个解决不了的问题。运用“两顶帽子”的方法合理地进行重构，它就可以完美地得到解决。
这个问题我会在代码复用部分着重进行探讨。