从 0 开始学架构
李运华
网名“华仔”,前阿里资深技术专家(P9)
152571 人已学习
新⼈⾸单¥68
登录后,你可以任选4讲全文学习
课程目录
已完结/共 66 讲
结束语 (1讲)
结课测试 (1讲)
从 0 开始学架构
15
15
1.0x
00:00/00:00
登录|注册

02 | 架构设计的历史背景

C++、Java、C#
自顶向下、逐步细化、模块化
结构化编程、面向对象编程、软件工程、架构设计都无法成为银弹
模块、对象、组件的拆分
大公司面临软件架构问题
软件系统规模增加,组织问题出现
面向对象也不是银弹,只是新的方法
面向对象的思想流行
软件扩展性问题
无法根除软件危机,只能缓解
结构化程序设计方法的出现
软件质量低下、项目超支等问题
编译为不同机器指令的机器语言
解放程序员,关注问题和业务
Fortran、LISP、Cobol
面向机器,需要了解底层知识
解决机器语言复杂性问题
问题:太难写、太难读、太难改
总结
软件架构的出现背景
第二次软件危机与面向对象(20世纪80年代)
第一次软件危机与结构化程序设计(20世纪60年代~20世纪70年代)
高级语言(20世纪50年代)
汇编语言(20世纪40年代)
机器语言(1940年之前)
软件架构的历史背景

该思维导图由 AI 生成,仅供参考

理解了架构的有关概念和定义之后,今天,我会给你讲讲架构设计的历史背景。我认为,如果想要深入理解一个事物的本质,最好的方式就是去追寻这个事物出现的历史背景和推动因素。我们先来简单梳理一下软件开发进化的历史,探索一下软件架构出现的历史背景。

机器语言(1940 年之前)

最早的软件开发使用的是“机器语言”,直接使用二进制码 0 和 1 来表示机器可以识别的指令和数据。例如,在 8086 机器上完成“s=768+12288-1280”的数学运算,机器码如下:
101100000000000000000011
000001010000000000110000
001011010000000000000101
不用多说,不管是当时的程序员,还是现在的程序员,第一眼看到这样一串东西时,肯定是一头雾水,因为这实在是太难看懂了,这还只是一行运算,如果要输出一个“hello world”,面对几十上百行这样的 0/1 串,眼睛都要花了!
看都没法看,更何况去写这样的程序,如果不小心哪个地方敲错了,将 1 敲成了 0,例如:
101100000000000000000011
000001010000000000110000
001011000000000000000101
如果要找出这个程序中的错误,程序员的心里阴影面积有多大?
归纳一下,机器语言的主要问题是三难:太难写、太难读、太难改

汇编语言(20 世纪 40 年代)

为了解决机器语言编写、阅读、修改复杂的问题,汇编语言应运而生。汇编语言又叫“符号语言”,用助记符代替机器指令的操作码,用地址符号(Symbol)或标号(Label)代替指令或操作数的地址。
例如,为了完成“将寄存器 BX 的内容送到 AX 中”的简单操作,汇编语言和机器语言分别如下。
机器语言:1000100111011000
汇编语言:mov ax,bx
相比机器语言来说,汇编语言就清晰得多了。mov 是操作,ax 和 bx 是寄存器代号,mov ax,bx 语句基本上就是“将寄存器 BX 的内容送到 AX”的简化版的翻译,即使不懂汇编,单纯看到这样一串语言,至少也能明白大概意思。
汇编语言虽然解决了机器语言读写复杂的问题,但本质上还是面向机器的,因为写汇编语言需要我们精确了解计算机底层的知识。例如,CPU 指令、寄存器、段地址等底层的细节。这对于程序员来说同样很复杂,因为程序员需要将现实世界中的问题和需求按照机器的逻辑进行翻译。例如,对于程序员来说,在现实世界中面对的问题是 4 + 6 = ?。而要用汇编语言实现一个简单的加法运算,代码如下:
.section .data
a: .int 10
b: .int 20
format: .asciz "%d\n"
.section .text
.global _start
_start:
movl a, %edx  
addl b, %edx  
pushl %edx
pushl $format
call printf
movl $0, (%esp)
call exit
这还只是实现一个简单的加法运算所需要的汇编程序,可以想象一下,实现一个四则运算的程序会更加复杂,更不用说用汇编写一个操作系统了!
除了编写本身复杂,还有另外一个复杂的地方在于:不同 CPU 的汇编指令和结构是不同的。例如,Intel 的 CPU 和 Motorola 的 CPU 指令不同,同样一个程序,为 Intel 的 CPU 写一次,还要为 Motorola 的 CPU 再写一次,而且指令完全不同。

高级语言(20 世纪 50 年代)

