架构师相关知识学习-201608.pdfVIP

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