代码重构在软件开发中经常遇见，重构的原因很多，例如：项目存在的时间久了，代码经过很多人维护已经变得千疮百孔，稍微改动一个地方就可能会出现莫名的bug，这是软件开发中难免的情况。除了维护成本高昂外，还有就是新的需求过来后，老的架构已经无法支撑或者支撑的成本非常高，这个时候就必须考虑重构。
代码重构本身技术上没有多大难度，但是什么时候应该重构，这个往往很难把握。经常会出现的情况是，没有早点重构，在业务需求和用户量不断飞涨时，老的系统已经不允许重构，因为这样做很可能导致系统不可用。所以就会出现干脆花更大的代价来重新做一套系统去替代老系统。这个看似比较完美的方案其实是有许多暗坑的。
首先，你需要有充足的开发资源来保证同时兼顾新老版本系统的开发。对于资源相对匮乏的公司来说，成本显然是第一要考虑的，因为新需求需要在两套版本上同时实现，而业务并不会因为技术的重构而停止发展。所以需要双倍的资源投入，但是在一些大公司这个情况倒不是问题，因为往往大公司不缺资源，team leader更需要新产品来提供KPI，所以有没有新产品产出是决策层非常看重的。是否需要新老版本并行开发需要根据当前的可用资源来考虑。
其次，开发了新系统需要将老的系统中所有的关键功能全部满足，否则老系统无法下线，新系统也不会受老用户喜爱。这样新系统的开发工作量会成倍增加，需要不断追赶老系统的进度。为了避免这种情况，所以产品经理都会尽量给老系统少提需求尽量只是修修bug和一些小需求，而将重点放在新版系统的开发上。那么这个带来的问题是用户感知不到产品的变化，产品满意度会打折扣。所以为了尽快弥补缺口期，新系统需要加班加点赶，工期一紧，那么必然会带来很多潜在问题。如前期业务模型分析不足导致数据模型也设计的不合理，或者产品经理在时间压力下没有完全想清楚产品怎么做。这样其实又是为新系统的下一次重构埋下了伏笔。
那么到底该不该重构，何时重构，可以参考 杜欢 老师的文章 http://www.infoq.com/cn/minibooks/architect-201608。里面总结了一个衡量重构静收益的公式：
重构净收益 = 旧架构开发效率 - 新架构开发效率 - 重构成本 - 迁移成本
公式中每个项目的解释：
- 旧架构开发效率：采用旧架构完成需求所需要的时间；
- 新架构开发效率：采用新架构完成需求所需要的时间；
- 重构成本：重构所需要的时间，这一般是一次性投入；
- 迁移成本：为了解决新架构带来的额外问题所花费的时间，包括新架构的Bug修复、业务测试回归成本、学习成本等。
在实际的工作中可以参考该公式来估算一下，也可以结合表格对比的办法列出，现有架构的优缺点，重构后的优缺点，设置好权重以及投入成本来比较选择。
以我的经验如果不涉及核心架构的制约，那么可以采用微重构，或者模块化重构，每次迭代只做一小部分重构，分块儿不断的优化代码结构保证代码是可以被可持续开发的。当然如果核心架构已经无法满足业务的变化，只能被迫重构甚至重做时，那么需要做可平滑迁移或兼容老的功能和数据。否则的话，老的系统下不掉，新的系统又满足不了需求，那会带来更多的麻烦和压力。
来源：https://www.cnblogs.com/xiangxiangruolin/p/5768125.html