许式伟的架构课
许式伟
七牛云CEO
立即订阅
20237 人已学习
课程目录
已更新 75 讲 / 共 87 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 怎样成长为优秀的软件架构师?
免费
基础平台篇 (21讲)
01 | 架构设计的宏观视角
02 | 大厦基石:无生有,有生万物
03 | 汇编:编程语言的诞生
04 | 编程语言的进化
05 | 思考题解读:如何实现可自我迭代的计算机?
06 | 操作系统进场
07 | 软件运行机制及内存管理
08 | 操作系统内核与编程接口
09 | 外存管理与文件系统
10 | 输入和输出设备:交互的演进
11 | 多任务:进程、线程与协程
12 | 进程内协同:同步、互斥与通讯
13 | 进程间的同步互斥、资源共享与通讯
14 | IP 网络:连接世界的桥梁
15 | 可编程的互联网世界
16 | 安全管理:数字世界的守护
17 | 架构:需求分析 (上)
18 | 架构:需求分析 (下) · 实战案例
19 | 基础平台篇:回顾与总结
加餐 | 我看Facebook发币(上):区块链、比特币与Libra币
加餐 | 我看Facebook发币(下):深入浅出理解 Libra 币
桌面开发篇 (16讲)
20 | 桌面开发的宏观视角
21 | 图形界面程序的框架
22 | 桌面程序的架构建议
23 | Web开发:浏览器、小程序与PWA
24 | 跨平台与 Web 开发的建议
25 | 桌面开发的未来
26 | 实战(一):怎么设计一个“画图”程序?
27 | 实战(二):怎么设计一个“画图”程序?
28 | 实战(三):怎么设计一个“画图”程序?
29 | 实战(四):怎么设计一个“画图”程序?
30 | 实战(五):怎么设计一个“画图”程序?
31 | 辅助界面元素的架构设计
课外阅读 | 从《孙子兵法》看底层的自然法则
加餐 | 想当架构师,我需要成为“全才”吗?
32 | 架构:系统的概要设计
33 | 桌面开发篇:回顾与总结
服务端开发篇 (14讲)
34 | 服务端开发的宏观视角
35 | 流量调度与负载均衡
36 | 业务状态与存储中间件
37 | 键值存储与数据库
38 | 文件系统与对象存储
39 | 存储与缓存
40 | 服务端的业务架构建议
41 | 实战(一):“画图”程序后端实战
42 | 实战(二):“画图”程序后端实战
43 | 实战(三):“画图”程序后端实战
44 | 实战(四):“画图”程序后端实战
45 | 架构:怎么做详细设计?
46 | 服务端开发篇:回顾与总结
加餐 | 如何做HTTP服务的测试?
服务治理篇 (11讲)
47 | 服务治理的宏观视角
48 | 事务与工程:什么是工程师思维?
49 | 发布、升级与版本管理
50 | 日志、监控与报警
加餐 | 怎么保障发布的效率与质量?
51 | 故障域与故障预案
52 | 故障排查与根因分析
53 | 过载保护与容量规划
54 | 业务的可支持性与持续运营
55 | 云计算、容器革命与服务端的未来
56 | 服务治理篇:回顾与总结
架构思维篇 (12讲)
57 | 心性:架构师的修炼之道
用户故事 | 站在更高的视角看架构
58 | 如何判断架构设计的优劣?
59 | 少谈点框架,多谈点业务
60 | 架构分解:边界,不断重新审视边界
加餐 | 实战:“画图程序” 的整体架构
61 | 全局性功能的架构设计
62 | 重新认识开闭原则 (OCP)
63 | 接口设计的准则
64 | 不断完善的架构范式
65 | 架构范式:文本处理
66 | 架构老化与重构
许式伟的架构课
登录|注册

66 | 架构老化与重构

许式伟 2019-12-20
你好,我是七牛云许式伟。
在 “64 | 不断完善的架构范式” 这一讲中,我们强调了架构师在日常工作过程中不断积累和完善架构范式的重要性。而上一讲 “65 | 架构范式:文本处理” 则以我个人经历为例,介绍了文本处理领域的通用架构范式。

架构的老化

