1.4 程序员如何向架构师成功转型

通过前面的介绍，我们已经明确了架构设计和架构师的基本概念，架构视图和视角也是代表架构师从事架构设计活动的主要维度。接下去要解决的问题就是如何从普通的开发人员成功转型成一名架构师。

1.4.1 转型成功的三段式模型

转型需要一个过程，而任何过程一般都可以抽象成人、工具和流程的组合。但是对于转型过程而言，显然普适意义上的人、工具和流程并不能直接应用。如何找到更加有效的途径来完成从程序员到架构师的转变？本书提出了针对转型的特定过程模型，即图1-22所示的由思路、方法论和工程实践所构成的三段式模型。

1.思路

思路意指思考的条理脉络，通俗的解释就是心里的想法。转型需要想法，但往架构师转型的想法却受以下 3 个方面限制：意识形态（Mindset）、环境（Environment）和决心（Determination）。意识形态是转型的触动点，当我们想去做一件事情而这件事情需要付出很大努力时，通常是意识形态发生了变化，从习惯于根据详细设计文档编写代码并完成功能自测，到根据业务需求抽象出系统模型并转变成架构描述。意识的转变是工作内容转变的前提，而意识形态很多时候决定了一个人发展的高度。但一个人所能达到的高度还很大程度受限于环境因素，好的环境和不好的环境对个人发展影响巨大，而我们往往无法改变环境，只能适应环境，所以是否具备一个良好的环境也是在转型之前需要进行梳理并作出判断，必要时也应该果断采取行动。思路的最后一点就是决心。当意识形态和环境因素都已经具备，决心变成是否能够转型的关键，毕竟想要成为一名合格甚至优秀的架构师可能要比想象的困难。

2.方法论

所谓方法就是做事的手段、方式、流程，而方法论即一组方法的集合，也就是一组用于确保成功的规则的集合。对架构师而言，了解主流软件架构风格、模式和模型、通过整合各种架构体系形成自身的架构设计思想是一种方法论；能够对主流架构设计方法进行阐述、把握主流技术体系知识领域及相应的原理是一种方法论；围绕软件开发生命周期的系统工程，理解软件工程、业务架构、敏捷方法、产品交付等概念是一种方法论；作为架构师了解各种软技能需求及相应的应对方法也是一种方法论。理论指导实践，只有具备相关的方法论，才能用于工程实践。

3.工程实践

在软件开发领域，我们经常提倡使用各种最佳实践（Best Practice）。最佳实践是一个管理学概念，认为存在某种技术、方法、过程、活动或机制可以使生产或管理实践的结果达到最优，并减少出错的可能性。把软件开发的最佳方式和开发人员个人做得最好的事项一一总结出来，就是组织的最佳实践。最佳实践包含在技术和非技术领域，包含在对人和事物的处理过程，也包含在架构师所应具备的各项软、硬能力中。要想成为一名架构师，对架构师所应该从事的各项活动都需要且能够提炼出最佳工程实践作为具体工作展开的输入和模板。

1.4.2 转型思维导图

架构师转型面临的巨大挑战来自于架构师的工作特性及康威定律。

康威定律（Conway’s Law）指出设计系统的组织，其产生的设计和架构等价于组织间的沟通结构。从传统的单块架构到目前非常流行的微服务架构实际就是这一定律的一种体现。现在很多开发团队本质上都是分布式的，单块架构的开发、测试、部署协调沟通成本巨大，严重影响效率且容易产生冲突。将单块架构解耦成微服务，每个团队开发、测试和发布自己负责的微服务，互不干扰，系统效率得到提升。可见，组织和系统架构之间有一个映射关系：一方面，如果组织结构和文化结构不支持，通常无法成功建立有效的系统架构；另一方面，如果系统设计或者架构不支持，那么你就无法成功建立一个高效的组织。

康威定律给我们的指导是设计系统架构之前，先看清组织结构和组织文化，再根据情况设计并调整系统架构。要做到这一点，架构师应该具备较高的综合能力。表1-1列示了普通研发工程师与架构师工作性质的对比，从对比中我们可以看到，架构师的工作不能只关注于技术，而更重要是站在团队和组织的角度看问题。

