《架构师修炼之道》摘录13-鼓励团队参与架构设计

本系列内容来自《架构师修炼之道》。在自己的笔记中以半摘录的方式，用 blockquote 穿插自己的思考和感悟，以加深对内容的理解和消化。

全书整体分为三个部分

1. 第一部分介绍软件架构的基础知识和架构师必备的设计思维
2. 第二部分讲解架构师需要掌握的核心技能和知识
3. 第三部分讨论一系列使用的架构设计方法

前两部分适合从头到尾通读，第三部分用于参考和检索。

开发现代软件系统需要借助团队的力量。科技进步 （容器技术、云设施等）赋予了开发者更大的灵活性和权力。随之而来的新架构模式（微服务、Faas 等）则对开发人员提出了更高的要求。他们必须清楚自己的决策会对包括质量属性在内的系统特性造成什么样的影响。

在现代软件开发中，开发人员与架构师的角色几乎没有差别。这并不是说现代软件开发团队不需要架构师，而是说我们需要的不再是那种传统的、居高临下的技术领导者。

今天的架构师应该与团队一起设计架构，而不是独自为团队设计架构。架构师应该既是技术专家，也是教练和导师。本书前两部分讲解了架构设计的核心原则和方法。现在，你要学习让团队与你一起成长，共同设计出色的软件架构。

13.1 提倡架构师思维

开发人员普遍具有架构师思维的团队更容易打造出出色的软件。这样的团队将具有更高的探索效率和开发质量，因为大家都有能力对设计角色做出有效评估。编写文档页变得更加容易，简明扼要地描述就能让团队成员看懂。

让所有团队成员参与设计架构，大家就会产生对系统的责任感——系统会变成“我们的系统”，而不仅仅是“这个系统”。有了这种共同的责任感以及对设计意图的理解，当系统发生变更时，修改过程会变得容易得多。更少的返工、更好的质量、更有效的沟通将带来更快的开发速度。

责任感的增强将带来更大的满足感，这反过来又会进一步增强团队的参与度。大家共同参与架构设计能产生 1+1>2 的效果，从而开发出更优秀的软件。

在鼓励团队参与设计的同时，还要传授设计技能，这样大家才能在实践中磨炼成长。既要给大家试错的机会，也要保证架构设计准确无误，这样才能确保交付有价值的软件。

为团队提供恰到好处的指导，既确保大家走在正确的道路上，也免得架构师自己检查每一项设计决策。传授技能、增强互信，不断学习和改进。此外，架构师要比因队成员多看一步、先行一步，带领大家避开陷阱与误区。

13.2 传授技能，辅助决策

为了让团队对系统形成共同的责任感，架构师必须向团队成员提供充分的支持。他应该向团队成员传授知识与技能，以便他们自己做出设计决策。架构师应该成为教练和导师，而不是制定所有设计决策的权威。如果可能的话，架构师应该尽可能让团队自己做决策，而不是亲自动手。下表对比了二流架构师与优秀架构师的区别。

undefined

13.3 为团队创建实践机会

我们希望赋予团队更多的设计权力，但这需要团队先做好准备。只有通过实践，团队成员才能得到锻炼、获得经验。可是交付时间步步逼近，要从紧张的开发工作中抠出时间做培训可不容易。这里有几个方法。

13.3.1 结对设计

结对是最简单、最安全的练习设计的方法，比如你可以邀请一位同事和你一起做设计。如果你想理解某一个模型，也可以邀请一位同事做白板涂鸦。在与利益相关方讨论质量属性时，也可以带上一位同事。在团队评审一份决策文档之前，你最好先找一位团队成员一起看一遍。

13.3.2 搭建支架

在教育理论中，支架式教学 (instructional scaffolding)，是指教师设法为学生提供的支持，帮助学生顺利学习新知识。我们在学校里都体验过支架方法，比如详细批改的试卷和作业、老师制作的辅导讲义、家庭作业模板等。向团队传授架构知识时，我们也可以采用相似的方法。

• 为常见的设计任务建立模板。
• 在代码评审中给出建设性的意见。
• 为新组件搭好代码框架。代码框架应当能提纲挈领地描绘采用的模式，同时仍然需要向其中填充内容。建议你与同事结对搭建代码框架。
• 对设计任务设定期望，并举例解释什么是好的设计，什么是糟糕的设计。
• 为各种思维模式和设计任务建立检查清单，帮助团队成员建立架构思维。

13.3.3 引入架构导轨

