殇
那估计重构之后的效果和重构以前没什么差别，甚至性能更差。
亲历者说明
榻榻米的榻榻
先从接触过的几个老项目经历来谈谈，对于老项目来说，大家在初步接触的过程中，大多总是抱着抵触的情绪，甚至有些是蔑视。总喜欢对以前的代码挑出一大堆的问题，接着就开始抱怨代码、抱怨以前的开发人员，经过一段时间郁闷的抱怨阶段后，处于职业的责任心，就很想去改变这一切，希望把自己认为好的方式给带进来，于是接下来的工作就是重构代码了。 这也许大多数开发人员都经历过，这种经历是辛酸的（因为重构工作虽然重要，但是得不到过多的认可，目前国内关注的是可用性，对于代码质量并没有得到应有的重视），也是甜蜜的（风雨之后总会有彩虹）。对于年轻的开发人员来说，见到彩虹的过程是痛苦、漫长地。他们都是在失败中成长，这些失败除了经验外，主要是由于太急功尽力了，盲目的重构！ 盲目主要体现在： 1、在还没有对系统整体架构有个清晰认识的时候，就想用自认为新的技术或架构来替换。 2、根本不分析现有系统架构或程序存在的弊端，只是一味地谈设计模式，以设计模式中固有的一套来重构（在重构中，它只作为一个参考，而不是一个依据。） 3、重构比较随性，每个版本的开发都跳出架构之外随意带入新的设计思想 这种盲目重构后给系统会带来更多问题： 你会发现当你重构完后你的系统运行效率变低了， 系统中同时存在多种思想，新加入人员更难接手， 由于你没有完全了解系统，反而在你的重构当中带来了很多重复代码， 最悲剧的是你重构后的代码也被其他人当成垃圾，而进行重构。 那么我们怎么消除盲目呢！？ 首先，了解目前项目是否存在问题，存在什么问题，这些问题是否能通过重构来解决，如果能，才进行重构，你的重构时间是需要公司给的，老板不会因为你说依赖性强偶合性低就同意的，你必须要通过问题来让他认识，关键的是只有通过问题才能得到重构时间和资源，并且你的工作才能得到认可，这是一个很现实的情况。 接下来，你要确定重构的对象，是针对架构还是局部代码，并且去设定一个理想的目标（为什么是理想的？因为我们不可能一步到位，理想和现实是有差距的，但是我们要做的是尽力去往理想上靠拢）。 如果是针对架构进行重构，那么这可不是一件轻松的事情，再真正开始之前需要做到以下几点： 1、全面的了解系统的过去，包括以前的架构/技术背景、业务需求
时事热闻
有点奇怪，你們确定項目重构這個目標的時候，沒有论证過的嗎？为什么要重构、如何重构、如何保证工作交接，這些都要论证過具體措施之後，才決定重构的呀。都确定要重构了，還問如何保证业务代码不动，那证明确定重构的時候就沒考慮好這一方面，不會是拍脑袋決策的吧？項目要到重构这一步，肯定有它不得不如此的充分理由，既然如此，详细考察怎麽做就是必須的。如果舊項目的代码可以讓你輕鬆保证不破壞业务，那麽它的设计的編寫已經基本到位，又何须重构！就是因為原系統一团糟，不能靠修修补补解決，才要重构。
TonyDeng
重构的目的是在不改变系统行为的前提下，对代码进行重新优化实现。单纯的用业务代码限定重构的范围不是特别明确。但是，重构一般要遵循渐进重构原则，切忌大规模的推倒性的全盘重构。
疯狂架构
业务代码不动，那重构的意义呢？重构之前，不是应该先梳理一下业务，确认哪些是可以优化，可以裁剪的，然后再重构
负利率哦
很难，应该说不可能，整个项目都重构了，就等于重新做是一样的，业务代码的变动也是必然的。
