架构之重构的12条军规
115 浏览量
2021-02-26
02:28:59
上传
评论
收藏 218KB PDF 举报
架构之重构的架构之重构的12条军规条军规
【注】架构之重构的12条军规（上）发布以后，一些读者着急要下篇，所以在这里我把上下篇合并成一篇，让大家可以阅读
完整版，不用分开看了。
对于开发者来说，架构设计是软件研发过程中最重要的一环，所谓没有图纸，就建不了房子。在遍地App的互联网时代，架构
设计有了一些比较成熟的模式，开发者和架构师也可以经常借鉴。
但是，随着应用的不断发展，最初的架构往往面临着各种问题，比如无法满足客户的需求、无法实现应用的扩展、无法实现新
的特性等等。在这种情况下，我们如何避免一些坑，尽量比较成功地实现架构的重构，是很多开发者和架构师亟需解决的问
题。
在这里，跟大家分享一下Uber的工程主管Raffi Krikorian的12条规则，并附上一些解读，希望对大家有所启发。
确定重构的目的和必要性
看起来这个规矩有些多余，但是请不要忽略。每一次架构的重构都是“伤筋动骨”，就像做手术一样，即使再成功，也会伤元
气，所以决策者们首先要分析架构重构的理由和其他备选方案，明确重构的目的是为了满足业务需求，并且是不得不做的最佳
方案，然后再考虑其他问题。 有时候，经过分析就会发现，也许还有其他解决方案，比如增加计算资源，或者重构的目的不
是为了业务需求，那就没有必要做了。
检查清单：
架构重构的原因是什么，是为了满足业务的需要还是只是觉得架构不好看？
除了架构重构之外，还有其他备选方案吗？是否都分析过这些方案的利弊？
定义“重构完成”的界限
如果确定要重构，那么要把目标明确下来，也就是重构的边界条件，怎么才算是“完成”了重构，目标要有数据量化，或者有能
够测试的办法。这也是一个需求分析的过程，如果需求不明确，那么规格说明书没法写清楚，负责重构的团队也没有明确的目
标，不能以重构的时间或者主观的判断为结束的依据。前几天和一朋友聊天，他最近在负责系统的性能优化，也要做一些重构
的事情，开始的时候团队的目标不明确，大家不知道优化到什么程度，所以不敢下手。如果目标是提高10%，那么可以从细节
处着手；如果是提高50%，那可能要搞大动作才能实现了。后来目标明确之后，团队才找到合适的办法。
检查清单：
重构的目标可以量化，或者说可以测试吗？
重构完成的标准是什么？得到业务部门或者领导的认可了吗？
渐进式重构
资源评论