架构的功夫全在平常。
无论是在我们架构范式的不断完善上,还是应对架构老化的经验积累上,都是在日常工作过程中见功夫。我们不能指望有一天架构水平会突飞猛进。架构能力提升全靠平常一点一滴地不断反思与打磨得来。
今天我们要聊的话题是架构老化与重构。
架构老化源于什么?
在我们不断给系统添加各种新功能的时候,往往会遇到功能需求的实现方式不在当初框架设定的范围之内,于是很多功能代码逸出框架的范围之外。
这些散落在各处的代码,把系统绞得支离破碎。久而久之,代码就出现老化,散发出臭味。
代码老化的标志,是添加功能越来越难,迭代效率降低,问题却是持续不断,解决了一个问题却又由此生出好几个新问题。
在理想的情况下,如果我们坚持以 “最小化的核心系统 + 多个相互正交的周边系统” 这个指导思想来构建应用,那么代码就很难出现老化。
当然,这毕竟是理想情况。现实情况下,有很多原因会导致架构老化难以避免,比如:
软件工程师的技术能力不行,以功能完成为先,不考虑项目的长期维护成本;
公司缺乏架构评审环节,系统的代码质量缺乏持续有效的关注;
需求理解不深刻,最初架构设计无法满足迭代发展的需要;
架构迭代不及时,大量因为赶时间而诞生的补丁式代码;
……
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《许式伟的架构课》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(6)

  • 丁丁历险记
    正在重构一个运营七年的盈利项目,举步维艰

    作者回复: 一起加油💪

    2019-12-20
    3
  • leslie
    引用老师课程中关于重构的一句经典话语"架构设计(未来架构应该是什么样的)、资源规划与调度(与新功能开发的优先级怎么排)、阶段规划(如何把大任务变小,降低内部的抵触情绪和项目风险)以及持久战的韧性与毅力的庞大工程。”体现了老师一直强调的架构与业务的理解。
            软件架构的老化与重构参与不多:不过数据库架构这块的事情经历过不少。虽范围有所缩小,不过核心思路大致相同。对于老师的这个总结拆分简析一下;
             首先是架构设计:1.需要梳理出当前的现状,对于整体现状做出分析;目的是再烂的架构都有其合理性,其中那些可能会被将来做为最小原子使用这是需要做的;2.针对分析的结果再权衡利弊的基础上想出改进方案,毕竟重构升级的过程还是有许多关联性的数据;3.未来的短、中、长期规划大致是怎样,怎样才能可扩展或后期升级。
           其次是资源规划与调度:个人觉得这块内容应当属于项目经理的知识;1.资源规划:要做的就是拆分,需要对于团队/项目有足够的了解才能更好的明白和了解有什么样资源以及可以用到什么样的程度
    2.资源调度:任何一个项目会有固定资源和非固定/调用资源,固定和非固定的使用程度和时间完全不同的且了解不同,这个协调能力是一个项目经理所需的能力。
           最后是阶段规划以及持久性:格局观和可持续性,即通常所说的CI/CD特性;对于整体的了解越明白、格局观与弹性越好,规划和持续性就越好。其实还涉及到产品中常用的MVP特性,试错中找到最佳持续方案。
            以上是我对于老师今天分享的思考和理解以及梳理;一路学习、一路实践、一路反思、一路收获。感谢老师的付出,让我在学习中能不断收获到不一样的知识;期待老师的后续分享,谢谢。
     

    作者回复: 挺好的思考与总结

    2019-12-21
  • Aaron Cheung
    许老师的讲解让我明白 talk is really important
    2019-12-20
  • 梦醒十分
    要多看几遍呀!
    2019-12-20
  • 沫沫(美丽人生)
    许老师,需求的变化点和稳定点,可以作为判断系统的核心模块和周边模块的依据吗?

    作者回复: 有这个味道在里面

    2019-12-20
    1
  • 沫沫(美丽人生)
    许老师,想请教一个核心功能界定的问题,还有一个产品之间差异化的问题。怎么确定一个系统的核心模块呢?作为竞争对手,WPS和office的差异化是什么?怎么在程序架构中抽象这种差异化呢?望您不吝赐教

    作者回复: 需求越稳定的部分,越处于核心的位置。MVC 框架,MV 是核心,C 是周边。M 如果比较大,内部还可以分核心与周边。wps 和 office 的竞争很有意思,从最初的不一样的 office 到后面提一样的 office,你可以感受一下。程序架构不会受此类商业策略的影响。

    2019-12-20
    1
收起评论
6
返回
顶部