别动不动拿"重构"说事

别动不动拿"重构"说事

自从Martin Fowler先生将Refactoring这个概念带到了中国，许多程序员都如同获得了一个通行金牌似的，随时可能提起"Bad Smell"和"重构"。

从我的心里来讲，我并不反对重构。但我反对不考虑项目情况的盲目重构。

回想一下，当我们在考虑系统需要重构的时候，我们都考虑了那些因素？特别是大范围的系统级别的重构。由于小型重构涉及面较小，所以下面的很多原因都是针对大型重构进行论述的。

"Bad Smell"也许是我们第一个说出的原因。讲起这个，我仿佛就听到有无限个非常有道理的理由，能从重构者嘴里说出。其中最经常的理由就是：现在不重构，以后也得重构，显然现在重构的代价更小一点。

那么，我们就因此而准备进行重构了吗？

至少我看到很多项目最终都选择了重构。

选择重构的心理，应该和我们程序员的追求完美的个性非常相关。软件不断的进行重构，那么软件的质量就能越好。最关键的是，我们越来越将代码修改得让自己感觉没有遗憾。请允许我这样来分析重构者的心理，但是你不得不承认，往往决定一件事的时候，潜意识很容易战胜理智。

我的问题是，我们重构的时候，真正理性而全面的考虑过吗？

第一、重构的目标是什么？是系统的完美吗？是项目的顺利完成！我想提出一个大家不一定能够接受的标准，任何系统都是可以也是必然存在足够多的缺陷的。真正的成功，是指项目的成功，而并不是指创造一个完美的系统。重构的需要，是项目开发过程中，根据需要而采用的开发方式。只要保障足够程度的软件架构，重构是可以不进行的。

第二、重构的基础具备了吗？在很多成功的经验中，都明确地指出，重构需要有足够的单元测试支持。而且最好是自动化的。目前，很多项目并不具备这样的基础。对于单元测试的问题，我在最近的几篇关于单元测试的博文中也分析过现状和原因。总体说来，真正具备重构的基础的很少。

第三、重构对成本是否考虑周到。我们知道，重构必然会影响到现有项目的进度。这个进度的影响是否是可以接受的？你先不要忙着回答这个问题。能不能接受不是重构者说的，而是市场说的。这个时候，一个三方的沟通会议必不可少。

第四、重构的策略是否制定。重构这件事，并不是简简单单地就去将所有需要重构的地方进行重构。重构的范围越大，这个策略的需求就越高。过分乐观地估计重构的过程，往往是重构失败的重要原因之一。在对项目进行系统级别重构的时候，针对重构的范围规划，进度控制是非常必要的。这个不能要求重构者完全把控。本着适合的人做适合的事的原则，项目经理，应该充分考虑这方面的问题。

其实说到底，不要因为喜欢重构而重构，不要因为重构而重构。在重构之前以及重构的过程之中，我们都必须进行足够的保障，才能保障成功地完成。