重构是改革,重写是革命

如果将一个软件系统或项目比喻成一个国家，那么重构就好比是改革，推翻老的系统，重写一个新系统就好比是革命。重构就是戊戌变法，重写就是辛亥革命。革命总是比改革要付出更多的代价，因为革命是要流血的。重写一个系统也是如此，要付出比重构更大的代价，因为原有的代码基本上全抛弃，公司曾经为那些编写老系统代码的程序员支付的工资就全付之东流了。但是，国内大部分软件公司仍然每隔三四年就上演一次这样的悲剧。究其原因，乃是不知道用重构这样小的代价去改善既有代码的设计。即便听说过重构，但却对重构的技巧、本质和意义一知半解，结果往往打着重构的旗帜，却做着重写的工作。

      重构是每天都应该做的工作。那些说“等我们n.X版本发布以后，有时间了，我们好好重构一下整个系统，这个系统中的代码太乱了”，这不是重构。既然知道代码乱，有坏味道了，就应该立即着手重构。

      重写往往是从来不重构造成的，代码越来越臃肿、冗余、混乱、腐朽，设计上发现的漏洞越来越多，实在无法在原有系统上维护和扩充代码了。于是开始所谓“重构”，却发现无从下手，无法完成，只好重写。这好比一个朝代无法延续了，于是来一场起义，建立一个新王朝，时间长了，又陷入腐朽，又被推翻，周而复始。人事间的事往往都如此，新系统写好后，三五年后又是推到重写。

      为什么从来不重构呢？国内的公司很多还处于瀑布开发模式的思维中，认为设计阶段完成后是编码阶段，编码阶段是不能修改设计的。目前先进的软件工程思想如敏捷开发都是迭代开发模式，设计是在多次迭代的过程中逐步完善的。尤其是XP编程，完全没有设计阶段的概念，这对很多国内的软件开发者是个革命性的思想。

      事实上，国内的软件设计者大多从业时间不长，工作两三年就敢做一些复杂系统的架构设计，经验、技术和能力的不足导致他们的设计往往是拙劣、丑陋和低效的，漏洞百出。瀑布开发模式往往有形无实，到测试和维护阶段总是能发现设计上致命的问题。这时要去改正这些设计错误，需要修改代码。但代码往往是混乱和低质量的，查错困难，修改的难度非常大。大部分项目经理往往是采取一种治标不治本的办法解决问题，而不去惊动原有的设计。最后导致设计的问题积累得越来越多，直到所有的人都无法忍受了，就重写。

      这其中涉及到编码过程中的质量控制和代码评审的问题，大部分软件公司都没有代码评审，也没有别的代码质量控制的办法。其次，如果代码质量还可以忍受，因担心重构后不能保证原有的功能和特性而不敢重构，这就涉及到敏捷开发原则中提到的一个原则：勇气！大多数程序员似乎都缺乏这个特质——勇气，是的，改变的勇气。虽然勇气不是个技术问题，但没有勇气，重构也是无法完成的。

      做什么事情都需要勇气，不仅仅是开发软件！