这两周对架构漫谈进行了几次简单的阅读，有几个短浅的体会：
一：什么是架构
架构是一种能力，架构角色则是要求你在具体事物中行使某些行为，而架构师则是用来标识这些能力与行为的一个职务。对于不同的人来说，可能意味着什么，也是不一样的【因此，对于不同的组织，不同的领域，不同的软件生态，架构师要做的事情也会有所不同】。
大局观；
改变成本很高的事情；
考虑难以改变的事情；
更加兼顾全局的设计；
重点关注接口而非实现；
审美（比如艺术般的整洁代码）；
概念模型；
满足非功能需求/质量属性；
每件事情都有架构；
沟通能力（抽象、语言、词汇）；
计划；
一定程度的严格和可靠性；
蓝图；
系统、子系统、交互和接口；
管理；
战略决策的产出；
必要的约束；
结构（组件和交互）；
技术方向；
战略和愿景；
结构单元；
实现目标的过程；
标准和准则；
整个系统；
工具和方法；
从需求到最终产品的道路；
指导原则；
技术领导力；
构成产品的元素之间的关系；
对环境约束和限制的意识；
基础；
抽象的观点；
把问题化整为零的过程；
产品的骨架、支柱；
架构作为名词来讲，与结构有关：将产品分解为一系列组件、模块和交互。
架构作为动词来讲，包括了理解需要构建什么、设定愿景以便于进行构建和作出恰当的设计决策。
所有这些都要以需求为基础，因为需求驱动架构。关键在于，架构是关于交流愿景以及引入技术领导力的，这样参与构建产品的每个人都能理解这个愿景，并为产品的成功做出积极贡献。
2、每个开发者都应该知道的五件事。
第一，软件架构不是大型预先设计。
软件架构历来被认为跟大型预先设计和瀑布式项目有关。团队要周全的考虑软件设计的所有细节，然后才开始编码。软件架构就是关于软件系统的高层次架构（愿景），以及你如何理解它，它是影响软件系统形态的重要决策，而非理解数据库每个字段应该有多长。
第二，每个软件团队都需要考虑软件架构。
简单的说，尚未发生的坏事往往都会发生，软件架构是关于结构和愿景的，如果不考虑这一点，就可能产出结构糟糕、内部不一致的软件系统。这样的软件系统难以理解和维护，很可能无法满足一些重要的非功能需求，比如性能，可伸缩性或安全性。明确的考虑软件架构，提供了一种引入技术领导的方式，增加成功交付的胜算，也对项目团队有益。
第三，软件架构的角色关乎编码，指导和合作。
现代软件架构更倾向于成为一种有利于编码、指导和协同设计的方法，软件架构的角色不一定要由一个人来承担，而且要了解到架构是否确实行得通，编码是非常好的方式。（也是必须的方式）
第四，无需使用uml。
实际上，可以说UML并不是一个交流软件架构的好方法，如果要保留一些简单的指导方针，轻量级“框线”风格的草图是一个交流软件架构的有效方式。
第五，好的软件架构是支持敏捷开发的。
好的软件架构是支持敏捷的，可以帮助你拥抱并实现变化，而好的软件架构并非与生俱来，需要你努力争取。持续改进。