架构漫谈阅读笔记

这两周对架构漫谈进行了几次简单的阅读，有几个短浅的体会：

一：什么是架构

架构是一种能力，架构角色则是要求你在具体事物中行使某些行为，而架构师则是用来标识这些能力与行为的一个职务。对于不同的人来说，可能意味着什么，也是不一样的【因此，对于不同的组织，不同的领域，不同的软件生态，架构师要做的事情也会有所不同】。

大局观；

改变成本很高的事情；

考虑难以改变的事情；

更加兼顾全局的设计；

重点关注接口而非实现；

审美（比如艺术般的整洁代码）；

概念模型；

满足非功能需求/质量属性；

每件事情都有架构；

沟通能力（抽象、语言、词汇）；

计划；

一定程度的严格和可靠性；

蓝图；

系统、子系统、交互和接口；

管理；

战略决策的产出；

必要的约束；

结构（组件和交互）；

技术方向；

战略和愿景；

结构单元；

实现目标的过程；

标准和准则；

整个系统；

工具和方法；

从需求到最终产品的道路；

指导原则；

技术领导力；

构成产品的元素之间的关系；

对环境约束和限制的意识；

基础；

抽象的观点；

把问题化整为零的过程；

产品的骨架、支柱；

架构作为名词来讲，与结构有关：将产品分解为一系列组件、模块和交互。

架构作为动词来讲，包括了理解需要构建什么、设定愿景以便于进行构建和作出恰当的设计决策。

所有这些都要以需求为基础，因为需求驱动架构。关键在于，架构是关于交流愿景以及引入技术领导力的，这样参与构建产品的每个人都能理解这个愿景，并为产品的成功做出积极贡献。

2、每个开发者都应该知道的五件事。

第一，软件架构不是大型预先设计。

软件架构历来被认为跟大型预先设计和瀑布式项目有关。团队要周全的考虑软件设计的所有细节，然后才开始编码。软件架构就是关于软件系统的高层次架构（愿景），以及你如何理解它，它是影响软件系统形态的重要决策，而非理解数据库每个字段应该有多长。

第二，每个软件团队都需要考虑软件架构。

简单的说，尚未发生的坏事往往都会发生，软件架构是关于结构和愿景的，如果不考虑这一点，就可能产出结构糟糕、内部不一致的软件系统。这样的软件系统难以理解和维护，很可能无法满足一些重要的非功能需求，比如性能，可伸缩性或安全性。明确的考虑软件架构，提供了一种引入技术领导的方式，增加成功交付的胜算，也对项目团队有益。

第三，软件架构的角色关乎编码，指导和合作。

现代软件架构更倾向于成为一种有利于编码、指导和协同设计的方法，软件架构的角色不一定要由一个人来承担，而且要了解到架构是否确实行得通，编码是非常好的方式。（也是必须的方式）

第四，无需使用uml。

实际上，可以说UML并不是一个交流软件架构的好方法，如果要保留一些简单的指导方针，轻量级“框线”风格的草图是一个交流软件架构的有效方式。

第五，好的软件架构是支持敏捷开发的。

好的软件架构是支持敏捷的，可以帮助你拥抱并实现变化，而好的软件架构并非与生俱来，需要你努力争取。持续改进。