第 8 章 软件架构师的主要职责
理需求
分模块
定接口
明时序
画愿景
找沟通
“软件开发者”这个词很容易理解，而“软件架构师”则不然。
软件架构师是一个角色，而不是一个级别。要成为一名软件架构师，绝非一夜之间或一次晋升那么简单。这是一个循序渐进的过程，需要时间和经验的积累才能逐渐获得这个角色所需的技能、经验和信心。
注意，我这里说的是“角色”；它可以是一个人，也可以由团队共同扮演。
大多数跟软件开发团队有关的角色都比较容易理解——开发人员、测试人员、流程经理、产品经理、业务分析师、项目经理等等。
什么是软件架构角色？有些软件团队对软件架构角色有没有明确的定义，常见的原因不外乎“没有”或“有，但我们不用”，同一个团队的不同的人往往会给出不同答案。
目标系统的软件架构的必要性通常是公认的，但在很多的软件团队，软件架构师这个角色的责任往往并不明确，通常有不同角色或称呼的人来承担，如比如架构师、技术主管、首席设计师，或直接有开发人员自己承担等。
下面是我认为构成软件架构角色的主要职责：
8.1 软件架构的驱动力：需求来源，架构输入
这个角色首先要理解业务目标和软件架构的驱动力，即什么是软件架构的输入，是什么决定了软件架构。
软件架构师必须考虑如下几个主要方面：
功能性需求（显性）
非功能性需求（隐性）
环境的限制（隐性）
软件项目经常纠缠于询问用户需要什么功能，却很少问他们有哪些非功能性需求（或质量属性）。
有时候利益相关者会告诉我们“系统一定要快”，这太主观了。
非功能性需求和限制往往对软件架构有巨大的影响，因此明确地将其纳入软件架构考虑的范围，可以保证它们被考虑到。
8.2 设计软件：架构设计6大步骤
设计软件的过程是软件架构角色的一部分，这一点应该在意料之中。
这涉及如下的6个关键的步骤：
步骤1：理解业务需求：功能性、非功能性、限制条件
步骤2：技术与方案选择
步骤3：技术风险分析与方案验证
步骤4：规划软件系统的整体结构
步骤5：为交付设定一个愿景，即未来交付的是什么样的目标系统。
步骤6：质量保证与架构演进
不管你想做到多敏捷，你可能都需要花一些时间去明确思考架构要如何解决利益相关者（干系人）提出的业务需求问题和程序员关心的问题，因为你的软件系统自己搞不定它们。
软件设计的一个关键部分是技术选择，这通常是一个有趣的实践，但也有一定的挑战。例如，有些组织有一份允许使用的技术清单，你只能从中选择，有些组织则规定不允许使用特定许可的开源技术。
接下来是考虑其他所有因素，比如：成本、软件许可、供应商关系、技术战略、兼容性、互操作性、升级策略、最终用户环境等等。这些因素掺杂在一起，常常会把选择一个客户端软件开发技术之类的简单决策彻底搞成一场噩梦。
需要有人负责这个技术选择的过程，这完全属于软件架构角色的职责范围。
程序员会按照架构师选择的技术进行实现！！！
8.3 技术风险分析、管理与方案验证 - 提前预测与预防
到目前为止的内容可以帮你专注于构建好的解决方案，但并不能保证成功。
把最好的设计和最好的技术简单地拼凑在一起，并不意味着整个架构就会成功。
影响技术方案成功的因素有很多，比如：
你选择的技术是否真的奏效，也是个问题。很多团队都有“做不如买”的战略，为了可能会节约成本而去使用一些（商业或开源的）产品。然而，很多团队也因为听信供应商网站或西装革履的销售人员的宣传，结果遭了殃。
似乎很少人会问技术是否真的以设想的方式工作，能证明的人更少。无论是外购的第三方技术，还是开源软件，还是自己开发的新软件，很多时候，最终的实现结果，并非按照预先的方式工作！！！这是软件项目中常见的风险：
或功能不完备
或性能指标不达标
或行为方式与预想不一致等等。
技术选择其实就是风险管理，当复杂度或不确定性高的时候要降低风险，当有利可图时再冒点险。
所有的技术决策，在做出选择时都要把全部因素考虑在内，这些技术决策也需要评审和评估。
在软件实现阶段，可以通过测试对软件进行评估和验证。
在架构设计阶段，软件还没有实现，架构师必须在软件开始实现之前，通过原型开发、模拟仿真等手段，对有风险的关键性技术进行架构验证和测试。
8.4 质量保证：通过项目管理来实现
即使有了世界上最好的架构，糟糕的代码编写与交付也能让原本可以成功的软件项目失败。
质量保证也确保团队代码实现与交付与架构愿景保持一致。
质量保证应该是软件架构师职责的一部分，包括：
代码评审 （项目管理）
建立保证基线，（项目管理）
引入一些标准和工作实践，如编码标准、设计原则和工具。
架构师有责任参与代码的实现与交付过程中，并确保架构的设想被成功的代码实现！！！
如果架构师的设计的架构并没有成为代码的一部分，架构师设计的架构就是一纸空文，价值没有得到体现。
一个软件系统很少孤立存在，可能有不少人要为整个架构过程作贡献。任何担任软件架构角色的人都需要与这些人合作，以确保架构能与周围环境成功整合。如果不合作，就等着失败吧。
这些决包括了：
定义业务需要规范的团队
从需要理解和认同架构的直接开发团队，
一直到那些对安全性、数据库、运营、维护或支持感兴趣的人组成的扩展团队。
项目管理团队
8.5 代码实现与架构师的职责
架构师是否需要参与代码的编写，不同的公司，不同的项目的做法是不相同的。
大多数最优秀的软件架构师，都有软件开发的背景。
由于种种原因，许多组织并不认为写代码是软件架构角色的一部分。
（1）情形1：熟读代码的结构、对他人编写的代码进行评审。
作为一个“实践派软件架构师”并不一定指涉足程序员日常的编码任务，但你需要持续地参与到代码交付的开发流程中，积极地帮助引导和塑造它。
（2）情形2：亲自编写代码
许多软件架构师都是构建大师，所以经常练手是有意义的。
此外，编码为架构师提供了一种与团队分享软件开发经验的方式，从而帮助他们更好地理解如何从开发的角度看待架构。
一般来说，一个写代码的软件架构师会更有成效也更快乐。你不应该因为“我是架构师”，就把自己排除在编码之外。
（3）情形3：不参与代码过程
许多公司都有阻止软件架构师参与编码工作的政策，因为他们的架构师“太宝贵了，不该承担日常编码工作”。
有些情况下要参与到代码级别并不实际。例如，一个大型项目通常意味着要照看更大的“大局”，有可能你根本没时间写代码。
8.6 架构演化：闭环、反馈、优化
架构设计并非是开环设计过程，而是一个闭环控制过程。
架构师不能把设计好的架构当作流水线就交给下一个环节来处理。在整个代码实现和交付过程中，架构师需要依据不断变化的新需求和团队反馈来对架构进行优化和演化。
确保架构与代码保持一致
确保架构得到持续优化
第 9 章 软件架构师应该编码吗？
前面提到，架构师是否需要参与代码的编写，不同的公司，不同的项目的做法是不相同的。
在本章节，探讨个人的观察：架构是如何参与到代码中。
9.1 关于架构师是否需要编写代码的一点建议
我的建议是让编码成为你作为软件架构师角色的一部分，只要把自己当作软件开发团队的一份子就行了。换句话说，你有一顶软件架构的帽子和一顶编写代码的帽子。你不见得要成为团队里写代码最厉害的，但参与到实践和交付流程的好处非常大：
毕竟，“知”和“行”还是不同的。
团队欣闻你要贡献代码，通常会受到鼓励，确保你的设计能落到实处。创建能实际实现的软件架构，这样做的好处显而易见。
除此之外，贡献代码还能帮助你和团队建立起融洽的关系，有助于缩短存在于很多软件团队的架构师和开发者之间的距离。
如果你了解如何编程，往往会忍不住对开发者该如何编写代码提出建议。但你需要注意，如果你没有参与项目的编程，开发者多半会无视你的编码经验。他们还会认为你越权，影响了他们的工作，所以尽量别在这方面指指点点。但如果参与到代码的编写，情形就不同的，你已经成为他们的一分子。
9.2 构建原型、框架和基础
当你被看作开发团队的一员时，软件架构的角色可能会轻松得多。
然而有时这却不太可能，晋升或被指定为软件架构师带来的一个问题在于，
你可能会发现自己不能像期望的那样写很多代码：
这可能因为时间压力，因为你有很多“架构”工作要做。
或者只是公司政策不允许你写代码，我见过这样的情况。
如果是这样的话，为软件系统中有疑问的概念，构建原型和证明是一个很好的参与方式。这让你可以和团队建立起融洽的关系，也是评估你的架构是否管用的好办法。作为替代，你可以帮助团队建立可用的框架和基础。
9.3 进行代码评审
显然没有什么能代替给真正的项目编码，如果参与（或做）代码评审至少能让你了解新技术及其应
用。但在代码评审需要注意，如果你没有相应的编程技术与经验，这样的编码评审可能会损害你的架构师名声和时间。
9.4 实验并与时俱进
你需要保持一定水平的业务技能和编程能力，才能称职地用它来进行软件方案设计。
但是，作为架构师的你要如何维持编码技能？
在工作之外你往往有更多的空间来维持编码技能，
从贡献开源项目，到不断尝试你感兴趣的最新语言、框架、API。
书、博客、播客、会议和聚会都能达到这个目的。
9.5 软件架构师和雇主公司之间的矛盾
设计软件时，编码是必不可少的，因为需要熟悉最新的技术，搞清楚我设计的哪些东西能工作。
许多组织认为编码是软件开发过程中最容易的部分，因此他们通常让另一个国家的其他人来做这件事，以为这样能省钱。好的代码在这样的组织看来也是“低价值”的。组织中软件架构师的资历和编码工
作的价值就脱节了，矛盾由此产生，那些大型组织里的矛盾最严重。
9.6 你不必放弃编码
我们会经常涉及到这个问题：“如果软件架构师打算在公司的职业道路上有所作为，是否还能继续编码”？不同的人可能与不同的诉求：
如果这些人真的很喜欢他们所做的技术，你可以继续写代码。
有些组织中，分工细致，高级职位是不需要写代码，管理者可以不同技术，架构师可以不用编写代码。
有些组织中，软件架构师在满足非功能性需求、进行技术质量保证、确保软件符合其用途等方面，要承担很大的责任。这是一个领导的角色，编码（以身作则）是保证项目成功最好的方式之一。
无论你怎么做，在不断变化的世界中，编码是一个保持技术能力的好办法。
9.7 不要把全部时间都用于编码
软件架构师不必放弃编码，但并不意味着架构师把大部分的精力放在编码本身上。
如果你花全部时间写代码，那软件架构角色的其他部分由谁来扮演？
第 10 章 软件架构师 VS 建造大师
在中世纪，设计建筑的人只是极少数，却组成了建造大师的高端社团。把建筑的隐喻应用到软件不见得合适之所以做这样的隐喻，是因为建造大师名副其实是他们这门学问的大师，一旦达到了这种高度，建造大师是继续建造还是让其他名气不大的人来做？软件行业的架构师面临着同样的境地。
10.1 被误解的架构师
在过去的十年间，为了更有效、更快速地交付软件系统，敏捷开发团队在编码前做的预先思考的工作量，结果现在“架构师”在软件团队里往往被架空或被弱化到开发团队中。很多团队都向着扁平化和自组织努力，从表面上看这不需要再专设技术领导。
另一个因素是，许多人认为架构师都在做高层次的抽象思维。“象牙塔架构师”或“PPT架构师”等说法，用来指代那些设计解决方案时从不考虑细节的人。
实际上，不同的组织和业务领域，对架构师的诉求是不同的，上面提到的两种场景，只是众多场景中的一种，就像构建茅草房不需要建筑师一样，然而，在更多的场景，亦然需要大量的建筑师，架构师承担类似这“建筑师”的职责。
10.2 建造大师真的会建造吗
建造大师是否真的建造了什么？
在古代和中世纪的历史中，大多数建筑设计和建设都是工匠完成的：下至石匠和木匠，上至建造大师
顶尖的石匠就是一个石匠大师。然而，建筑大师这个头衔，指的是全面负责建筑工地、让石匠大师们为他工作的那个人。建筑大师也负责木匠、玻璃工匠等。实际上，每个建筑工地上的人都在建筑大师的监督下工作。然后，石匠大师为将要建造的东西设计结构、美学和象征等方面的特性，组织后勤，还要评定工作的优先级并决定它们的顺序。
10.3 与建造大师角色的差异
软件架构师被看作是首席设计师，是把项目的每件事凝聚在一起的人。但建筑师可不会干这些。建筑师关注的是与想要建筑的客户交流。他的精力集中在客户觉得重要的事情上，比如建筑的布局和外观。但建筑也不仅限于此。因其背后蕴含的包括物理定律在内的丰富知识，建筑现在被看作是一门工程学科，这些知识能够建模和预测建材的行为。
相比之下，软件开发行业还比较年轻，正以惊人的速度发展。今天的建筑大多还是使用和几百年前相同的材料，但似乎我们每20分钟就会发明一种新技术。我们生活在“互联网时代”。除非我们这个行业发展到软件的构建方式和预测工程项目相同，否则团队中有人一直跟随技术的发展，有能力做出如何设计软件的正确决策，还是很重要的。
换句话说，软件架构师还需要扮演结构工程师和建筑师的角色。
第 11 章 从开发者到架构师
软件架构角色的经验是一个渐进的过程，先是在别人的监督下写代码，渐渐地，获得更多的经验，就开始承担更大的设计任务。
软件开发和架构之间的界线很诡异：
有些人会告诉你这个界线并不存在，架构就是由开发者负责的设计流程的延伸。
另一些人则说这是一个巨大的深渊，只有志向远大的开发者才能跨过，他们坚信必须尽可能地
抽象，而不拘泥于讨厌的实现细节。
这中间有一种务实的平衡
但它也带来了一个有趣的问题：你如何在开发者和架构师两者之间穿梭？
软件架构就是总览全貌，看清“大局”，才能理解软件系统整体如何工作。这可能有助于区分软件设计和架构，然而不一定有助于理解软件开发者如何转换到软件架构的角色，因为开发者和架构师都可以设计软件的架构。
11.1 软件架构师的职责
步骤1：理解业务需求：功能性、非功能性、限制条件
步骤2：技术与方案选择
步骤3：技术风险分析与方案验证
步骤4：规划软件系统的整体结构
步骤5：为交付设定一个愿景，即未来交付的是什么样的目标系统。
步骤6：质量保证与架构演进
从上面可以粗略看出，架构师与软件开发者职责上的差别。
11.2 模糊的界限
不管你认为软件开发与架构之间的界线是捉摸不透还是深渊，人们对于软件架构角色的经验水平各不相同，这种不同，增加了软件开发和架构之间的界线的模糊程度。
在实际中，很有可能不少软件开发者已经为承担部分软件架构的角色和相关的工作，使得软件开发和软件架构之间的界限越发模糊。
11.3 跨越界线是开发者自己的责任
然后，大多数开发者都不会在某个星期一早上醒来之后，突然宣称自己变成架构师了，通往软件架构的道路很大程度上也是一个演化的过程：
给一个软件系统的架构出力和为之负责之间，有一个很大的差异。软件架构师要对软件架构全权负责，而不是对软件架构的参与或出力。
软件架构师需要跨越不同领域，融会贯通的不同领域的技能、知识和经验。
能否跨越软件开发者和架构师的漫长的模糊的界线，取决于开发者长期的努力和经验的积累。
第 12 章 架构师是T型人才
不管别人怎么说，软件架构都不是一个“后技术”或者“非技术”的工种。在白板上画一堆框、线和云，交出这种“软件设计”，可不是软件构架师所为。架构师是T型人才。
12.1 深厚的技术能力
“T”指的是技术，这也正是优秀的软件构架师应该懂得的。
作为软件开发者，我们倾向于去搞懂：编程语言语法、API、框架、设计模式、自动化单元测试和其他所有日常使用的底层技术。
对一个软件构架师来说，这些属于架构师具备的基础知识，必备的技能。
扮演软件构架角色的人必须懂技术，这样他们才能如实、高效、正确地回答以下类型的技术决策问题：
该方案是否可行？
该方案是否有效？
我们要这样去构建吗？
12.2 宽广的知识面
相比与一般程序员，软件架构师需要回答更多的技术决策问题：
和其他可选技术相比，我们所选的是否最合适？
对该系统的设计和构建，还有哪些选择？
是否应该采用一种通用的架构模式？
我们是否明白所做决策的利弊？
我们照顾到了品质属性的需求吗？
如何证明这种架构行之有效
要回答上述问题，精通编程语言和编程技巧是无法胜任的。架构师必须具备如下技能：
（1）业务技能：不同业务应用，需要不同的业务技能
（2）软件技能：编程、软件工程、计算机原理
（3）架构技能：常见架构方法与常见的架构（本系列的重点）
（4）软技能：（本系列的重点）
领导力
沟通能力
影响力
情商
等等
12.3 软件架构师是通才型专家
软件架构师，既要是通才，同时在某个领域也要是专家，称为通才型专家。
大部分最优秀的软件设计师都有软件开发背景。这并不意味着他们是团队中最好的程序员，但他们能够在底层细节和大局之间切换。他们还有着深厚的技术积累，以及从多年软件构建的经验中获得的广阔的知识面。但他们不能（也不会）总是知道一切。再加上也很难找到一个只使用单一技术栈的软件系统。
虽然一般性的设计知识、技巧、模式和方法通常适用于许多不同的技术，但不明白如何将其成功应用在底层细节上可能会导致问题。这是否意味着对任何特定软件系统中使用的所有技术，软件架构师都应该是专
家？不，合作才是关键。找到那些知你所不知的人，与他们紧密合作。
没有谁说软件构架的角色不能分享，而且欣然认识到你的知识差距往往是创造更和谐的工作环境的第一步。结对编程有好处，那么为什么不能结对架构？
实际上，在超大型组织中，软件架构就是有一个架构团队来实现的！！而不是单个的个人，这就需要架构师需要协同多个架构师、系统工程师、软件开发工程师共同完成软件架构的设计。
12.4 软件架构本身是技术活
支撑软件架构角色的技术知识需要深度与广度并存的知识组合。
如果设计软件、画架构图的人回答不了该架构是否行之有效，那他们可能不是这项工作的正确人选。并不是真正的架构师，真正的软件架构绝对是一个技术工种。
第 13章 软技能
当然，对应架构师而言，但光有技术还不够，良好的软技能也至关重要。
不管你怎么看，软件架构师都是一个领导的角色，对开发团队中不少人说，作为软件架构师的你都可能会是重要的榜样。原因是什么？团队中的一些人可能就是有抱负的软件架构师。这种处境让人飘飘然吧？然
而如果你把视线移开，还是能看到一些负面的东西。
不管你是否意识到了，你都在一个非常有影响力的位置上，你的一举一动都被整个开发团队看在眼里。不管愿不愿意，单是这一个原因，你就有改变整个团队的能量。如果你很主动，开发团队也很可能变得主动。如果你对工作充满热情，团队其他人也会很可能充满热情。如果你对每件事都很乐观，开发团队也会这样。
你几乎可以把这看作是正能量的回路，你的热情带动了团队，他们的热情也带动你。这无比梦幻，但也不难看到由于你不恰当的行为而造成的损害。任何程度的懒散、冷漠或悲观传染到团队的速度，都会比你说“但我们会没事”更快，然后你就会陷入消极的恶性循环。
我们不常谈论软件架构师的软技能，但软技能有时候比过硬的技术更重要。交付产品的团队才是愉快的团队。作为领导，让团队保持积极是你的责任，你的角色在整个团队中不应被低估。
领导力：简单来说，领导力就是创造共有的愿景，并带领人们向着共同目标前行的能力。
沟通：你有世界上最好的想法和愿景，但如果不能有效地传达给其他人，也是死路一条。这包括了软件开发团队内外的人，要使用适合受众的语言和细节水平。
影响力：这是重要的领导技能，每个人都有自己的想法和计划，你在处理时还得让他们都不反感，并主动地去追求你需要的结果。好的影响力也要求好的倾听和探索能力。
信心：信心很重要，是有效的领导力、影响力和沟通的基础。但信心不代表傲慢。
合作：软件架构角色不应该被孤立，（与其他人）合作想出更好的方案是一项值得实践的技能。这意味着倾听、谦虚和响应反馈。
指导：不是每个人都对你正尝试做的事情有经验，你需要对他们进行角色、技术等方面的指导。
辅导：辅导是对人进行学习方面的指引，而非告诉他们怎么做一件事。作为领导，你可能会被要求去辅导团队中的其他人。
动力：这说的是保持团队愉快、开朗和积极。团队要有积极性，才会跟随你这个软件架构师所创建的任何愿景。你还要面对团队中一些人不买账的局面。
润滑剂：你经常需要退后一步，促进讨论，特别是团队内有不同意见时。这需要探索、客观，帮助团队达成共识。
政治：每个组织都少不了政治。我的咒语是，离得越远越好，但你至少应该明白周围发生了什么，这样才能做出更可靠的决策。
责任感：你不能因为失败就责备软件开发团队中的其他人，有责任感对你而言很重要。如果软件架构不能满足业务目标，无法交付非功能性需求或技术品质很差，那都是你的问题。
授权：授权对任何领导角色来说都是一个重要部分，作壁上观和事必躬亲之间有一条模糊的界线。你应该学会在适当的时候授权，但请记住，你授权的可不是责任。
第 14 章 软件架构不是接力运动
更敏捷的软件团队很可能由除了一项核心专长，还具备更多综合知识和经验的通才组成。理想状况下，这些跨领域的团队成员会一起工作，运作和交付一个软件项目，承担从收集需求和架构到编码和部署的所有事情。尽管很多软件团队都朝自组织的方向努力，然而现实中他们往往更大、更混乱，而且由专才构成。因此，这些团队往往需要，也确实有一个人担任技术领导。架构师就承担了这个责任。
14.1 解决方案架构师不值得鼓励
有很多人，特别是在大型组织里，自称“解决方案架构师”或“技术架构师”。他们设计好了软件，为自己的方案编写文档，然后扔给一个单独的开发团队。这个方案一旦“完成”，架构师就会去别的地方重复这个过程，甚至往往对开发团队的进展看都不看一眼。结果往往就是接手的团队不会对这个方案负责，最初创建的“架构”变得脱离现实。
14.2 要有人负责大局和变化
不同于典型的软件开发者，软件架构角色需要通才。这肯定是在软件项目起航阶段掌舵的角色，包括管理非功能性需求，整理出对上下文和环境因素敏感的软件设计。但也要不断地转向，因为你选择的航线可能需要在途中调整。毕竟，敏捷方法已经向我们展示了，不一定预先就有（或需要）所有的信息。
创建一个最初的愿景，交流，并在整个软件开发的声明周期中潜在地演化它，这些对一个成功的软件项目是必需的。单是这个原因，让某人来创建这个愿景，然后让另一个团队去（试着）交付，就毫无意义。当这种事情发生时，初始的设计方案本质上就成了在架构师和开发团队中传递的指挥棒。这很低效，甚至无效，文档交换也意味着很多与创建愿景相关的决策上下文也丢失了。祈祷开发团队永远不需要问任何关于设计或其意图的问题吧！
真正的自组织团队不会有这样的问题，但大多数团队还没有成熟到那个程度。在整个交付中，要有人负责大局，同时为保证软件顺利交付承担责任。软件开发不是接力运动，顺利交付也不是“实现细节”。
第 15 章 软件架构要引入控制吗
软件架构向软件项目引入了软件结构和愿景，是否也引入了适当的控制，确保软件架构得到实施呢？
答案是肯定的。
15.1 提供指导，追求一致性
需要通过指导和限制条件，确保项目架构得以正确的实现。
15.2 控制的程度
一种是架构师强势，不允许开发做任何的改动
一种是架构师放权，架构仅供参考，最终的实现完全由开发自己决定。
一种是架构师协商，架构师通过从开发哪里收到的反馈动态调整架构。
第 16 章 避免常见的错误
16.1 避免开发者只关注底层细节
我们都梦想在这样的团队中工作：
所有人都经验丰富，从代码到架构，对软件考虑得面面俱到。然而现实并非如此。
大多数团队，成员经验参差不齐，有些甚至刚接触IT这一行，另一些则“接触过几
次”。作为软件开发者，代码是我们主要的关注点，但如果你的团队只关注底层细节，会发生什么？想象有一个用上了所有最新编程语言特性的代码库，代码很好地解耦，测试也完全自动化。这个代码库的结构和格式都堪称完美，但如果系统在部署到生产环境时有可伸缩性的问题，一切就毫无用处。
这时候，团队就需要一个架构师，对全局的技术负责，对性能、可伸缩性、可用性、安全性负责。
16.2 避免闭门造车的独裁架构师
软件架构角色不同于开发者角色。
有些人把它看作开发者的上级，有些人则看作同级。不管你怎么看，架构师都要负责“大局”。很多团队了解软件架构的重要性，会找来一个有着受人尊敬的“架构师”头衔的人，却只是把他们硬塞在凌驾于团队的位置上。发生任何事，都会在架构师和原本要一起工作的团队之间造成巨大的鸿沟，让架构师立刻被孤立起来。
很多软件团队里，在开发团队和架构师之间都有这个不必要的鸿沟，特别是当架构师被看作是只会下命令的独裁者会这导致了几个问题：
不管架构师的决策是否正确，开发团队都不尊重他；
开发团队变得缺乏积极性；
重要决策因为职责不明而无人负责；
因为没有人负责大局，项目最终苦不堪言。
架构师要尽量避免这种情形的出现。
16.3 拉近距离
（1）如果你是软件架构师
包容与合作：让开发团队参与软件架构的过程，帮助他们了解大局，认同你所做的决策。确保每个人都明白决策背后的原理和目的，会对此有所帮助。
动手：如果可能的话，参与一些项目的日常开发工作来提高你对架构交付的理解。根据你的角色和团队规模，这可能会不太现实，那就通过其他方式来了解底层的进展，比如协助设计和代码评审。了解软件的底层如何工作会让你更透彻地了解开发团队对架构（比如：他们是否对其视而不见）的感受，也会为你提供有价值的信息，可以用来更好地塑造/影响架构。如果开发者感到痛苦，你也要感同身受。
（2）如果你是软件开发者
了解大局：花些时间去了解大局将帮助你了解做出架构决策的语境，增强你对系统整体的理解。
挑战架构决策：有了对大局的了解，你现在就有机会挑战眼前的架构决策。架构应该是一个合作的过程，而不是由那些不参与项目日常工作的人说了算。如果你发现有些事情你不理解或不喜欢，挑战
它。
申请参与：很多项目都有一个负责架构的架构师，这个人通常会承担所有的“架构工作”。如果你是一个开发者，想要参与其中，提出来。你说不定帮了架构师一个忙！
（3）软件架构的合作方式
无论项目规模如何，确保大局不被忽视是成功的关键，而这个重任往往落在架构师的肩上。减少开发者和架构师之间不必要的鸿沟，可以让大多数软件团队从中获益，双方都可以努力减少这个鸿沟。开发者可以增加他们的架构意识，而架构师可以加强与团队其他人的合作。
第 17 章 未来的软件架构师在哪里
17.1 指导、辅导和师徒关系
在大多数软件开发项目中，指导和辅导是一项被忽视的活动，很多团队成员没有得到所需的支持。
技术领导力就是要引导整个项目，有时候个人需要协助，架构师就需要主动指导、辅导、协助他人。
指导和辅导提供了一种方式来增强人们的技能，帮助他们完善自己的职业生涯。这种协助有时候是技术性的，有时候是软技能。
从技术的角度来看，为什么承担软件架构角色的人不应该帮着指导和辅导呢？我认识的大多数架构师正是因为他们在一个或多个技术领域有大量的经验才当上架构师的。既然是这样，为什么那些架构
师不应该通过分享一些自己的经验来帮助别人？学徒模式正是过去建造大师传承技艺的方式。
简单地说，架构师要懂得分享，把自己的经验分享给团队，指导团队的成长。
17.2 我们正在失去技术导师
可悲的是，在我们的行业里许多开发者为了在企业晋升机制中有所发展，被迫转向非技术的管理岗位。
讽刺的是，被迫离开技术岗位的往往是最优秀和最资深的技术人员，而软件团队中则失去了最有价值的技术领导、架构师和导师。今天的开发者还会在将来继续重蹈覆辙。
在国内，官本位的思想的影响下，这种现象尤为严重。
17.3 软件团队需要休息和学习来提升自己
许多团队失去了最资深的技术人员，留在团队中的人受制于外部带来的压力。
很多团队意识到他们应该努力提高，但却没有时间或缺乏动力。
为了提高，软件开发团队需要一些时间远离日常工作，进行思考，但他们也需要保持对软件开发流程各个方面的关注。
第 18 章 每个人都是架构师，除非他们有其他身份
18.1 每个人都是架构师
很多软件团队都朝着敏捷和自组织努力，在这种现代软件开发团队中，集体拥有代码，以便团队中任何人都有权做出改动。这种方式奏效暗示团队中每个人至少都对“大局”有一些基本的了解。
不同成熟度的团队，退软件架构的诉求是不同的。
生存型（混乱）：需要一种直接指挥和控制的领导风格。
学习型：需要一种指导的领导风格。
自组织型：需要简易化来确保平衡不受影响。
18.2 敏捷团队需要架构吗
可惜，许多团队把“大局”上的技术技能看作一种不必要的邪恶，而不是重要的补充，可能是因为他们过去深受大型预先设计之害。有些人也过于渴望“敏捷”，以至于忽略软件开发流程的其他方面。接踵而至的是混乱而非自组织，这样的团队也面临着需要更直接的领导方式的挑战。毕竟，他们在努力变得敏捷。单个点负责项目的技术层面，也跟他们对敏捷团队的想象相冲突。这种冲突使人认为敏捷和架构是对立的：你只能拥有其中一个。与敏捷对立的不是架构，而是大型预先设计。
敏捷软件项目仍然需要架构，因为那些围绕复杂非功能需求和约束的棘手问题不会消失，只是对架构角色的执行不同。
集体代码所有制，每个人都要能在架构的层次上工作，因此每个人某种程度上都是架构师。还不是自组织阶段的团队如果试图跑太快，就会陷入挣扎。尽管人们的愿望是变得敏捷，集体代码所有制和架构角色的分配都有可能阻碍混乱的团队，而不是帮助他们。混乱的团队需要更直接的领导方式，单个点负责软件项目的技术层面，将使他们受益。换句话说，他们会受益于一个人负责软件架构的角色。理想的话，这个人会指导别人，让他们也能以这个角色产生帮助。
软件架构师要一个还是多个？
一个人承担责任还是团队共同分担？
不论敏捷与否，软件架构的角色都是存在的。
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
