架构师养成第一课

关于文档

在过往的工作中，因为踩过不少文档缺失的坑，就比较重视文档建设，每个产品的上线和迭代都有要求研发团队产出设计文档和接口文档，并基于文档进行技术评审。但公司和部门内部没有统一的文档规范，而团队内部也一直没有形成统一的执行标准，导致不同的同学产出的文档在形式上五花八门，各种维度的图根据文档的编写者习惯随机出现，有时甚至无法正确传达设计思路。

在这个过程中也曾尝试过 UML 和 C4model 等工具，大家普遍对于 UML 有些人云亦云的偏见，认为这个工具已经过时，不再适应互联网时代的软件开发。因为自己缺乏对 UML 系统性的认知，也没能说服大家坚持使用。

另一个方面是动机问题，技术同学普遍对编写技术文档或多或少的存在排斥心理，认为编写文档徒增了工作量，而未带来显而易见的回馈，没有意识到文档在软件开发中的重要性。当然在这个过程中，自己也缺乏有效的引导。

面对以上两个问题，一直没有找到比较好的解法，很是苦恼。

本周学习了李老师的课程，明确了软件设计文档在整个软件生命周期中的重要程度，尤其是关于“没有软件文档就没有软件设计”的观点，深以为然。在上述两个问题中，动机问题是更根本的原因，所以明确软件设计文档的地位至关重要。

此外，在课程中深入剖析了 4+1 视图方法论和 UML 建模方法和工具，收益匪浅。课程中明确了架构设计文档的基本结构和执行套路，甚至贴心的提供了案例和模板，可以直接应用在实际工作中。

关于架构师

帽子和椅子

每个软件产品都应该有架构师角色，以承担架构设计并产出文档的工作。这个角色不一定是带有架构师或技术专家头衔的人，更多的是团队内部某个较为资深的工程师来扮演。重要的是能解决实际问题，而非虚挂头衔。因此架构师更像是一顶帽子，而非一把椅子

软件架构师职责

• 编写架构设计文档

• 开发编程框架

• 重构软件代码

• 设计系统架构

• 进行技术选型，解决技术应用中的问题

• 优化系统性能

• 模块分解与微服务架构重构

• 保障系统安全与高可用

• 大数据应用

• 技术创新

• 技术管理

软件架构师能力清单

• 编程能力

• 基础技术掌握能力

• 常用技术产品的理解与应用能力

• 性能优化与分析故障的能力

• 常用架构模式和框架理解应用能力

• 建模以及设计文档的方法与能力

• 业务理解与功能模块及肺功能模块拆解能力

• 快速学习能力

• 沟通与领导能力

关于软件架构

软件架构 = {元素，形式，关系/约束}

架构的表达

软件架构是一种抽象的存在，仅通过单一的视图无法完整表达设计思路和关键细节，因此需要具备完整的视图集。

架构方法论

4+1 架构视图是一种软件架构方法论，其主要包含：

• 逻辑视图（Logic View）

• 设计的对象模型

• 相关者：用户，研发负责人

• 视角：系统的功能元素，及其接口、职责。交互

• 主要元素：系统、子系统、功能模块、子功能模块、接口

• 用途：开发组织划分，成本/进度评估

• 过程视图（Process View）

• 设计的并发和同步特征（活动图，状态图，时序图）

• 相关者：性能优化，相关开发人员

• 视角：系统运行时线程进程情况

• 主要元素：系统进程，线程以及处理队列等

• 物理视图（Physical View）

• 软件到硬件的映射，反映部署特性（部署图）

• 相关者：系统集成商，系统运维人员

• 视角：系统逻辑组件到物理节点的物理部署和节点之间的物理网络配置

• 主要元素：物理节点以及节点的通信

• 开发视图（Development View）

• 软件的静态组织结构（组件图，包图，类图）

• 相关者：开发人员，测试人员

• 视角：系统如何开发实现

• 主要元素：描述系统的层，分区，包，框架，系统通用服务，业务通用服务，类和接口，系统平台和相关基础框架

• 用途：指导开发组织设计和开发实现

• 场景视图（Scenarios）

• 描述用例场景（用例图）

• 相关者：用户，设计和开发人员

• 视角：概括了架构上最重要的场景（最典型或罪有风险）及其非功能性需求，通过这些场景的实现，阐明了架构的广度和众多架构元素的运行方式

模型

模型是一个系统的抽象，人们对某个领域特定问题的求解及解决方案，对他们的理解和认知都蕴含在模型中。

通常，开发一个计算机系统是为了解决某个领域的特定问题，问题的求解过程，就是领域问题到计算机系统的映射。

人类的很多发明创造都会经历：抽象->具象 （有限次迭代） 的过程，如数学规律、物理规律的应用、仿生学等。

而抽象的产物就是模型，对应到计算机软件领域，因现代软件工程普遍需要多人协作，因此将模型表达出来的重要性愈加凸显。

UML 统一建模语言

常用模型：

• 静态图（描述不变的逻辑关系）

• 用例图（UseCase Diagrams）

• 部署图（Deployment Diagrams）

• 组件图（Component Diagrams）

• 类图（Class Diagrams）

• 包图（Package Diagrams，不常用）

• 对象图（Object Diagrams，不常用）

• 动态图（描述软件在执行中的变化过程）

• 时序图（Sequence Diagrams）

• 活动图（Activity Diagrams）

• 状态图（State Diagrams）

• 协作图（Collaboration Diagrams，不常用）

心得体会

主动做事，不要被动等待。主动发现问题，解决问题