许式伟的架构课
许式伟
七牛云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 | 架构老化与重构
许式伟的架构课
登录|注册

58 | 如何判断架构设计的优劣?

许式伟 2019-11-20
你好,我是七牛云许式伟。
想要让自己进步,我们首先得知道什么是好的。所以我们今天的话题是,如何判断架构设计的优劣?

架构设计的基本准则

架构设计会有它的一些基本准则。比如:
KISS:简单比复杂好;
Modularity:着眼于模块而不是框架;
Testable:保证可测试性;
Orthogonal Decomposition:正交分解。
KISS 全称是 Keep it Simple, Stupid,用最直白的话说,“简单就是美”。不增加无谓的复杂性。正确理解系统的需求之后才进行设计。要避免过度设计,除非有人为复杂性买单。
KISS 的“简单”,强调的是易实施性。让模块容易实现,实现的时候心智负担低,比复杂的优化更重要。
KISS 的“简单”,也是主张让你的代码,包括接口,符合惯例。接口语义要自然,最好让人一看方法名就知道怎么回事,避免惊异。
Modularity,强调的是模块化。从架构设计角度来说,模块的规格,也就是模块的接口,比模块的实现机制更重要。
我们应着眼于模块而不是框架。框架是易变的。框架是业务流,可复用性相对更低。框架都将经历不断发展演化的过程,逐步得到完善。
所以不让模块为框架买单。模块设计时应忽略框架的存在。认真审视模块的接口,发现其中“过度的(或多余的)” 约束条件,把它提高到足够通用的、普适的场景来看。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《许式伟的架构课》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(7)

  • Bachue Zhou
    其实还有一种耦合度经常被人忽视,就是技术耦合度。我们相信,无论是今天多么流行的技术,未来都有失去竞争力的一天,但要开一家长达数十年甚至数百年的技术公司,不可能长期使用已经失去竞争力的技术,必然涉及到技术的多次演进。如果公司的关键性产品与某一种技术耦合度太高,则当该技术失去竞争力或彻底淘汰后,技术迁移成本过高,极易造成迁移彻底失败。所以我从不看好那种一个 Git 库里数十万甚至数百万行 xx 语言或者基于 xx 框架编写的代码,要起一个新项目还必须去引用这个库里的代码不可,这种项目不可能活很久。如果这个项目是公司的关键性产品,那么这个公司也活不了很久。

    作者回复: 👍

    2019-11-22
    2
  • 精彩,用心的总结
    2019-11-21
    2
  • Geek_03056e
    两个核心模块之间由接口调用,并且是A调用B这种的单方面调用,可是两个模块有公用的结构体数据,这些结构体的定义,应该放到那个位置呢?

    作者回复: 如果认为B更加基础、可以放在B。也有人会放在单独的C。anyway,如果A、B、C都隶属于核心系统,全局来说放在哪里只是个细节,对外来说没区别,只不过最好有一个总的入口级模块D把所有这些模块组装起来形成一个整体的DOM。

    2019-11-20
    2
  • 丁丁历险记
    笔记
    1 kiss 有时候,效率就是少做无意义的事。
    2 模块化
    缺经验,伤害值,耦合度为啥那样,理解不来。
    模块设计时应忽略框架的存在。认真审视模块的接口,发现其中“过度的(或多余的)” 约束条件,把它提高到足够通用的、普适的场景来看。
    3 可测试
      好处 一验证和引导代码设计的是否足够解偶。martin fowlor 敏捷开发 模式 实践里有详细论述
    其二 确保完成的代码可用。 在坚固的基础上叠加。
    4 正交分解, 架构就是一种不断正交分解的过程(需要长时间去体验感悟)
    让模块直接。 (推荐看吴军信息论,里面也有介绍信息正交性)
    组合是一种正交,让互为正交模块以乘法模式去组合业务。
    集成是一种加法,(个人觉得有时候抽象类干多了直接变减法)

    最后 缺经验。如何量化,知其然,不知所以然。
    先胡乱理解一波
    伤害公式 ,模块耦合度 用好设计模式,重构技巧优化。
    ,总耦合公式引导了团队开发方向。
    2019-11-21
    1
  • @㍿社长
    想知道,动态的耦合会对系统的复杂性造成什么影响吗?

    作者回复: 动态的耦合?

    2019-12-18
  • 欧星星
    还是不太明白组合为什么比继承更好,老师说组合是做乘法继承是做加法为什么会是组合好呢,本来是想着继承是强依赖如果父类发生了变化会直接影响子类的行为,但如果用组合的话不一样也会影响实现的行为吗?希望老师解惑
    2019-11-23
  • Aaron Cheung
    KISS:简单比复杂好;


    封装很多次的代码 是否所谓体现抽象能力呢
    2019-11-20
收起评论
7
返回
顶部