但是我们知道软件研发人员也具有自己的思想和方法论，因此，一方面作为技术人员自然崇尚技术能力，架构师应该具备较强的技术创新能力才能让下面的开发人员信服；另一方面，架构师需要把握团队架构，在组织文化下和外部团队进行有效协作，需要具备人员和过程的管理能力，能够使内部、外部的团队成员目标一致，实现架构师的自身价值。显然，要做到以上两个方面是困难的。软件行业特定的企业文化及开发人员特定的思维模式决定了架构师不同于一般主管，如图1-23所示，架构师角色要遵守的是一种跷跷板游戏规则，若稍有不慎就可能失去平衡。

面对架构师转型所需要克服的各项挑战及康威定律给我们带来的启示，结合转型成功所需要的三段式模型，我们得出了图1-24的转型思维导图。该图上半部分代表包含思路、方法论和工程实践的三段式模型，下半部分代表转型主题，包括体系结构、架构设计和技术实现三部分在内的系统架构设计知识领域，包括软件开发系统工程，也包括架构师所需的软能力。三段式模型指导着转型主题的落实，即对每一个转型主题，思路、方法论和工程实践都是我们进行转型的基本切入点；反过来，转型主题又推动着三段式模型的进一步成熟和改进。该转型思维导图构成了本书的基本行文框架。本书后续章节内容基本按照该图进行展开。

1.4.3 作为架构师开展工作

在进行转型之前，程序员可以分析和挖掘作为一名架构师是如何开展工作的，明白架构师的日常工作内容有助于理解架构师转型过程中可能会碰到的问题，以及抱着这些问题继续本书后续章节的转型之路。图1-25梳理了作为一名架构师所从事的典型工作内容。

1.识别干系人

识别干系人的首要问题是明确谁是干系人。明确干系人可以使用图1-26中的干系人识别模型。该模型有两个步骤，首先从架构师自身出发，找到某一件与架构相关的事情，然后再通过事情找到与“我”相关的干系人。该模型虽然简单，但却可以避免找到不必要的干系人及错过所需要找的干系人。在识别干系人的过程中同样需要对干系人进行分类。理想的干系人应该具备见多识广、有担当、有权威和有代表性等特征。

2.确定原则

架构原则代表对架构设计过程中采用的方法和意图的基本声明，并用于指导架构的定义。最小化外部数据、用户信息需要进行安全性处理都属于典型的原则示例。在系统设计之前对一些基本原则的规划和沉淀被认为是一项比较好的工程实践，有助于在根据具体业务场景进行架构设计过程中保持架构的独立性及架构师的基本立场。

3.分析业务场景

业务场景分析需要先对场景进行分类，可以分为功能性场景和系统质量场景两大类，分别对应架构视图和架构视角。识别业务场景的过程可以采用从业务需求出发进行分析、跟干系人沟通、借助于架构师经验等方式。该过程的输出是一系列业务场景，确保这些业务场景按照优先级进行排序。

4.使用架构模式

所谓架构模式就是解决问题通用的方法和结构，包括发布-订阅、管道-过滤器、事件驱动架构等架构风格，也包括对象-关系行为模式、Web表现模式、分布模式架构等架构模式及各种架构模型。

5.构建系统模型

有了业务需求场景及通用的架构风格和模式，接下去就是对系统进行建模。系统建模通常使用统一建模语言UML。采用UML能够方便地建立系统所需的用例建模、静态建模、动态建模和架构模型。业界也有专门从业务领域出发的建模体系和方法论，如领域驱动设计（Domain Driven Design，DDD）模型。

6.完成技术方案

对于系统架构设计，技术方案即架构描述。架构描述中通常包含干系人的关注点、通用架构原则、架构视图的确立、架构视角的确定、视图与视角之间的一致性和相关性等要素。

7.评估与决策

架构描述需要通过评估才能正式生效。常见的评估方法包括正式评审、结构化走查、场景评估、原型系统演示等。架构师在各种评估活动中应该起到推动作用。评估只是过程，不是结果，评估的目的是与干系人达成一致。

8.管理过程事务

架构师作为技术负责人，通常也担任技术团队的Leader，自然也需要参与团队资源整合、内部/外部分享和交流、Code Review、人员招聘面试、汇报等日常管理事务。

9.开发并学习

架构师通常也需要和团队一起参与核心代码编写、参加技术会议和调研新技术。