66 | 架构老化与重构
许式伟
该思维导图由 AI 生成，仅供参考
你好，我是七牛云许式伟。
在 “64 | 不断完善的架构范式” 这一讲中，我们强调了架构师在日常工作过程中不断积累和完善架构范式的重要性。而上一讲 “65 | 架构范式：文本处理” 则以我个人经历为例，介绍了文本处理领域的通用架构范式。
架构的老化
架构的功夫全在平常。
无论是在我们架构范式的不断完善上，还是应对架构老化的经验积累上，都是在日常工作过程中见功夫。我们不能指望有一天架构水平会突飞猛进。架构能力提升全靠平常一点一滴地不断反思与打磨得来。
今天我们要聊的话题是架构老化与重构。
架构老化源于什么？
在我们不断给系统添加各种新功能的时候，往往会遇到功能需求的实现方式不在当初框架设定的范围之内，于是很多功能代码逸出框架的范围之外。
这些散落在各处的代码，把系统绞得支离破碎。久而久之，代码就出现老化，散发出臭味。
代码老化的标志，是添加功能越来越难，迭代效率降低，问题却是持续不断，解决了一个问题却又由此生出好几个新问题。
在理想的情况下，如果我们坚持以 “最小化的核心系统 + 多个相互正交的周边系统” 这个指导思想来构建应用，那么代码就很难出现老化。
当然，这毕竟是理想情况。现实情况下，有很多原因会导致架构老化难以避免，比如：
软件工程师的技术能力不行，以功能完成为先，不考虑项目的长期维护成本；
公司缺乏架构评审环节，系统的代码质量缺乏持续有效的关注；
需求理解不深刻，最初架构设计无法满足迭代发展的需要；
架构迭代不及时，大量因为赶时间而诞生的补丁式代码；
……
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
架构老化与重构是软件开发中常见的问题。本文通过七牛云许式伟的经历为例，介绍了架构老化的原因以及应对方法。作者提出了以“最小化的核心系统 + 多个相互正交的周边系统”为指导思想构建应用，以减少架构老化的方法。在应对架构老化时，作者建议从两个视角出发：如何重构系统以及如何进行局部改善和添加新功能。对于添加新功能，作者强调将其定位为周边功能，并将其视为独立业务系统，尽量减少对核心系统的依赖。此外，作者还分享了在实际工作中如何处理新功能的思路，以及如何与既有系统剥离，从独立业务视角去实现业务，抽象对环境的依赖。文章内容丰富，为读者提供了对架构老化与重构的深入思考和实践经验。文章中还介绍了局部调整和核心系统的重构方法，强调了依赖优化和接口改造的重要性。总的来说，本文为读者提供了对架构老化与重构的深入思考和实践经验，对于软件开发人员和架构师具有一定的借鉴意义。
仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《许式伟的架构课》，新⼈⾸单¥68
《许式伟的架构课》，新⼈⾸单¥68
立即购买
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(17)
- 最新
- 精选
丁丁历险记正在重构一个运营七年的盈利项目，举步维艰作者回复: 一起加油💪
2019-12-20313
Eternal"重构的挑战远不只是这些。这是一个集架构设计（未来架构应该是什么样的）、资源规划与调度（与新功能开发的优先级怎么排）、阶段规划（如何把大任务变小，降低内部的抵触情绪和项目风险）以及持久战的韧性与毅力的庞大工程" 总结得太好了，2019年我们2个人重构了一个老系统，本以为花上几个月时间能搞定，结果我们遇到了一堆问题：新需求需要继续做怎么保持兼容？重构任务怎么拆分，？后阶段性完成，回归测试资源不足怎么安排上线时间？外部资源不够（重构需求得优先级容易被打压）作者回复: 多谢补充
2020-02-025- Geek_88604f最近在考虑云服务计费功能的重构，服务资源的计量依赖资源的状态，而状态是由业务控制的，业务状态变更的时候需要刷新计费相关的数据，因此计费的功能就和业务耦合了。目前的重构思路是这样的：起一个定时任务，按照一定的周期调用业务接口查询资源的状态，所有的计费逻辑都在定时任务中。避免对核心业务的影响。后续可以进一步优化成基于事件的机制。不知道这个思路是否可行，许老师？
作者回复: 非常好的一个经典案例。不妨多思考几种解决思路，客观对比一下彼此的优缺点。
2019-12-2835 
东方华尔街刚刚参加了ECUG 大会，许老师的个人魅力和架构能力杠杠的作者回复: 多谢支持
2020-01-063
leslie引用老师课程中关于重构的一句经典话语"架构设计（未来架构应该是什么样的）、资源规划与调度（与新功能开发的优先级怎么排）、阶段规划（如何把大任务变小，降低内部的抵触情绪和项目风险）以及持久战的韧性与毅力的庞大工程。”体现了老师一直强调的架构与业务的理解。 软件架构的老化与重构参与不多：不过数据库架构这块的事情经历过不少。虽范围有所缩小，不过核心思路大致相同。对于老师的这个总结拆分简析一下； 首先是架构设计：1.需要梳理出当前的现状，对于整体现状做出分析；目的是再烂的架构都有其合理性，其中那些可能会被将来做为最小原子使用这是需要做的；2.针对分析的结果再权衡利弊的基础上想出改进方案，毕竟重构升级的过程还是有许多关联性的数据；3.未来的短、中、长期规划大致是怎样，怎样才能可扩展或后期升级。 其次是资源规划与调度：个人觉得这块内容应当属于项目经理的知识；1.资源规划：要做的就是拆分，需要对于团队/项目有足够的了解才能更好的明白和了解有什么样资源以及可以用到什么样的程度 2.资源调度：任何一个项目会有固定资源和非固定/调用资源，固定和非固定的使用程度和时间完全不同的且了解不同，这个协调能力是一个项目经理所需的能力。 最后是阶段规划以及持久性：格局观和可持续性，即通常所说的CI/CD特性；对于整体的了解越明白、格局观与弹性越好，规划和持续性就越好。其实还涉及到产品中常用的MVP特性，试错中找到最佳持续方案。 以上是我对于老师今天分享的思考和理解以及梳理；一路学习、一路实践、一路反思、一路收获。感谢老师的付出，让我在学习中能不断收获到不一样的知识；期待老师的后续分享，谢谢。作者回复: 挺好的思考与总结
2019-12-213
沫沫（美丽人生）许老师，想请教一个核心功能界定的问题，还有一个产品之间差异化的问题。怎么确定一个系统的核心模块呢？作为竞争对手，WPS和office的差异化是什么？怎么在程序架构中抽象这种差异化呢？望您不吝赐教作者回复: 需求越稳定的部分，越处于核心的位置。MVC 框架，MV 是核心，C 是周边。M 如果比较大，内部还可以分核心与周边。wps 和 office 的竞争很有意思，从最初的不一样的 office 到后面提一样的 office，你可以感受一下。程序架构不会受此类商业策略的影响。
2019-12-2023- 沫沫（美丽人生）许老师，需求的变化点和稳定点，可以作为判断系统的核心模块和周边模块的依据吗？
作者回复: 有这个味道在里面
2019-12-2031 - 小刚把老师讲的思路整理下： 理想情况下，“最小化的核心系统 + 多个相互正交的周边系统” 架构思想，代码是不会出现老化的，根本不会产生重构的需求; 那为什么需要重构呢： why（这些是我们要尽力在前面避免的） - 软件工程师的技术能力不行，仅考虑眼前的功能实现，不考虑项目的长期守护成本 - 公司缺乏架构评审环节，代码质量缺乏持续有效的关注 - 需求理解不深刻，最初的架构设计无法满足迭代发展的要求 - 架构迭代不及时，产生很多补丁式代码 - 。。。。。。 how 场景一：老系统增加新功能 - 尽可能与既有系统剥离，新做一个业务模块 - 新的业务模块尽量不依赖老的业务模块 - 最终的代码实现，是A(核心模块) B（新的业务模块，与A无关） A->B的桥接代码； - 这个桥接代码应该尽量小，应该归属于A，一般就是插件机制 或者 回调接口； 场景二： 局部优化 - 子场景一：重写， 相当于重新开发一个业务模块； - 子场景二： 依赖优化； 把相同功能的代码都挪到一个地方，相当于是一个新的模块；做到OCP 场景三： 核心模块重构 步骤如下： 整理当前接口； 让周边系统依赖接口，而不是依赖实现 实现一个mock系统，保证系统能run起来，确保上述第一步周边系统已经完成通过接口实现； 设计新的接口，这个必须体现接口设计原则，体现业务本质的表达方式； 实现新的接口； 新老接口并存，并逐步完成周边系统的向新接口切换； 这个中间过程应该不能持续太久；
作者回复: 👍
2022-12-03归属地：新加坡 - Geek_c25e3d老师讲了业务架构和基础架构，但是现实中有很多企业要求应用架构，请问它和业务架构的区别是什么，有什么参考资料吗
作者回复: 应用架构就是指业务架构
2020-06-092 
reverse许神的架构课重要部分笔记已记录，github地址：https://github.com/xiaomiwujiecao/KongFuOfArchitect/blob/master/part1/README.md 欢迎拍砖！欢迎丢香蕉2019-12-3117
收起评论