为了解决汇编语言的问题,计算机前辈们从 20 世纪 50 年代开始又设计了多个高级语言,最初的高级语言有下面几个,并且这些语言至今还在特定的领域继续使用。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

软件架构设计的历史背景是一个承载着技术革新和挑战的过程。从机器语言到高级语言的演进,每一步都是为了解决软件开发中的复杂性和低效率问题。随着软件规模和复杂度的增加,出现了第一次软件危机,导致了软件质量低下和项目延期等问题。为了解决这一问题,结构化程序设计应运而生,有效控制了软件复杂度,成为了20世纪70年代软件开发的潮流。然而,随着硬件的快速发展和业务需求的复杂化,第二次软件危机迅速到来。面向对象的思想开始流行起来,成为了主流的开发思想。软件架构的概念在20世纪90年代开始流行,由于大规模软件系统面临的问题,如系统规模庞大、内部耦合严重、开发效率低等,软件架构的出现有其历史必然性。总的来说,软件架构设计的历史背景展现了技术革新对软件开发的影响,为读者提供了对软件架构设计历史背景的深入了解。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《从 0 开始学架构》
新⼈⾸单¥68
立即购买
登录 后留言

全部留言(246)

  • 最新
  • 精选
  • 公号-技术夜未眠
    2018年5月1日心得 在古代的狼人传说中,只有用银质子弹(银弹)才能制服这些异常凶残的怪兽。在软件开发活动中,“银弹”特指人们渴望找到用于制服软件项目这头难缠的“怪兽”的“万能钥匙”。 软件开发过程包括了分析、设计、实现、测试、验证、部署、运维等多个环节。从IT技术的发展历程来看,先辈们在上述不同的环节中提出过很多在当时看来很先进的方法与理念。但是,这些方法、理念在摩尔定律、业务创新、技术发展面前都被一一验证了以下观点:我们可以通过诸多方式去接近“银弹”,但很遗憾,软件活动中没有“银弹”。 布鲁克斯发表《人月神话》三十年后,又写了《设计原本》。他认为一个成功的软件项目的最重要因素就是设计,架构师、设计师需要在业务需求和IT技术中寻找到一个平衡点。个人觉得,对这个平衡点的把握,就是架构设计中的取舍问题。而这种决策大部分是靠技术,但是一定程度上也依赖于架构师的“艺术”,技术可以依靠新工具、方法论、管理模式去提升,但是“艺术”无法量化 ,是一种权衡。 软件设计过程中,模块、对象、组件本质上是对一定规模软件在不同粒度和层次上的“拆分”方法论,软件架构是一种对软件的“组织”方法论。一分一合,其目的是为了软件研发过程中的成本、进度、质量得到有效控制。但是,一个成功的软件设计是要适应并满足业务需求,同时不断“演化”的。设计需要根据业务的变化、技术的发展不断进行“演进”,这就决定了这是一个动态活动,出现新问题,解决新问题,没有所谓的“一招鲜”。 以上只是针对设计领域的银弹讨论,放眼到软件全生命周期,银弹问题会更加突出。 小到一个软件开发团队,大到一个行业,没有银弹,但是“行业最佳实践”可以作为指路明灯,这个可以有。

    作者回复: 赞,666,你已经提前帮我做了后面相关内容的预热了👍👍

    2018-05-01
    14
    823
  • narry
    软件开发最本质的挑战有两个:复杂和变更,而软件的价值是保证业务的响应力,而与之相对的是开发资源的有限,而各种的软件开发方法论,也都是在研究有限的资源下,如何应对着两个挑战,寻找平衡点,实现业务目标,因为是在寻找平衡点,就说明是有取舍的,所以就没有所谓的银弹的存在

    作者回复: 回答的很好,作者也受到了启发,谢谢👍👍

    2018-05-02
    5
    236
  • felix
    变化才是唯一的不变,所以银弹不会存在

    作者回复: 言简意赅,抓住了核心本质,“银弹”产生于一定的历史背景和大环境,而历史和环境总是会变化的

    2018-05-02
    2
    91
  • Up
    作者这个问题是否在考验,读者认真看了这篇文章没有?我认为文章的软件发展历史正是答案,软件工程归根结底是为各行各业的需求服务的,而随着需求的复杂度越来越高,用户的要求越来越高,软件也越复杂,形态也在不断变化,所以没有一种方法论能称得上是银弹,只能说某一种方法论适合某一种需求。这也正是架构师存在的意义,去选择合适的技术,如果有银弹,还要架构师干嘛!以上只是个人见解!

    作者回复: 你已经看穿一切👍👍 确实是想通过介绍历史来启发大家思考

    2018-05-01
    75
  • 李志博
    软件开发的结果在于人,而不在于方法论,面向对象,设计模式,架构,这些概念的推出距离现在,好几十年了吧,可真正理解透彻的能有多少呢,就算有像作者这样理解透彻的,还在一线开发的能有多少……阿里的p9难道还在一线写代码嘛……最终写代码的人还是理解不到位的我们,技术强的,写的项目能多撑两年,但是复杂到一定程度,没有良好关系架构指导,都是坑

    作者回复: 其实不一定要P9才要理解到位呢,我2014年就写了《面向对象葵花宝典》,那时我还在写代码的哦,其实我现在也写代码,不写代码很多技术没法确切理解,我现在写demo代码比较多,例如用golang写个简单的区块链,用java写个reactor等

    2018-05-01
    3
    42
  • xuan
    “No Silver Bullet”的原文是:“没有任何技术或管理上的进展,能够独立地许诺十年内使生产率、可靠性或简洁性获得数量级上的进步。”之所以这样说,是因为软件的根本困难(Essence,包括复杂度、一致性、可变性、不可见性) 复杂度:规模上, 软件实体可能比任何由人类创造的其他实体更复杂, 因为没有任何两个软 件部分是相同的 一致性:软件的变化必须遵循一系列接口标准规范,有些情况下它的变化就是要兼容; 可变性:一般有如下几种情况: 1.当客户喜欢用某个功能或者某个功能能解决他的某些问题时,他会针对这方面提出很多优化该功能的需求点 2.硬件或者其他配件的升级变化 必须升级现有软件平台 不可见性:软件不存在一种空间形态 可以通过一张图 或者其他载体来可视化展示 ,不能通过地图 电路设计图等来全面展示. 由于这几个点的变化,导致系统越来越臃肿,从而导致管理成本上升,沟通困难,可靠性逐年下降等等;而结构化 面向对象等主要是来提高生产率 可靠性和简洁性

    作者回复: 没有看过《人月神话》的程序员不能成为好的架构师😃😃👍👍

    2018-05-02
    29
  • Mark Yao
    软件本身的复杂度难以度量,随时间和规模发展,原有的解决方案很快难适应,人们就不断总结经验模式和设计解决新困难的办法,但是不管什么样的架构设计都是在尽量满足适应我们可能遇到的问题的解决方案,不是解决问题方案。生活中我们的应用从单体到主备再到集群、分布式、微服务最后到最新的Service Mesh,这些其实都是解决和改善、完善、优化我们在软件开发遇到的问题。There is no silver bullet.

    作者回复: 回答正确👍

    2018-05-02
    21
  • yoummg
    作者的用心令人敬佩。 为什么现在我们在谈“架构”,他不是平白无故产生的,他是在一定的背景下产生的。更好地理解他产生的原因,会在具体解决问题的时候做到有的放矢。 直到现在才看明白,what,why,how。这真是一个认清事物最本质的三步。👍👍👍

    作者回复: 你已经洞悉天机👍👍😄整个专栏思路就是这样的

    2018-07-08
    17
  • 闭嘴
    感觉作者对整个软件行业有比较深入的了解。就是内容太少。还没看就没了。希望后面的文章多来一点干货。让我这种小白能够学习到一点实质的东西。能够解决项目问题的一些东西。希望大神能够把自己的功力展现60%就行。

    作者回复: 这是提炼出来的,为了写这一篇,我写了2~3周,如果觉得意犹未尽,可以在这个基础上继续去探索

    2018-05-02
    9
  • Geek_92f9aa
    一个答案解决所有问题:“因为熵增定律”。 而熵增的表现其实就是变化。 那如何克服这一变化? 同样是一句话概括:“生命以负熵为食”。 即在生物界,生命通过已知的信息完成外界能量到自身的转移,这个过程虽然逃不过熵增定律,但通过加速外界的熵增实现了生命自身熵的不变,生物因此得以维持自身状态不变(即活着,没死) 文章说到的架构的历史,其实就是一个对抗熵增的生命演化史。软件本身没有生命,所以要依靠人来实现自身状态维持。 即如果我们将软件和人看成一个整体,那么其状态即是可维持的,所以这就是银弹。而如果将人从这个整体中剥离出去,软件就失去了生命力,无法永远维持自身状态,再牛逼的设计也不可能成为银弹,除非让其拥有对抗熵增的能力,那样的话软件也是有生命的。从这点来看,人工智能极有可能成为一个新生物,届时再也不需要程序员了,恩,人也不需要了,哈哈,细思极恐。

    作者回复: 别担心,你我有生之年应该还不会被人工智能干掉������

    2020-10-29
    3
    5
收起评论
大纲
固定大纲
机器语言(1940 年之前)
汇编语言(20 世纪 40 年代)
高级语言(20 世纪 50 年代)
显示
设置
留言
99+
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部