项目发展到一定程度，由于功用的增多，就会变得越来越臃肿，原来的架构，就会不能满足现有的需求，由于我们有很多最后规划的时候没有想到的事情，比如说在网站或者软件规模小的时候，我们并没有考虑到国际化，但随着发展，我们走出亚洲奔向世界了，这个时候我们需求全世界的人来用我们的产品，这个时候就需求重构了。

有人会问，既然这样，为什么我们不在软件最后架构搭建的时候把这些东西都想进去呢？由于我们在产品的前期开发中，不会有这么多的人力财力投入进去。而且产品是慢慢进化的，不是一天想出来的，功用也会随着增多。还有一个个重要的缘由，是技术不在停的进步，比如说原来没有OOP的概念，原来没有Web API的概念，原来没有AJAX的概念，所以我们可能会用一些老旧的技术。

公司的发展也是一种重要的缘由，在企业发展初期，公司往往是怎样快怎样来，前期次要是活下来，先生存再生活，一大早就想开个哈里法塔是不理想的，罗马不是一天建成的。我记得曾经有个这样的老板，一个小小的创业型公司，就想着要把系统打形成日访问量500万独立IP的系统（他当时说的是并发500万，呵呵，由于他不懂技术，我认为他想的是日访问量500万），这明显是不理想的，由于一方面，你的团队没有这个能力来盖这么高的房子，迫其而为之，而你又不懂技术，最终得到的只是欺骗。另一方面，我们退一步说，就算你真的有这样的团队，也没必要把资金浪费在这种不靠边的事上。除非你真的经过沙盘推演，有足够的决心和钱烧，让访问量很快达到这个水平，不过我觉得一个创业型公司达到500万独立IP不是一个很容易的事情。

很多公司基本上是这样，在初创的时候，也没有统一的规划，找人是怎样便宜怎样来，结果可能是找一帮实习生来干的活，形成一个项目什么言语都有，完全没有OO的概念，比如我曾经在搜房呆过几天，他们的代码就是如此，Asp.Net的代码完全写在aspx的页面里，一行代码望不到头，没有文档。软通很多的项目也是如此。所以很多时候，你别看公司很大，其实他们的IT项目也不规范，由于真正轨范起来的成本还是很高的，前期成本非常高。

扯了这么多，我们该说说重构了，当项目一而再再而三地修正的时候，大家都会很烦，老手可能习惯Ctrl+V和Ctrl+C，我是最痛恨这种行为的，我本身比较懒，只需是在两个地方或者可能会在两个地方出现的代码，我就会提炼出来。面对着一团乱麻的代码，或者技术曾经相当落后了的时候，我们就需求重构，重构是需求勇气的，我们需求去说服决策者，这很不容易，由于很多时候决策者不懂技术，你忽然说要重构就意味着大笔的投入，而对于决策者来说，投入就意味着要产出，这个时候技术担任人会面临着很大的压力，很多技术担任人会卡在这里，停滞不前，或者是采用折中的办法。

我们技术担任人应该就决策者关怀的事情和他谈，就是投入与产出的问题，这个是决策者都最想知道的问题，如果你能清楚地通知决策者，投入一千万可以赚下（或者省下）五千万，那么我想他会考虑这个事情，但技术担任人往往不擅长于谈判，或者是说责任心不足。

或者我们可以这样，把过去一年中，在IT中的投入列出，通知决策都有哪些是通过重构生避免的，同时把过去一年中的机会列出，通知他如果我们重构生哪些机会可以把握住。

然而，是所有的项目都需求重构么？项目重构都会成功么？未必！但是——我们需求有勇气打破僵局，不破则不立，当原有的系统曾经不能满足如今的需求时，我们就打破它，建立一个新的规则。