[架构之路-91]：《软件架构设计：程序员向架构师转型必备》-1-从程序员到架构师，学习本书的路径

Posted 2023-02-19 文火冰糖的硅基工坊

第1章 从程序员到架构师

本书不是从系统培训的角度，也不是按照软件的开发流程来组织内容的和展现软件架构师在不同阶段中的职责和作用，而是立足于程序员，展现程序员走向架构师的路径。

1.1 软件业人才结构

1.1.1 金字塔型，还是橄榄型？

在上文，从两个不同的角度展现了人才的架构：一是学历，二是能力。

在大部分的软件公司，是按照能力和角色来划分成才结构的，其中，软件叫架构师、系统工程师、技术经理都是在金字塔中的高级人才区间，中间人才包括高级软件工程师等。

1.1.2 从程序员向架构师转型

在该章节中，作者认为，一个软件企业的高级人才，通常不是以外聘为主，而是以内部培养为主。

程序员成长为架构师，不仅仅是程序员（员工）自己的职责（员工需要进行专项的自我提升），

同时也是HR的职责，HR需要定期分析公司的人才储备和人才结构，有组织有计划的培养和提拔高端人才；

同时也是部门经理的职责，程序员成长为架构师，需要大量的实践，这些实践都从项目中来，部门经理需要给程序员创造条件和机会，并且有计划的提拔人才。

在一个组织内部，一个程序员要成长为架构师，如果他认为仅靠自己的努力就能够达到，这未免过于可爱和天真了，估计是机器打交道太久了。在大部分的组织中，很大一部分的机会来自于组织内部，而不仅仅是程序员自己 。

1.1.3 架构师的主要任务

• 理需求

• 分模块

• 定接口

• 明时序

• 画愿景

• 找沟通

1.2 本书价值

不同的人，可以采用不同的路径读本书，不一定从头按顺序开始。

1.2.1 阅读路径1：架构设计入门

一个程序员要成为初级架构师，还是要立足于原有的知识结构，向外扩展：

（1）用逻辑视图和物理视图来描述自己用代码编写的软件系统。 =》两类重要的视图。

（2）按照特定的规则来分解与组织自己用代码编写的软件系统。 =》在视图内对系统进行功能分解。

一个程序员，如果在代码基础之上，能够完成上述两个步骤，就可以说，程序员已经能够跳出代码本身，初步具备了用架构师的抽象思维来观察、阐述整个软件系统了。

当然，要成为优秀的架构师，仅仅上述两个步骤还不够，还需进一步的学习。

1.2.2 阅读路径2：领会大系统架构设计

对于小型系统，可以从软件需求，直接到软件的逻辑架构和物理架构，而不需要经过中间的概念架构。

对于一个大型的软件系统，除了逻辑架构和物理架构之外，在软件系统还没有实现之前，还需要概念架构来阐述目标软件系统。概率架构是对软件系统关键需求的抽象和汇总，在软件需求和逻辑架构之间起承前启后的作用。所谓概念架构，主要是指软件的方案设计，业务方案，告诉程序员和客户，未来的软件系统如何解决客户的业务问题，因此，有时候也称为“市场”架构。概念架构关注可行性、可实现性以及方案的技术优势等，它并不关心如何实现，也不关心采用什么样的编程语言来实现。

1.2.3 阅读路径3：从需求到架构的全过程（全面、层次、系统、流程）

任何软件都是为了满足客户的业务需求。

在有些组织，需求的收集来自于项目经理或系统工程师。而架构师根据系统工程师的输出作为自己的输入，然后构建目标系统。

然而，真正优秀的架构师，需要有客户思维，要能够根据客户模糊的需求，还有客户真实的需求，然后把客户的业务需求转换成软件架构。或者这样说，优秀的架构师，要能够根据软件的架构识别出客户的业务需求，即能够理解软件的架构背后的业务业务需求。

从需求到架构的全过程，是一些列活动的集合，需要一群人的通力合作，它不仅仅是架构师的职责，中间还包括产品经理、市场经理、系统工程师。只有所有人员的通力配合，才构建了符合功能和性能要求的整个软件系统。优秀的架构师要能够从模糊的客户需求开始，整理和构建出能够满足客户需求的目标软件系统。

1.2.4 阅读路径4：结合工作，解决实际问题

在实际工作中，一方面，架构师要设计目标系统的架构，另一方面，架构师还需要协作开发团队，能够解决目标系统中的如下的一些技术问题：

• 系统性、全局性的技术问题

• 性能相关的技术问题

• 疑难杂症相关的问题

• 在业务领域与编程实现之间的映射，根据业务领域知识，决定技术解决方案 =》备注：很多程序员知道如何编程，是编程高手，但不知道程序背后的业务逻辑，而对业务逻辑的理解，以及如何映射成代码，这是架构师必须具备的能力。

对于业务领域知识的理解和归档，复杂度不同的目标软件系统，有不同的要求。

小型系统，有个需求列表就可以了，绘制简单的需求规格说明书即可。

对于中型软件系统，需要对需求进一步的细化，过于空洞的中型目标，软件开发人员不会知道如何实现。

愿景文档与需求列表的主要区别是，愿景文档更加的详细，展现的内容更多、视角更全，形式更多样。

需求列表通过excel就可以完成，愿景文档通常是word文档。

大型系统，相对于中型系统，增加了流程图，流程图的作用是描述复杂系统的内部的动态流程，包括：

• 数据流程图

• 行为、动作流程图

流程图是反应了“时间”对系统行为的影响。

补充：业务需求、用户需求、功能需求的区别

定义：官方

在产品的需求里面，经常有这三个概念：业务需求、用户需求、功能需求

但往往，我们很容易搞混，不清楚他们之间的关系和差异，我们先引用一下比较官方的解释：

业务需求（ Business requirement ）表示组织或客户高层次的目标。业务需求通常来自项目投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门。业务需求描述了组织为什么要开发一个系统，即组织希望达到的业务或战略目标。简单的说，就是赚钱的模式，如何赚钱。

用户需求（ user requirement ）描述的是使用该系统的用户的目标，或用户要求系统必须能完成的任务。用例、场景描述和事件――响应表都是表达用户需求的有效途径。也就是说用户需求描述了用户能使用系统来做些什么。

功能需求（ functional requirement ）规定开发人员必须在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求。

类比：房地产

这个解释其实还是蛮明确的，其实理解这三者的关键点，是要先认清楚每个需求针对的对象来源不一样：

业务需求——对应的是组织或者客户，实质就是业务的营销方，赚钱方；你也可以类比房地产市场的开发商；

用户需求——对应的是使用产品的用户；你也可以类比买房的人；

功能需求——对应的是产品，即产品要具备怎样的功能，才能满足相应的业务需求和用户需求；类比房地产市场，也就是房子本身，针对的是房子的设计方、陈建方、开发方。

类比成房地产三个角色后，你发现，开发商通常的诉求是想多赚钱，买房的人诉求是买到物有所值，甚至物超所值的房子；但不管二者怎么想，最终都是需要通过房子来实现，必须建设的房子的属性达到某个标准才能满足二者的诉求。

所以，这么一看，你就明白了，其实这三者之间的关系是：

业务需求和用户需求，只有经过需求分析的转化，变成产品的功能需求后，才能得到实现。

做这个转换的是产品经理或系统工程师。