架构导轨可以约束设计选项，从而确保细节设计不会大幅偏离既定架构。架构导轨既可以用来简化设计（见第 5.1节），也可以为团队创造安全的实践机会。架构导轨降低了破坏架构的可能性。

架构导轨有很多种形式，作用各不相同。设计方针 （design policy）就是一种简单的架构导轨，它规定了该做哪些事，不该做哪些事。在安排团队做设计时，可以给出临时的设计方针。如果要降低风险、提升质量或克服团队的弱点，则可以设立正式的设计方针。

另一种常用的架构导轨是要求使用指定库，这种方法能够降低开发难度，同时避免犯一些低级错误。最严格的架构导轨是融入代码的约束（见第8.3节），在这种情况下开发人员是很难再犯错的。

13.3.4 举办交流会

如果团队对架构十分着迷，那么不妨举办几场交流会 (information session） 就具体话题展开探讨。交流会时间不必很长，见缝插针地开几次短会跟开长会的效果一样好。为了提高交流效率，应该提前把讨论涉及的知识点传授给大家，避免出现临阵磨枪的现象。

随着团队成员逐渐成熟，他们会更频繁地发表意见。这是好事，应该鼓励大家这样做。团队成员愿意分享改善架构的建议，说明你的付出有了回报。这时你可以考虑让他们承担更多的设计任务了。

13.4 设计下放

随着越来越多的团队成员参与架构设计，必须决定下放(或保留）多少设计权限。我们希望尽可能多地下放设计，当然前提是确保架构与核心质量属性不受影响。在《管理 3.0：培养和提升敏捷领导力》一书中，Jurgen Appelo 提出了 七级权限。我们可以借助这七级权限决定如何下放设计。

• 第一级：告知。由你做设计决策，告诉团队结果。通常需要展示你的设计。
• 第二级：贯彻。由你做设计决策，然后向团队说明这样设计的理由。
• 第三级：咨询。在做设计决策前咨询团队的意见，但最终还是由你做决策。
• 第四级：商定。与团队合作，就设计決策建立共识。大家有平等的话语权。
• 第五级：建议。通过观点、见解影响团队，但是由团队其他成员做设计决策。
• 第六级：审查。由团队做决策，请他们解释为什么这样设计。
• 第七级：委托。委托另一位成员做决策，由他对结果负全责。你作为辅助成员，帮助团队收集信息。

下放多少设计权限要视具体情况而定。恰当地下放权限能增强团队信心、活跃开发氛围、提高敏捷性。下放的权限太少可能会破坏因队信任，让团队成员觉得束手束脚；下放的权限太多则可能造成团队焦虑，设计结果也难以令人满意。

在带领缺少经验的团队时，千万不要下放过多的权限。这样做很可能会破坏团队信任、造成严重的返工。更糟糕的是，如果你没能及时发现其中的问题，有可能造成无法挽回的损失。

下放设计权限不存在标准的做法，你只能通过尝试我到适合自己因队的运作方式。检验下放权限是否合适最简单的方式是多与团队成员交流，了解大家的意见。

13.4.1 何时保留设计权限

如果你觉得项目风险高，那么在权限下放上还是保守些比较好。带领经验不足的团队时，建议只采用前三级权限。经检验，这是一种比较可靠的做法。遗憾的是，前三级权限在增强团队信心，活跃开发氛围，提高敏捷性方面作用有限。

在设计架构的同时提高团队能力是架构师面临的最大挑战之一。也许你觉得这样做还不如自己设计架构来得轻松。从短期来看，这样想有道理。但从长远看，这会造成团队成员无法成长。如果团队里只有你一个人能设计架构，那么你的知识、能力、精力将会成为整个因队的瓶颈

如果你仍有疑虑，可以先保留设计权限，等到合适的时机再下放权限。

ThoughtWorks 首席技术顾问 Patrick Kua 认为：架构师身上的担子很重．他要降低技术风险，要设法应对未来的变化，还要确保提升既定的系统质量属性。仅仅做到这些还不够，他还必须像一位技术主管那样思考和工作。

优秀的架构师不能只靠自己做決第。技术发展日新月异，架构师不可能热悉所有的工具和技术细节，所以他应该善于利用团队的智慧和经验。作为技术主管的架构师要为团队树立技术愿景，提高团队的开发效率和团队成员的能力。

如果用团队的决策质量衡量架构师的工作成果，那么架构师也应当致力于帮助开发人员做出更好的决策。毕竟，每一行代码都代表一种选择，而每一种选择都是一个决策。架构师可以通过指明约束条件或者与团队共同确定架构原则来提高开发人员的决策质量。

无论是树立技术愿景、指明约束，还是共同确定架构原则，都需要架构师具备一种非技术能力。这种能力常被称为软技能（soft skill）。它往往是最难学到的。成为出色的架构师，你必须掌握一些沟通技巧，比如用非技术性术语解释技术理念、借助图表和模型建立共识、用故事
激励团队成员，等等。此外，还要学会倾听同事的意见和观点。倾听不但能增加你的知识储备，还能提高对方对技术愿景的认同感。

一类架构师，他们独来独往，只想研究专业技术，不布望别人干涉自己的架构设计——这些人应该回到象牙塔里去，如果你不想成为这样的架构师，就必须提升自己的技术管理能力，加强自己与团队的合作与联系。

13.4.2 何时下放设计权限

如果团队具备了一定的经验，那么可以找机会咨询大家的意见，一起制定决策，或者干脆让团队作决策（你只分享建议）。对那些与团队日常工作息息相关或存在争议的设计决策而言，下放设计权限尤为重要。

随着团队逐渐加深对架构的理解，你管理团队的信心也会与日俱增。这时就可以开展设计研讨会了。你可以在后四级权限里挑选你认为最合适的方式来开展研讨会。把更多的设计权限下放给团队，你将逐渐从架构的设计者变成架构设计的促进者。

第三部分介绍的许多方法都可以用来让团队参与设计，这里举几个例子：

• 向团队讲述架构故事，鼓励团队成员一起讲述与架构有关的故事 （见第 15.1节和第 16.10节）。
• 开展研讨会，鼓励团队成员参与架构设计（见第9章、第17.5节、第 17.6节、第17.8节)
• 检查团队的参与程度，了解进展（见第17.1节、第17.7节）。
• 如果有好的案例，可以把制作文档的任务下放给团队。可以委托团队制作与评审的文档包括架构决策记录（见第 16.1 节）、架构主旨（见第16.2节）、启动计划书 （见第 16.5节)

