# 架构的历史
如果想要深入理解一个事物的本质，最好的方式就是去追寻这个事物出现的历史背景和推动因素。
- 机械语言（1940年之前）
- 汇编语言（20世纪40年代）
- 高级语言 (20世纪50年代)
# 第一次软件危机与结构化程序设计(20世纪60年代~20世纪70年代)
软件危机最典型的例子莫过于IBM的System/360的操作系统开发。佛瑞德·布鲁克斯(Frederick P. Brooks, Jr. )作为项目主管，率领2000多个程序员夜以继日地工作，共计花 费了5000人一年的工作量，写出将近100万行的源码，总共投入5亿美元，是美国的“曼哈顿”原子弹计划投入的1/4。尽管投入如此巨大，但项目进度却一再延迟，软件质量也得不 到保障。布鲁克斯后来基于这个项目经验而总结的《人月神话》一书，成了畅销的软件工程书籍。 为了解决问题，在1968、1969年连续召开两次著名的NATO 会议，会议正式创造了“软件危机”一词，并提出了针对性的解决方法“软件工程”。虽然“软件工程”提出之后也曾被视为 软件领域的银弹，但后来事实证明，软件工程同样无法根除软件危机，只能在一定程度上缓解软件危机。
问题：第一次软件危机的根源在于软件的“逻辑”变得非常复杂 方案：采取“自顶向下、逐步细化、模块化”的指导思想。结构化程序设计本质上还是一种面向过程的设计思想，但通过“自顶向下、逐步细化、 模块化”的方法，将软件的复杂度控制在一定范围内，从而从整体上降低了软件开发的复杂度。
# 第二次软件危机与面向对象(20世纪80年代)
问题：而第二次软件危机主要体现在软件的“扩 展”变得非常复杂。对于业务变化带来的软件扩展却无能为力。 方案：面向对象的思想开始使用，和软件工程一样，面向对象也不是银弹，而只是一种新的软件方法而已。
#面临软件架构相关的问题
- 系统规模庞大，内部耦合严重，开发效率低;
- 系统耦合严重，牵一发动全身，后续修改和扩展困难;
- 系统逻辑复杂，容易出问题，出问题后很难排查和修复。
软件架构的出现有其历史必然性。20世纪60年代第一次软件危机引出了“结构化编程”，创造了“模块”概念;20世纪80年代第二次软件危机引出了“面向对象编程”，创造了“对象”概 念;到了20世纪90年代“软件架构”开始流行，创造了“组件”概念。我们可以看到，“模块”“对象”“组件”本质上都是对达到一定规模的软件进行拆分，差别只是在于随着软件的复杂度 不断增加，拆分的粒度越来越粗，拆分的层次越来越高。
在古代的狼人传说中，只有用银质子弹(银弹)才能制服这些异常凶残的怪兽。在软件开发活动中，“银弹”特指人们渴望找到用于制服软件项目这头难缠的“怪兽”的“万能钥匙”。软件开发过程包括了分析、设计、实现、测试、验证、部署、运维等多个环节。从IT技术的发展历程来看，先辈们在上述不同的环节中提出过很多在当时看来很先进的方法与理念。但是，这些 方法、理念在摩尔定律、业务创新、技术发展面前都被一一验证了以下观点:我们可以通过诸多方式去接近“银弹”，但很遗憾，软件活动中没有“银弹”。布鲁克斯发表《人月神话》三十年后，又写了《设计原本》。他认为一个成功的软件项目的最重要因素就是设计，架构师、设计师需要在业务需求和IT技术中寻找到一个平衡点。个人觉得，对 这个平衡点的把握，就是架构设计中的取舍问题。而这种决策大部分是靠技术，但是一定程度上也依赖于架构师的“艺术”，技术可以依靠新工具、方法论、管理模式去提升，但是“艺术”无法量化 ，是一种权衡。软件设计过程中，模块、对象、组件本质上是对一定规模软件在不同粒度和层次上的“拆分”方法论，软件架构是一种对软件的“组织”方法论。一分一合，其目的是为了软件研发过程中的成本、进 度、质量得到有效控制。但是，一个成功的软件设计是要适应并满足业务需求，同时不断“演化”的。设计需要根据业务的变化、技术的发展不断进行“演进”，这就决定了这是一个动态活动，出现 新问题，解决新问题，没有所谓的“一招鲜”。以上只是针对设计领域的银弹讨论，放眼到软件全生命周期，银弹问题会更加突出。 小到一个软件开发团队，大到一个行业，没有银弹，但是“行业最佳实践”可以作为指路明灯，这个可以有。
# 架构的目的
# 架构设计的误区
因为架构很重要，所以要做架构设计(正确的废话)不是每个系统都要做架构设计吗为了高性能、高可用、可扩展，所以要做架构设计(项目遥遥无期)
# 架构设计的真正目的
整个软件技术发展的历史，其实就是一部与“复杂度”斗争的历史，架构的出现也不例外。简而言之，架构也是为了应对软件系统复杂度而提出的一个解决方案，
# 总结
- 架构是为了应对软件系统复杂度而提出的一个解决方案
- 架构即(重要)决策
- 需求驱动架构，架起分析与设计实现的桥梁
- 架构与开发成本的关系
← 1.架构是什么