重构并非难在如何做，而是难在何时开始做-搜狐

　　周五了，今天不发长文了，下班时间，和大家聊聊，重构的时机。大多数架构师在回顾重构过程的时候都会感慨：“要是早点重构就不会这么麻烦了”，不过在下一次重构到来之前，永远没人知道“早点”究竟是何时，同样的感慨会反复被提起。那到底有什么办法找到最合适的重构时机？本文作者杜欢是滴滴平台产品中心技术总监，他就这个问题进行了探讨，不一定能找到最终答案，或者这个问题本身就没有答案，但希望能给读者一些思路，如果你有想法，别忘了评论。

　　重构并非难在怎么做，而是难在何时开始做。

　　对于一个高速发展的公司来说，停下来做重构从来就不是一个可接受的选项，“边开飞机边换引擎”才是这种公司想要的。当代码还不是很混乱的时候，重构的必要性不高，相比不小心重构出错让引擎熄火的风险来说，得过且过可能反而是一个明智之选。

　　于是各种技术债就这样慢慢积累起来，直到业务因为各种技术债快跑不动的时候，架构师们才不得不用一些激进的重构手段快速的解决历史顽疾。如果重构获得了成功，大多数架构师在回顾过程的时候都会感慨：“要是早点重构就不会这么麻烦了”，不过在下一次重构到来之前，永远没人知道“早点”究竟是何时，同样的感慨会反复被提起。

　　就没有什么办法找到最合适的重构时机么？可能真没有。不过通过评估重构收益可以早一点察觉到重构的必要性，从而至少能做到稍微“早点”。

　　重构的根本目的就是让业务能跑的更快，达到更高的开发效率。对于一般工程项目而言，基本不会出现无法实现的需求，只要有充足的时间，需求总能被实现。在这里提到的“需求”包含业务中所有明确或潜在需要的东西，并不局限于产品需求，各种性能、可用性、柔性指标也都是需求的一种。很显然，在需求一定的情况下，开发效率越高所需要花费的时间或人力就会越少，业务就能跑的更快。

　　并不是任何的重构都能达到预期的效果，因为重构本身需要付出成本，重构之后的架构也不一定真的能提升开发效率，只有通过估算发现“重构净收益”为正才是重构的好时机。

　　“重构净收益”由以下公式定义：

　　重构净收益 = 旧架构开发效率 - 新架构开发效率 - 重构成本 - 迁移成本

　　公式中每个项目的解释：

旧架构开发效率：采用旧架构完成需求所需要的时间；
新架构开发效率：采用新架构完成需求所需要的时间；
重构成本：重构所需要的时间，这一般是一次性投入；
迁移成本：为了解决新架构带来的额外问题所花费的时间，包括新架构的Bug修复、业务测试回归成本、学习成本等。

　　重构净收益是一个长期收益，随着需求不断演进新旧架构开发效率带来的差异会日渐明显，直到能够超过重构成本和迁移成本，如果估算发现收益为正，那么意味着当前就是重构的好时机，应该着手准备了。

　　举个使用公式的例子。

　　假设有一个服务由于长期开发不注重代码复用，重复代码颇多，开发一个新功能，比如增加一种新的通用参数，就不得不修改几乎所有接口的代码，那么是否值得消除重复代码？按直觉来说，答案应该就是肯定的，但实际上并非如此，这些情况基本可以用“重构净收益”公式来解释。

　　如果这个服务基本不再维护，旧架构并不会持续的带来开发成本，假如重构成本大于使用旧架构完成需求的时间，那么重构收益就一定为负，重构不值得做；

　　如果重构会带来很大的迁移成本，比如会造成几十万行无人维护缺乏测试覆盖的旧代码发生改动，无人能够保证改动正确性，那么就算重构本身成本不高（假设能够利用一些脚本大批量抽取重复的代码），这种重构也是值得商榷的；

　　如果重构之后的新架构过于超前，学习门槛很高，当前团队很难可靠的掌握高效的开发方法，最终这些学习成本会被放在迁移成本之中，假如过大也意味着收益为负，重构不值得做或者必须换一种更让团队容易接受的方案。

　　限于篇幅，这里就不展开说明公式的更多用法，大家不妨拿自己工作中的例子套用试试，看是否有帮助。需要特别注意，就算重构净收益为正，也并不意味着应该停下业务做重构，重构带来的是长期收益而业务需求代表着短期收益，架构师有责任在确保业务正常运转的情况下为未来做准备。

　　InfoQ在线课堂

　　本期InfoQ在线课堂将邀请前EMC大中国区资深技术顾问、现任AWS中国资深技术讲师张波，围绕云计算自动化部署的实现以及AWS CloudFormation实践应用案例进行探讨与分享，对比传统与云端两种自动化部署及管理方式的不同和特点，深入讲解如何使用AWS CloudFormation实现基础设施的代码化，8月16日周二晚8点正式进行直播。点击阅读原文，马上报名（仅限20个名额，先来先得）。