面对软件的腐化，你选择重做还是重构？

经过了激烈的讨论、反复的评审，包括产品经理、需求分析师、开发团队、测试团队在内容的研发专家们达成了一致。系统设计居然还保持清晰，更为幸运的是，在系统发布的时候，设计依然保持清楚，虽然编码不够规范，也没有太多注释，但与文档基本一致的。接下来就是见证神奇的时刻–事情开始变糟，直至不可收拾。“软件像一片坏面包一样开始腐化。随着时间的流逝，腐化蔓延、增长，丑陋腐烂的痛处和疖子在代码中积累，使它变得越来越难以维护。最后，即使仅仅进行最简单的变更，也需要花费巨大的努力。以至于开发人员和一线管理人员强烈要求重新设计。”（Robert C. Martin，《敏捷软件开发：原则、模式与实践》，P79）多么形象的描述，然而这样的故事在一个个外国的、中国的公司里，一次又一次的轮番上影，永不落幕。遗憾的是，他们所要求的重做，大多以失败收场。

一个正在运营的系统，尤其是互联 的系统，有着大量的历史数据，重做必须面对历史数据的迁移问题，这将是一个工作量庞大且风险极大的事情。很多时候，大家把系统腐化归结于日常需求变化太多，疲于应付日常需求而忽视系统优化。但既然现有人力已经难以应付日常需求，又何来大量人力去重新设计一套新的系统？也有人把问题归结于原来的设计考虑不周到，现有系统已经不适用新的变化。是的，事情总是变化的，而开发人员的智力总是有限的，难以一下子把所有的问题都预先想到，把所有将来要出现的需求都预计得到。既然过去的系统会因此而存在缺陷，新做一套系统也未必就是设计周全的，未必都能适应将来的变化，新设计出来的系统存在一定的缺陷也是必然的。人还是原来的人，观点还是原来的观点，做事方法还是原来的做事方法，即使新做一套系统且很幸运的替换了老系统，2年或者3年之后历史还会重演。

好像说得有些悲观，那么问题是否就没有解决途径了呢？在探索解决问题的路径之前，需要我们去探讨问题的根源在哪里？

首先，新的需求在源源不断的提出，也就是说原来的设计没有办法满足新的变化，我们的系统需要不断的去应付这些新的需求。我们不可能指望一次性设计就满足将来所有变化，变化是必然的，有了变化，我们的系统能够通过不断的优化来满足新的需求，这就能够持续的保持系统进步、保持系统活力。需要改变的是我们的观念：不是去拒绝而是要拥抱变化；不是通过一次性的过度设计去满足未来变化，而是在新的变化出现的情况下通过增量设计去持续改进系统，持续迭代系统。

其次，新的需求往往都在时间上很急迫，开发资源往往不够，而且很多开发人员对原有的设计思路不太熟悉，不断的在原来系统的基础上打补丁，每次补丁又遗留一些隐含问题，导致设计不足或设计退化。“数据结构的构造非常随意，甚至近乎不存在，任何东西都要与其他东西通信。所有重要的状态数据都可能是全局的。在状态信息被隔开的地方，需要通过错综复杂的后端通道杂乱地传递，以绕开系统的原有设计”（《重构与模式》）由于疏于对编码规范的管理，程序变得越来越不可读，而设计文档与程序越来越不匹配，以至于下一个开发人员都得诅咒前任开发人员。这样的系统隐含问题却越来越多，每次修改都危机重重，一不小心就踩上炸弹。这个时候，系统的开发速度变得越来越慢，直至所有人都恨不得躲得远远的，叫嚣要扔掉它。

解决问题的方法就是“持续重构”。不是推翻重来去做，而是在日常的需求开发中持续的重构。

问题看似很简单，实践起来却很痛苦，持续重构不仅仅是观念问题，还存在方法问题。首先要求我们程序员保持持续重构的习惯。其次要求开发人员具备优秀设计能力和敏锐的洞察力，能够看透问题本质顺利寻找的优化路径，而这往往是很多开发人员所不具备的。最后，在重构的同时，需要保持编码的规范，使得系统保持干净、简单，增强程序的可读性。上述的改变，是开发风格的一次范型转变，需要面对观念、方法、执行力等问题，其改变过程可能是艰难而漫长的，需要有强有力的推动才有成功的可能。