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