从0开始学架构_03_02_架构设计的历史背景
你好，我是华仔。
今天我和你分享的主题是架构设计的历史背景，理解了架构的有关概念和定义。
之后呢，今天我会给你讲讲架构设计的历史背景。
我认为，如果想要深入理解一个事物的本质，最好的方式就是去追寻这个事物出现的历史背景和推动因素。
我们先来简单梳理一下软件开发进化的历史，探索一下软件架构出现的历史背景。
最早的软件开发使用的是机器语言，直接使用二进制码零和一来表示机器可以识别的指令和数据，例如在八零八六机器上完成一个简单的加减数学运算，机器码是三行零一串不用多说。
不管是当时的程序员，还是现在的程序员，第一眼看到这样一串东西时，肯定是一头雾水，因为这实在是太难看懂了，这还只是一行运算。
如果要说出一个hello world,面对几十上百行这样的零一串眼睛都要花了，看都没法看。
更何况去写这样的程序，如果不小心哪个地方敲错了，将一敲成了零。
如果要找出这个程序中的错误，程序员的心理阴影面积得有多大？归纳一下，机器语言的主要问题是，三难太难写，太难读，太难难。
为了解决机器语言编写阅读修改复杂的问题，汇编语言应运而生。
汇编语言又叫符号语言，用助记符代替机器指令的操作码，用地址、符号或标号代替指令或操作数的地址。
例如，为了完成将计算器BX的内容送到AX中的简单操作，机器语言是一串二二净指数。
相比机器语言来说呢，汇编语言就清晰的多了。
点击文稿可以看到非常简洁的代码。
Mov是操作，AX和BX是寄存器代号。
这个语句基本上呢就是将寄存器BX的内容送到AX的简化版的翻译。
即使不懂汇编，单纯看到这样一串语言，至少也能明白大概意思。
汇编语言虽然解决了机器语言读写复杂的问题，但本质上呢还是面向机器的。
因为写汇编语言，需要我们精确了解计算机底层的知识，例如CPU、指令寄存器断地址等底层的细节，这对于程序员来说同样很复杂。
因为程序员需要将现实世界中的问题和需求按照机器的逻辑进行翻译。
例如，对于程序员来说，在现实世界中面对的问题是，四加六等于多少？而要用汇编语言实现一个简单的加法运算，需要多达十四行代码。
这还只是实现一个简单的加法运算所需要的汇编程序。
可以想象一下啊，实现一个四则运算的程序会更加复杂，更不用说用汇编写一个操作系统了。
除了编写本身复杂，还有另外一个复杂的地方，在于不同的CPU的汇编，指令和结构是不同的。
例如英特尔的CPU和摩托罗拉的CPU指令不同。
同样一个程序为英特尔的CPU写一次，还要为摩托罗拉的CPU再写一次，而且指令完全不同。
为了解决汇编语言的问题，计算机前辈们从二十世纪五十年代开始又设计了多个高级语言，最初的高级语言。
有下面几个，并且这些语言至今还在特定的领域继续使用。
Fortunin.一九九五年名称取自formula translator及公式，翻译器，由约翰、巴克斯等人发明list. P一九五八年名称取自list processor及枚举处理器。
由约翰，麦卡锡等人发明cobe、一九五九年名称取自common business、 oriented language及通用商业导向语言由葛利斯霍普发明。
为什么称这些语言为高级语言呢？原因在于这些语言让程序员不需要关注机器底层的低级结构和逻辑，只需要关注具体的问题和业务即可。
还是以四加六等于多少？这个加法为例，如果用lis p语言实现，只需要简单一行代码即可。
除此之外呢，通过编译程序的处理高级语言，可以被编译为适合不同CPU指令的机器语言程序员。
只要写一次程序，就可以在多个不同的机器上编译运行，无需根据不同的机器指令重写整个程序高级语言的出现的解放了程序员。
但好景不长，随着软件的规模和复杂度的大大增加，二十世纪六十年代中期开始爆发了第一次软件危机。
典型表现有软件质量低下，项目无法如期完成、项目严重超支等等。
因为软件而导致的重大事故时有发生。
例如，一九六三年美国的水手一号火箭发射失败事故，就是因为一行fortund代码错误导致的软件危机。
最典型的例子莫过于IBM的system,三六零的操作系统开发弗瑞德布鲁克斯作为项目主管，率领两千多个程序员业以继之的工作，共计花费了五千人一年的工作量。
写出将近一百万行的源码。
二共投入五亿美元，是美国的曼哈顿原子弹计划投入的四分之一。
尽管投入如此巨大，但项目进度却一再延迟，软件质量也得不到保障。
布鲁克斯后来基于这个项目经验而总结的人月神话一书，成了畅销的软件工程书籍。
为了解决问题，在一九六八年、一九六九年连续召开两次著名的nature会议，会议正式创造了软件危机一词，并提出了针对性的解决方法。
软件工程虽然软件工程提出之后呢，也曾被视为软件领域的银弹，但后来事实证明软件工程同样无法根除，软件危机，只能在一定程度上缓解软件危机差不多同一时间，结构化程序作为另外一种解决软件危机的方案被提了出来。
艾茨赫尔戴克斯特拉于一九六八年发表了著名的go to有害论论文，引起了长达数年的论战，并由此产生了结构化程序设计方法。
同时，第一个结构化的程序语言tesco也再次诞生，并迅速流行起来。
结构化程序设计的主要特点呢是抛弃构to语句，采取自顶向下，逐步细化、模块化的指导思想。
结构化程序设计本质上还是一种面向过程的设计思想，但通过自顶向下逐步细化模块化的方法，将软件的复杂度控制在一定范围内，从而从整体上降低了软件开发的复杂度。
结构化程度。
方法成为了二十世纪七十年代软件开发的潮流。
结构化编程的风靡在一定程度上缓解了软件危机。
然而，随着硬件的快速发展，业务需求越来越复杂，以及编程应用领域越来越广泛，第二次软件危机很快就到来了。
第二次软件危机的根本原因呢，还是在于软件生产力，远远跟不上硬件和业务的发展。
第一次软件危机的根源在于软件的逻辑变得非常复杂。
而第二次软件危机主要体现在软件的扩展变得非常复杂。
结构化程序设计虽然能够解决软件逻辑的复杂性，但是对于业务变化带来的软件扩展却无能为力，软件领域迫切希望找到新的银弹来解决软件危机。
在这种背景下，面向对象的思想开始流行起来。
面向对象的思想并不是在第二次软件危机后才出现的，早在一九六七年的simuu的语言中就开始提出来了，但是第二次软件危机促进了面向对象的发展，面向对象真正开始流行是在二十世纪八十年代，主要得益于c加加的功劳。
后来的java c sharp把面向对象推向了新的高峰，到现在为止，面向对象已经成为了主流的开发思想。
虽然面向对象开始也被当做解决软件危机的银弹，但事实证明，和软件工程一样，面向对象也不是银弹，而只是一种新的软件方法而已。
虽然早在二十世纪六十年代，戴克斯特拉这位上古大神就已经涉及软件架构这个概念了，但软件架构真正流行却是从二十世纪九十年代开始的。
由于在rational和微软内部的相关活动，软件架构的概念开始越来越流行了，与之前的各种新方法或者新理念不同的是，软件架构出现的背景并不是整个行业都面临类似相同的问题。
软件架构呢也不是为了解决新的软件危机而产生的这是怎么回事呢？卡内基梅隆大学的玛丽肖和戴维加兰对软件架构做了很多研究，他们在一九九四年的一篇文章软件架构介绍中写道，随着软件系统规模的增加，计算相关的算法和数据结构不再构成主要的设计问题。
当系统有许多部分组成时，整个系统的组织也就是所说的软件架构，导致了一系列新的设计问题。
这段话呢很好的解释了软件架构为何现在rational或者微软这样的大公司开始逐步流行起来，因为只有大公司开发的软件系统才具备较大规模，而只有规模较大的软件系统才会面临软件架构相关的问题。
例如，系统规模庞大，内部耦合严重，开发效率低，系统耦合严重迁移，发动全身后续修改和扩展困难。
系统逻辑复杂，容易出问题，出问题后很难排查和修复。
软件架构的出现呢有其历史必然性。
二十世纪六十年代，第一次软件危机引出了结构化编程，创造了模块概念。
二十世纪八十年代，第二次软件危机引出了面向对象编程，创造了对象概念。
到了二十世纪九十年代，软件架构开始流行创造了组件概念。
我们可以看到模块对象组件本质上呢都是对达到一定规模的软件进行拆分。
差别。
只是在于，随着软件的复杂度不断增加，拆分的力度越来越粗，拆分的层次越来越高。
人月神话中提到的IBM三六零大型系统开发时间是一九六四年。
那个时候呢，结构化编程都还没有提出来，更不用说软件架构了。
如果IBM三六零系统放在二十世纪九十年代开发，不管是质量还是效率，成本都会比一九六四年开始做要好得多。
当然这样的话，我们就可能看不到人月神话了。
今天呢我为你回顾了软件开发进化的历史，以及软件架构出现的历史背景。
从历史发展的角度，希望对你深入了解架构设计的本质有所帮助，这就是今天的全部内容。
留一道思考题给你吧。
为何结构化编程、面向对象编程、软件工程架构设计，最后都没有成为软件领域的银蛋呢？欢迎你把答案写到留言区，和我一起讨论。
相信经过深度思考的回答，也会让你对知识的理解更加深刻。