重构的欲望与方向：让现有的代码实现更容易扩展

如果你是一个拥抱Agile的开发人员，“重构”肯定会紧紧围绕在你的思维中。而作为开发人员，也应该时刻有重构的欲望。

事实上，上面那个命令行类，已经很成熟了。在经过几年的补充之后，已经需要支持十几个任务了。我们姑且用ApplicationManage来代替这个命令行类的名称。很多年以后，这个类成为一个非常“臃肿”的类，一个2000多行的类。

这个类的命令模式大致这样，每个任务都有自己特定的一些参数：

ApplicationManager –upload –domain AAA –archive user ······

ApplicationManager –deploy –domain AAA –app appname ······

如果这个时候，你需要新增一个任务，比如我们需要达到这样的效果：

ApplicationManager –newtask –domain AAA –file tesfile ······

这个时候，你必须修改ApplicationManage很多地方的代码，按照原有的代码逻辑和结构在不同的地方增加代码：

◆我需要在解析输入参数的地方，增加对几个新的参数的解析。

◆我需要在校验的地方，增加对新参数的解析。

◆我需要增加对新Usage的支持代码。

◆我需要增加对新任务处理的支持代码。

新增一个新任务的支持，代码是并没有任何难度，也不复杂，但是我却要在一个类的很多处来回修改，要知道，这是一个2000行的类啊。——这就是“代码的坏味道”。

是的，如果这个时候，当你面对这么“难以忍受”的修改代码的时候，就需要萌发了“重构”的欲望。我们无须为“重构”寻找很多冠冕堂皇的理由，只此一条就足够了：觉得有更好的实现结构可以让我们扩展起来更容易。

重构的抉择：进行还是放弃?

当你想重构的时候，你就一定能够重构吗?这是需要进行时间成本、风险估算的问题。

ApplicationManager经过几年的发展，已经相当稳定。而Feature Freeze是时间是不允许被更改的。即使旧有的代码比较“臃肿”，但是经过时间检验的稳定性、正确性是无法被推翻的。结局只有一个：只能在旧有代码上添砖加瓦，来新增一个新任务的处理。

重构的计划就这么被迫放弃吗?

当然不应该放弃。可被用来修炼重构的机会本身就不多，“猎物就在眼前，怎能轻易放弃呢?”

是的，我不能把“重构”的代码提交到svn中，但是我可以在sandbox中进行啊！“重构，不一定非要在真实项目代码中”。事实上，在真实项目代码中重构是“非常危险”的行为，除非你有足够的时间和完整的设计思路，或者你的项目经理已经批准你进行比较大范围的代码修改。否则最好是在“sandbox”中实践和预研你的想法吧。

客户并不关心代码的实现好坏，只关心“功能、效率、稳定性”。有人会站出来把“扩展性”补充进来，是的，客户也关心“扩展性”，但是客户关注的“扩展性”只是外围的扩展，而真正很多内部实现的代码结构是“对客户透明的”，客户也不是关心那部分对其毫无“意义”的内部代码实现。

记住这个吧：没有人可以阻止你在“sandbox”放入你的想法和你的实践，除了你自己。——当然，你必须协调调好你的时间、你的工作。

晚上9点钟，当坐在家中电脑前的时候，谁还能阻止我们把自己的想法在“sandbox”中实践呢?灵感有时候是来自寂静的深夜!

重构之前：吸收原有设计思路的精华

重构并不意味着完全摒弃旧有的代码。很多时候，旧有的代码带着很明显的“历史烙印”：它们最初设计是满足当时的需求，满足当时快速实现某些功能的需求。在那时候，设计是正确的，但是随着后续功能需求的扩张，结构逐渐变的臃肿，从而变得越来越难维护。

上面的ApplicationManager就是这样一种情形。

但是，任何的组件，“存在就意味着它的价值”，它其中肯定存在一些“经得起历史考验”的设计思路。首先，我们应该找出这些“应该被吸纳的设计思路”。

偶尔也会听到有些开发人员抱怨旧有代码：重构它，还不如重写呢。——也许真的存在“一点价值都没有的旧有代码”，但这样的几率太小了。作为开发人员，应该本着“尽量能够吸纳旧有的设计思路的精华”的思路来进行重构。

ApplicationManager命令行类中就有一些不错的设计思路的：

(1)基本的处理过程是正确的：解析、验证、初始化、执行任务、打印Usage。

(2)提出了“任务”这个思路。认为一个命令行类是由很多Task组成的。

在代码实现方面，也有一些不错的可借鉴的“代码”可以借鉴学习，这里就不多叙述了。