项目发展到一定程度，因为功能的增多，就会变得越来越臃肿，原来的架构，就会不能满足现有的需求，因为我们有很多最初规划的时候没有想到的事情，比如说在网站或者软件规模小的时候，我们并没有考虑到国际化，但随着发展，我们走出亚洲奔向世界了，这个时候我们需要全世界的人来用我们的产品，这个时候就需要重构了。
有人会问，既然这样，为什么我们不在软件最初架构搭建的时候把这些东西都想进去呢？因为我们在产品的前期开发中，不会有这么多的人力财力投入进去。而且产品是慢慢进化的，不是一天想出来的，功能也会随着增多。还有一个个重要的原因，是技术不在停的进步，比如说原来没有OOP的概念，原来没有Web API的概念，原来没有AJAX的概念，所以我们可能会用一些老旧的技术。
公司的发展也是一种重要的原因，在企业发展初期，公司往往是怎么快怎么来，前期主要是活下来，先生存再生活，一大早就想开个哈里法塔是不现实的，罗马不是一天建成的。我记得曾经有个这样的老板，一个小小的创业型公司，就想着要把系统打造成日访问量500万独立IP的系统（他当时说的是并发500万，呵呵，因为他不懂技术，我认为他想的是日访问量500万），这明显是不现实的，因为一方面，你的团队没有这个能力来盖这么高的房子，迫其而为之，而你又不懂技术，最终得到的只是欺骗。另一方面，我们退一步说，就算你真的有这样的团队，也没必要把资金浪费在这种不靠边的事上。除非你真的经过沙盘推演，有足够的信心和钱烧，让访问量很快达到这个水平，不过我觉得一个创业型公司达到500万独立IP不是一个很容易的事情。
很多公司基本上是这样，在初创的时候，也没有统一的规划，找人是怎么便宜怎么来，结果可能是找一帮实习生来干的活，造成一个项目什么语言都有，完全没有OO的概念，比如我曾经在搜房呆过几天，他们的代码就是如此，Asp.Net的代码完全写在aspx的页面里，一行代码望不到头，没有文档。软通很多的项目也是如此。所以很多时候，你别看公司很大，其实他们的IT项目也不规范，因为真正规范起来的成本还是很高的，前期成本非常高。
扯了这么多，我们该说说重构了，当项目一而再再而三地修改的时候，大家都会很烦，新手可能习惯Ctrl+V和Ctrl+C，我是最痛恨这种行为的，我本身比较懒，只要是在两个地方或者可能会在两个地方出现的代码，我就会提炼出来。面对着一团乱麻的代码，或者技术已经相当落后了的时候，我们就需要重构，重构是需要勇气的，我们需要去说服决策者，这很不容易，因为很多时候决策者不懂技术，你忽然说要重构就意味着大笔的投入，而对于决策者来说，投入就意味着要产出，这个时候技术负责人会面临着很大的压力，很多技术负责人会卡在这里，停滞不前，或者是采用折中的办法。
我们技术负责人应该就决策者关心的事情和他谈，就是投入与产出的问题，这个是决策者都最想知道的问题，如果你能清楚地告诉决策者，投入一千万可以赚下（或者省下）五千万，那么我想他会考虑这个事情，但技术负责人往往不擅长于谈判，或者是说责任心不足。
或者我们可以这样，把过去一年中，在IT中的投入列出，告诉决策都有哪些是通过重构生避免的，同时把过去一年中的机会列出，告诉他如果我们重构生哪些机会可以把握住。
然而，是所有的项目都需要重构么？项目重构都会成功么？未必！但是——我们需要有勇气打破僵局，不破则不立，当原有的系统已经不能满足现在的需要时，我们就打破它，建立一个新的规则。