大多数架构师在回顾重构过程的时候都会感慨：“要是早点重构就不会这么麻烦了”，不过在下一次重构到来之前，永远没人知道“早点”究竟是何时，同样的感慨会反复被提起。那到底有什么办法找到最合适的重构时机？本文作者杜欢是滴滴平台产品中心技术总监，他就这个问题进行了探讨，不一定能找到最终答案，或者这个问题本身就没有答案，但希望能给读者一些思路，如果你有想法，别忘了评论。
重构并非难在怎么做，而是难在何时开始做。
对于一个高速发展的公司来说，停下来做重构 从来就不是一个可接受的选项 ，“边开飞机边换引擎”才是这种公司想要的。当代码还不是很混乱的时候，重构的必要性不高，相比不小心重构出错让引擎熄火的风险来说，得过且过可能反而是一个 明智之选 。
于是各种技术债就这样慢慢积累起来，直到业务因为各种技术债快跑不动的时候，架构师们才不得不用一些激进的重构手段快速的解决历史顽疾。如果重构获得了成功，大多数架构师在回顾过程的时候都会感慨：“要是早点重构就不会这么麻烦了”，不过在下一次重构到来之前，永远没人知道“早点”究竟是何时，同样的感慨会反复被提起。
就没有什么办法找到最合适的重构时机么？可能真没有。不过通过评估重构收益可以早一点察觉到重构的必要性，从而至少能做到稍微“早点”。
重构的根本目的就是让业务能跑的更快，达到更高的开发效率。对于一般工程项目而言， 基本不会出现无法实现的需求 ，只要有充足的时间，需求总能被实现。在这里提到的“需求”包含业务中所有明确或潜在需要的东西，并不局限于产品需求，各种性能、可用性、柔性指标也都是需求的一种。很显然，在需求一定的情况下，开发效率越高所需要花费的时间或人力就会越少，业务就能跑的更快。
并不是任何的重构都能达到预期的效果，因为重构本身需要付出成本，重构之后的架构也不一定真的能提升开发效率，只有通过估算发现“重构净收益”为正才是重构的好时机。
“重构净收益”由以下公式定义：
重构净收益 = 旧架构开发效率 – 新架构开发效率 – 重构成本 – 迁移成本
公式中每个项目的解释：
- 旧架构开发效率：采用旧架构完成需求所需要的时间；
- 新架构开发效率：采用新架构完成需求所需要的时间；
- 重构成本：重构所需要的时间，这一般是一次性投入；
- 迁移成本：为了解决新架构带来的额外问题所花费的时间，包括新架构的Bug修复、业务测试回归成本、学习成本等。
重构净收益是一个长期收益，随着需求不断演进新旧架构开发效率带来的差异会日渐明显，直到能够超过重构成本和迁移成本，如果估算发现收益为正，那么意味着当前就是重构的好时机，应该着手准备了。
举个使用公式的例子。
假设有一个服务由于长期开发不注重代码复用，重复代码颇多，开发一个新功能，比如增加一种新的通用参数，就不得不修改几乎所有接口的代码，那么是否值得消除重复代码？按直觉来说，答案应该就是肯定的，但实际上并非如此，这些情况基本可以用“重构净收益”公式来解释。
如果这个服务基本不再维护 ，旧架构并不会持续的带来开发成本，假如重构成本大于使用旧架构完成需求的时间，那么重构收益就一定为负，重构不值得做；
如果重构会带来很大的迁移成本 ，比如会造成几十万行无人维护缺乏测试覆盖的旧代码发生改动，无人能够保证改动正确性，那么就算重构本身成本不高（假设能够利用一些脚本大批量抽取重复的代码），这种重构也是值得商榷的；
如果重构之后的新架构过于超前 ，学习门槛很高，当前团队很难可靠的掌握高效的开发方法，最终这些学习成本会被放在迁移成本之中，假如过大也意味着收益为负，重构不值得做或者必须换一种更让团队容易接受的方案。
限于篇幅，这里就不展开说明公式的更多用法，大家不妨拿自己工作中的例子套用试试，看是否有帮助。需要特别注意，就算重构净收益为正，也并不意味着应该停下业务做重构，重构带来的是长期收益而业务需求代表着短期收益，架构师有责任在确保业务正常运转的情况下为未来做准备。
摘自：http://www.weixinla.com/document/42395795.html