13.5 共同设计架构

第 1.4 节曾提到出色的软件架构可以提高团队开发能力。请注意，提高团队开发能力的是架构，而不是架构师。架构师的责任是指导团队设计出色的架构，让大家从中获益。第 1.1节曾介绍架构师要做什么，就是告诉大家如何完成这项任务。本书前两部分都在围绕这个主题进行阐述。

现在，让我们结合新学的知识，重新回顾架构师的主要职责：

• 从工程角度定义问题。架构师要负责定义关键架构需求，特别是质量属性。我建议采用以人为本的设计方法收集需求，避免与利益相关方的真实需求脱节。
• 分解系统，分配职责。架构师要引导团队识别有利于提升既定质量属性的模式。我建议只做够用的架构设计，确保实现关键的质量属性，而把其他决策留给后续设计人员。
• 关注大局，保证全局设计的一致性。架构师要从全局的角度把握架构设计，同时带领团队完成系统开发。我建议建立精确的架构模型（记录架构决策），同时使用简单的文档。架构模型可以用来推演系统、评估决策、识别风险，帮助我们实现业务目标。
• 在质量属性之问做出取舍。放弃一些东西换取其他东西在软件开发中很常见。架构师要找出备选方案，与各方一起协商如何取舍最合理。我建议借助风险决定设计决策和内容。
• 管理技术债务。架构师要识别技术债务，制定偿还策路。我建议将技术债务看成软件系统不可避免的副产品，需要在整个系统生命周期中有策略地加以管理。
• 提升团队的架构技能。架构师要提高团队的架构设计能力（包括理解、探索、展示、评估架构的能力），让大家对系统形成共同的责任感。我建议与团队一起设计架构，而不是为团队设计架构。

对大多数团队而言，编程是相对容易的任务，最困难的是理解问题并从系统的角度解决问题。团队对架构的理解越深刻，就越容易解决开发中遇到的问题。与团队一起设计架构能够加深这种理解

结束语

架构师是技术领导者，但不应该自己设计架构的所有细节。架构师应该带领团队一起成长，为大家创造实践机会，提高团队的架构技能，通过与大家合作来影响架构设计。要知道团队成长的重要性并不亚于做出正确的设计决策。

本书前两部分介绍了软件架构设计的核心原则与方法。掌握这些内容，可以成为一名合格的架构师。但是，如果我希望成为一名出色的架构师，只满足于这些知识是远远不够的。我还需要不断深入学习与这些原则、方法有关的内容。要一直保持探索、学习的好习惯。

接下来，我是尝试将从本书中学到的知识运用到我的项目中去。帮助自己和团队一起成长。