除了创建技术架构和做出架构决策外，软件架构师还负责在架构的实现过程中指导开发团队。优秀的软件架构师能够创建高效的开发团队，这些团队紧密合作来解决问题并产出成功的解决方案。虽然这听起来很容易理解，但我们已经见过太多架构师忽视开发团队，在孤立的环境中工作来创建架构。然后，这个架构被移交给开发团队，然后开发团队在如何正确地实现架构中挣扎。能够使团队高效是有效率的和成功的软件架构师区别于其他软件架构师的方法之一。在本章中，我们将介绍架构师可以利用的一些基本技术，以使开发团队更高效。
团队边界
根据我们的经验，软件架构师可以极大地影响开发团队的成败。感觉被排除在圈子之外或与软件架构师（以及架构）疏远的团队通常没有得到适当级别的指导和关于系统上各种约束的恰如其分的知识，因此不能正确地实现架构。
软件架构师的角色之一是创建和沟通约束，即开发人员可以在其中实现架构的框框。架构师可以创建过度严紧、过度宽松或恰到好处的边界。这些边界如图22-1所示。过紧或过松的边界会直接影响到团队成功实现架构的能力。
创建过多约束的架构师在开发团队周围形成一个严紧的盒子，从而阻止对许多有效实现系统所必需的工具、库和实践的访问。这会导致团队内部的挫败感，通常会导致开发人员离开项目去寻找更快乐、更健康的环境。
相反的情况也可能发生。软件架构师可以创建过于宽松的约束（或者根本没有约束），将所有重要的架构决策留给开发团队。在这种与严密约束同样糟糕的场景中，团队本质上扮演着软件架构师的角色，在没有适当级别的指导的情况下执行概念验证并为设计决策进行斗争，从而导致低效、混乱和挫败。
一个有效的软件架构师努力提供正确级别的指导和约束，以便团队拥有正确的工具和库来有效地实现架构。
架构师个性
有三种基本类型的架构师个性：控制狂架构师（图22-2）、扶手椅架构师（图22-3）和高效的架构师（图22-5）。每一种个性都与上一节关于团队边界的讨论中所讨论的特定边界类型相匹配：控制狂的架构师会建立紧密的边界，扶手椅架构师会建立松散的边界，而高效的架构师会建立恰到好处的边界。
控制狂
控制狂架构师试图控制软件开发过程的每一个细节。一个控制狂架构师所做的每一个决定通常都过于细粒度和低级，导致开发团队受到太多的约束。
控制狂架构师产生了上一节讨论的严密边界。一个控制狂架构师可能会限制开发团队下载任何有用的开源或第三方库，而是坚持让开发团队使用语言API从头开始编写所有东西。控制狂架构师还可能对命名约定、类设计、方法长度等进行严格约束。他们甚至可能会为开发团队编写伪代码。从本质上说，控制狂架构师从开发人员那里窃取编程的艺术，从而导致团队沮丧情绪产生和对架构师缺乏尊重。
成为一个控制狂架构师是非常容易的，特别是当从开发人员过渡到架构师时。架构师的角色是创建应用的构建块（组件）并确定这些组件之间的交互。开发人员在这项工作中的角色是获取这些组件，并确定如何使用类图和设计模式实现它们。然而，在从开发人员到架构师的转变中，他们还是会希望去创建类图和设计模式，因为这是新上任的架构师先前的角色。
例如，假设架构师创建一个组件（架构的构建块）来管理系统中的引用数据。引用数据包括网站上使用的静态名称-值对数据，以及产品代码和仓库代码（整个系统中使用的静态数据）等内容。架构师的角色是识别组件（在本例中是引用管理器），确定该组件的核心操作集（例如GetData、SetData、ReloadCache、NotifyOnUpdate等等），以及哪些组件需要与引用管理器交互。控制狂架构师可能会认为实现这个组件的最佳方式是通过一个并行加载程序模式来实现，该模式利用一个内部缓存，并为该缓存提供一个特定的数据结构。虽然这可能是一个有效的设计，但它不是唯一的设计。更重要的是，提出引用管理器的内部设计不再是架构师的角色，而是开发人员的角色。
我们将在“多大的控制？中讨论，有时架构师需要扮演控制狂的角色，这取决于项目的复杂性和团队的技能水平。然而，在大多数情况下，控制狂架构师扰乱了开发团队，没有提供正确级别的指导，妨碍了开发，并且在通过架构的实现来领导团队方面没有效率。
扶手椅架构师
扶手椅架构师是那种在很长一段时间内（如果有的话）都没有编写过代码的架构师，在创建架构时也没有考虑到实现细节。他们通常与开发团队隔绝开来，从不四处走动，或者在初始架构图完成后从一个项目转移到另一个项目。
在某些情况下，扶手椅架构师确实是在技术或业务领域方面超出了他们的能力，因此不可能从技术或业务问题的角度来领导或指导团队。例如，开发人员做什么？当然，他们是编码的。编写程序代码真的很难伪造；要么一个开发人员编写了软件代码，要么没有编写。然而，架构师是做什么的？没人知道！大多数架构师都会画很多线和框，但是架构师应该在这些图中描述得有多详细呢？这里有一个关于架构的肮脏的小秘密，很容易伪装成一个架构师！
假设一个扶手椅架构师在某些方面超出了他们的能力，或者没有时间为股票交易系统设计一个合适的解决方案。在这种情况下，架构图可能类似于图22-4所示。这种架构没有什么问题，只是层次太高以至于对任何人都没有任何用处。
扶手椅架构师在开发团队周围创建松散的边界，如前一节所讨论的。在这个场景中，开发团队最终扮演架构师的角色，基本上完成架构师应该做的工作。团队的速度和生产力因此受到影响，团队对系统应该如何工作感到困惑。
就像控制狂架构师一样，成为一个扶手椅建筑师太容易了。一个架构师可能会成为一个扶手椅架构师的最大迹象是没有足够的时间与实现该架构的开发团队在一起（或者选择不与开发团队在一起）。开发团队需要架构师的支持和指导，他们需要架构师在技术或业务相关的问题出现时回答这些问题。扶手椅架构师的其他标志如下：
- 不完全了解业务领域、业务问题或使用的技术
- 没有足够的软件开发的实践经验
- 不考虑与架构解决方案的实现相关的影响
在某些情况下，架构师并没有打算成为一个扶手椅架构师，而是通过在项目或开发团队之间延展得过于浅薄、与技术或业务领域缺乏接触而“发生”的。架构师可以通过更多地参与项目中使用的技术并理解业务问题和业务领域来避免这种个性。
高效的架构师
一个高效的软件架构师会在团队中建立适当的约束和边界，确保团队成员能够很好地协同工作，并对团队有正确的指导。高效的架构师还确保团队拥有正确和适当的工具和技术。此外，他们还消除了阻碍开发团队实现目标的所有障碍。
虽然这听起来很显然也很容易，但事实并非如此。在开发团队中成为高效的领导者是一门艺术。成为一名高效的软件架构师需要与团队紧密合作，并获得团队的尊重。在本书的后面几章中，我们将探讨成为一名高效的软件架构师的其他方法。但是现在，我们将介绍一些指导方针来了解一个高效的架构师应该对开发团队施加多大的控制。
多大的控制？
成为一个高效的软件架构师需要知道对一个给定的开发团队施加多大的控制。这一概念被称为弹性领导，并被作家兼顾问Roy Osherove广为宣扬。我们将稍微偏离Osherove在这一领域所做的工作，并关注软件架构的特定因素。了解一个高效的软件架构师在多大程度上应该是一个控制狂还是一个扶手椅架构师，主要涉及五个因素。这些因素还决定了一个软件架构师可以同时管理多少个团队（或项目）：
团队熟悉度
团队成员相互了解程度如何？他们以前合作过一个项目吗？一般来说，团队成员相互了解得越好，就越不需要控制，因为团队成员开始变得自组织。相反，团队成员越新，就越需要控制来促进团队成员之间的协作，减少团队内部的派系。
团队规模
团队有多大？（我们认为同一个团队中有12个以上的开发人员是一个大团队，4个或更少的开发人员是一个小团队。）团队越大，就越需要控制。团队越小，需要的控制就越少。这将在“团队告警标志”中详细讨论。
总体经验
有多少团队成员是资深的？有多少是初级的？它是由初级和高级开发人员组成的混合团队吗？他们对技术和商业领域了解多少？拥有大量初级开发人员的团队需要更多的控制和指导，而拥有更多高级开发人员的团队需要更少的控制。在后一种情况下，架构师从导师的角色转变为协调者的角色。
项目复杂度
这个项目是非常复杂还是只是一个简单的网站？高度复杂的项目需要架构师花更多的时间在团队上，并协助解决出现的问题，因此需要对团队进行更多的控制。相对简单的项目很直接，因此不需要太多的控制。
项目工期
项目是短期（两个月）、长期（两年）还是平均工期（六个月）？工期越短，需要的控制就越少；反之，项目越长，需要的控制就越多。
虽然大多数因素在多或少的控制方面是有意义的，但项目工期因素似乎没有意义。如前表所示，项目持续时间越短，需要的控制就越少；项目持续时间越长，就越需要控制。直觉上，这似乎是相反的，但事实并非如此。考虑一个两个月的快速项目。两个月的时间对于确认需求、实验、开发代码、测试每个场景以及发布到生产环境中来说并不多。在这种情况下，架构师应该更像一个扶手椅架构师，因为开发团队已经有了强烈的紧迫感。一个控制狂架构师可能会妨碍项目的进行，并可能会使项目延误。相反，设想一个为期两年的项目。在这种情况下，开发人员很放松，不考虑紧迫性，可能会计划休假和花很长时间来吃午餐。架构师需要更多的控制，以确保项目能够及时进行，并首先完成复杂的任务。
在大多数项目中，通常利用这些因素来确定项目开始时的控制水平；但随着系统的不断发展，控制水平也在不断变化。因此，我们建议在项目的整个生命周期中不断分析这些因素，以确定对开发团队施加多少控制。
为了说明如何使用每一个因素来确定架构师在团队中应该施加的控制级别，假设每个因素的固定比例为20分。分值减少更偏向成为扶手椅架构师（较少控制和参与），而分值增加则更偏向成为控制狂架构师（更多的控制和参与）。该级别说明如图22-6所示。
当然，应用这种级别并不准确，但它确实有助于确定对团队施加的相应控制。例如，考虑表22-1和图22-7中所示的项目场景。如表所示，这些因素指向控制狂（+20）或扶手椅架构师（-20）。这些因素加起来累积得分为-60，这表明架构师应该扮演更多的扶手椅架构师的角色，而不是妨碍团队的发展。
在场景1中，所有这些因素都被考虑在内，以证明一个高效的软件架构师最初应该扮演协调者的角色，而不是过多地参与与团队的日常交互。架构师需要回答问题并确保团队走上正轨，但在大多数情况下架构师都应该放手，让经验丰富的团队做他们最了解的事情：快速开发软件。
考虑表22-2中描述的另一种场景，如图22-8所示，其中团队成员彼此熟悉，但团队很大（12个团队成员），并且大部分由初级（无经验）开发人员组成。这个项目比较复杂并历时六个月。在这种情况下，累计得分为+20，这表明高效的架构师应该参与团队内的日常活动，并承担指导和指导角色，但不至于扰乱团队。
很难将这些因素具体客观化，因为其中一些因素（比如整个团队的经验）可能比其他因素更重要。在这些情况下，可以很容易地对指标进行加权或修改，以适应任何特定的场景或条件。不管怎样，这里要表达的主要信息是，软件架构师对团队的控制和参与程度因这五个主要因素而不同，并且通过考虑这些因素，架构师可以判断对团队施加何种控制，以及开发团队可以在其中工作的范围应该是什么样的（严密或松散的边界和约束）。
团队告警标志
如前一节所述，团队规模是影响架构师应该对开发团队施加的控制量的因素之一。团队越大，就越需要控制；团队越小，就越不需要控制。在考虑最有效的开发团队规模时，有三个因素起作用：
- 过程损失
-多元无知
- 责任分散
过程损失，也被称为布鲁克定律，最初是由弗雷德.布鲁克斯在他的书《神话人月》中创造的（Addison-Wesley）。过程损失的基本思想是，您添加到项目中的人员越多，项目所需的时间就越多。如图22-9所示，组织潜力由团队中每个人的集体努力来定义。然而，对于任何一个团队来说，实际生产力总是低于团队潜力，不同的是团队的过程损失。
一个高效的软件架构师将观察开发团队并探索过程损失。过程损失是确定特定项目或工作的合适团队规模的一个好因素。过程损失的一个指标是，在将代码推送到存储库时，经常发生合并冲突。这表明团队成员可能在互相踩踏，在相同的代码上工作。在团队中寻找并行区域并让团队成员处理应用的不同服务或区域是避免过程损失的一种方法。每当一个新的团队成员加入到一个项目中，如果没有创建并行工作流的区域，一个高效的架构师就会质疑为什么一个新的团队成员被添加到团队中，并向项目经理展示这个额外的人将对团队产生的负面影响。
当团队规模过大时，多元无知也会发生。多元无知是指每个人都同意（但私下里反对）一个规范，因为他们认为自己遗漏了一些明显的东西。例如，假设在一个大型团队中，大多数人都同意在两个远程服务之间使用消息传递是最好的解决方案。然而，团队中的一个人认为这是一个愚蠢的想法，因为两个服务之间有一个安全的防火墙。然而，这个人并没有说出来，而是同意使用消息传递（但私下里反对这个想法），因为他们担心自己遗漏了一些明显的东西，或者担心如果他们说出来，可能会被视为傻瓜。在这种情况下，拒绝规范的人是正确的，消息传递将不起作用，因为两个远程服务之间有一个安全的防火墙。如果他们大声说出来（并且团队规模小一些），原始的解决方案将受到挑战，而使用另一个协议（比如REST），在这种情况下，这将是一个更好的解决方案。
多元无知的概念因安徒生的丹麦童话故事《皇帝的新衣》而闻名。在故事中，国王确信他的新衣服对任何不配去看到的人都是看不见的。他全裸着大摇大摆地走来走去，问所有的人他们喜欢他的新衣服吗。所有的臣民，害怕被认为是愚蠢或不配，而回应国王他的新衣服是最好的东西。这种愚蠢的行为一直持续到一个孩子最终向国王喊道他根本没穿衣服。
一个高效的软件架构师应该在任何形式的协作会议或讨论中持续观察面部表情和肢体语言，如果他们感觉到多元无知的发生，应该充当协调者的角色。在这种情况下，高效的架构师可能会打断并询问该人员他们对所提议的解决方案的看法，并且在他们发言时站在他们一边并支持他们。
第三个表明适当团队规模的因素称为责任分散。责任分散是基于这样一个事实：随着团队规模的增加，它会对沟通产生负面影响。搞不清谁应该为团队中的哪些事情负责，以及事情被落下都是符合团队规模过大的迹象。
请看图22-10中的图片。你观察到了什么？
这张照片显示有人站在一个小乡村路边一辆坏了的汽车旁边。在这种情况下，有多少人会停下来问司机一切是否正常？因为这是一个大概每个人都会路过的小社区里的一条小道。然而，有多少次驾车者被困在一个大城市中心繁忙的高速公路边上，数千辆汽车只是开过去，没有人停下来问是否一切正常？一直都是这样。这是责任分散的一个很好的例子。随着城市变得越来越繁忙和拥挤，由于大量的人目睹了这一事件，人们认为司机已经打电话或救援已经在路上。然而，在大多数情况下，救援不在路上，司机被一部坏的或被遗忘的手机卡住，无法呼叫救援。
一个高效的架构师不仅有助于指导开发团队完成体系结构的实现，而且还可以确保团队健康、快乐，并共同努力实现一个共同的目标。探索这三个告警标志并帮助纠正它们有助于确保开发团队的高效性。
利用检查表
航空公司的飞行员在每一次飞行中都使用检查表，即使是最有经验的资深飞行员。飞行员有起飞、着陆和其他数千种情况的检查表，包括常见和不常见的情况。他们使用检查表是因为一次错失的飞机设置（如将襟翼设置为10度）或程序（如获得进入终端控制区的许可）可能意味着安全飞行和灾难之间的区别。
Atul Gawande博士写过一本名为《检查清单宣言》（Picador）的优秀的书，他在书中描述了检查清单在外科手术中的作用。Gawande博士对医院中葡萄球菌感染率之高表示震惊，于是制定了手术检查表来试图降低这种比率。在这本书中，他证明了使用检查表的医院的葡萄球菌感染率下降到接近零，而没有使用检查表的对照医院的葡萄球菌感染率继续上升。
检查表起作用。他们提供了一个很好的工具，确保一切都涵盖和得到处理。如果检查表这么好，那么为什么软件开发行业不利用它们呢？通过个人经验，我们坚信检查表对开发团队的效率有很大的影响。然而，对于这一说法有一些警告。首先，大多数软件开发人员不会驾驶客机或进行心脏手术。换距话说，软件开发人员不需要所有事情都有检查表。使团队高效的关键是知道何时使用检查表，何时不使用。
考虑图22-11所示的创建一个新的数据库表的检查表。
这不是一个检查表，而是一套程序步骤，因此不应包含在检查表中。例如，如果表单尚未提交，则无法对数据库表进行验证！任何包含依赖性任务过程的流程都不应该包含在检查表中。简单的、众所周知的、经常执行且不会出错的流程也不需要检查表。
可以很好地利用检查表的流程是那些没有任何程序顺序或依赖任务的流程，以及那些容易出错或经常遗漏或跳过步骤的流程。使检查表有效的关键是不要把所有的事情都列到检查表上。架构师发现，事实上，检查表确实使开发团队更加高效，因此开始将所有内容都作为检查表，引发所谓的收益递减规律。架构师创建的检查表越多，开发人员使用它们的机会就越小。创建检查表的另一个关键成功因素是使其尽可能小，同时仍然捕获流程中所有必要的步骤。开发人员通常不会遵循太大的检查表。寻找可以通过自动化执行的项目，并将其从检查表中删除。
提示
不要担心在检查表中声明显而易见的事情。显而易见的东西通常会被遗漏或错过。
我们发现最有效的三个关键检查表是开发人员代码完成检查表、单元和功能测试检查表以及软件发布检查表。以下各节将讨论每个检查表。
霍桑效应
向开发团队引入检查表的一个问题是让开发人员实际使用它们。对于一些开发人员来说，在没有实际执行任务的情况下，将特定检查表中的所有项目都标记为已完成是很常见的。
解决这个问题的方法之一是与团队讨论使用检查表的重要性以及检查表如何在团队中发挥作用。让团队成员阅读Atul Gawande的检查表宣言，以充分理解检查表的力量，并确保每个团队成员理解每个检查表背后的理由以及为什么使用它。让开发人员在检查表上应该和不应该列出的内容上进行协作也会有所帮助。
当所有其他方法都失败时，架构师可以援引所谓的霍桑效应。霍桑效应本质上意味着，如果人们知道他们被观察或监视，他们的行为就会改变，通常他们会做正确的事情。例如，建筑物内和周围的高可视摄像头实际上不起作用，或者没有真正记录任何东西（这是非常常见的！）以及网站监控软件（实际有多少报告会被真正查看？）。
霍桑效应也可以用来监管检查表的使用。架构师可以让团队知道检查表的使用对团队的效率至关重要，因此，所有检查表都将得到验证，以确保实际执行了任务，而实际上架构师只是偶尔抽查检查表的正确性。通过利用霍桑效应，开发人员将不太可能跳过项目或将其标记为已完成，而实际上任务并未完成。
开发人员代码完成检查表
开发人员代码完成检查表是一个有效的工具，尤其是当软件开发人员声明他们已经“完成”了代码时。它对于定义所谓的“完成的定义”也很有用。如果检查表中的所有内容都完成了，那么开发人员就可以声称他们已经完成了代码。
以下是开发人员代码完成检查表中要包含的一些内容：
- 自动化工具中不包括的编码和格式标准
- 经常被忽略的项目（如吸收的异常）
- 项目特定标准
- 特别小组指示或程序
图22-12展示了一个开发人员代码完成检查表的例子。
注意检查表中明显的任务“运行代码清理和代码格式化”和“确保没有异常”。有多少次开发人员匆忙在一天结束或一次迭代结束时，忘记从IDE运行代码清理和格式化？无数次。在检查表宣言中，Gawande发现了与外科手术相同的现象——明显的往往是经常被忽略的。
同时注意条目2、3、6和7中的项目特定任务。虽然这些都是检查表中的好条目，但架构师应该经常检查清单，看看是否有任何条目可以自动化或作为代码验证检查器的插件来编写。例如，虽然“Include@ServiceEntrypoint on service API class”可能无法进行自动检查，但“Verify that only public methods are calling setFailure（）”肯定可以（这是一种使用任何类型的代码爬虫工具的直接自动检查）。检查自动化区域有助于减少检查表中的规模和噪音，使其更有效。
单元和功能测试检查表
也许最有效的检查表之一是单元和功能测试检查表。这个检查表包含了一些软件开发人员往往会忘记测试的不寻常的和边缘的案例测试。每当QA人员发现基于特定测试用例的代码有问题时，应该将该测试用例添加到此检查表中。
由于可以针对代码运行的所有类型的测试，这个特定的检查表通常是最大的检查表之一。这个检查表的目的是确保尽可能覆盖全部的代码，这样当开发人员完成检查表时，代码就基本上可以准备部署生产环境了。
以下是典型单元和功能测试检查表中的一些条目：
- 文本和数字字段中的特殊字符
- 最小值和最大值范围
- 异常和极端测试用例
- 缺少字段
与开发人员代码完成检查表一样，任何可以作为自动测试编写的项目都应该从检查表中删除。例如，假设股票交易应用程序的检查表中有一个项目用于测试负股票数（例如买-1000股苹果[AAPL]）。如果此检查可以通过测试套件中的单元或功能测试自动进行的，则应从检查表中删除该项。
开发人员有时不知道在编写单元测试时从哪里开始，也不知道要编写多少个单元测试。此检查表提供了一种方法，确保在软件开发过程中包含了一般或特定的测试场景。在由不同团队执行这些活动的环境中，此检查表还可以有效地弥合开发人员和测试人员之间的间隙。开发团队执行完整测试的次数越多，测试团队的工作就越容易，从而使测试团队能够专注于检查表中未涵盖的某些业务场景。
软件发布检查表
将软件发布到生产环境中可能是软件开发生命周期中最容易出错的地方之一，因此可以形成一个很好的检查表。此检查表有助于避免失败的构建和失败的部署，并显著降低与发布软件相关的风险。
软件发布检查表通常是检查表中最不稳定的，因为每次部署失败或出现问题时，它都会不断更改以解决新的错误和情况。
以下是软件发布检查表中通常包含的一些项目：
- 服务器或外部配置服务器中的配置更改
- 添加到项目中的第三方库（JAR、DLL等）
- 数据库更新和相应的数据库迁移脚本
每当构建或部署失败时，架构师应该分析失败的根本原因，并在软件发布检查表中添加相应的条目。这样，该条目将在下一个构建或部署中得到验证，从而防止该问题再次发生。
提供指导
软件架构师还可以通过使用设计原则来提供指导，从而提高团队的效率。这也有助于形成边界（约束），如本章第一节所述，开发人员可以用来实现架构。有效地传达这些设计原则是创建成功团队的关键之一。
为了说明这一点，请考虑向开发团队提供有关使用通常称为分层堆栈（即构成应用的第三方库（如JAR文件和dll）集合）的指导。开发团队通常有很多关于分层堆栈的问题，包括他们是否可以自己决定使用各种库（哪些可以，哪些不可以）。
使用此示例，一个高效的软件架构师可以通过首先让开发人员回答以下问题来为开发团队提供指导：
1、建议的库和系统内现有功能之间是否有重叠？
2、使用建议的库的理由是什么？
第一个问题引导开发人员查看现有库，看看新库提供的功能是否可以通过现有库或现有功能得到满足。根据我们的经验，开发人员有时会忽略此活动，从而创建大量重复的功能，特别是在大型团队的大型项目中。
第二个问题促使开发人员质疑为什么新的库或功能是真正需要的。在这里，一个高效的软件架构师会询问一个技术理由和一个商业理由来说明为什么需要额外的库。这是一种很有效的技巧，可以让开发团队意识到业务合理性的需要。
商业理由的影响
您的一位作者（Mark）是一个非常复杂的基于Java的项目的首席架构师，拥有一个大型开发团队。其中一个团队成员对Scala编程语言特别着迷，非常想在项目中使用它。这种使用Scala的愿望最终变得如此具有破坏性，以至于几个关键的团队成员通知Mark，他们正计划离开项目，转向其他“低毒”的环境。马克说服了两个关键的团队成员推迟他们的决定，并与Scala爱好者进行了讨论。Mark告诉Scala爱好者，他将支持在项目中使用Scala，但是Scala爱好者必须提供使用Scala的商业理由，因为这涉及到培训成本和重写工作。Scala的狂热者欣喜若狂，说他会马上开始，他离开会场时大喊：“谢谢你，你是最棒的！”
第二天，Scala爱好者走进办公室，态度完全变了样。他立刻走近马克，要求和他谈谈。他们都走进了会议室，Scala的狂热者立刻（谦卑地）说：“谢谢。” Scala爱好者向Mark解释说，他可以想出世界上所有使用Scala的技术理由，但这些技术优势在所需的架构特征（“ilities”）：成本、预算和时间方面都没有任何商业价值。事实上，Scala爱好者意识到成本、预算和时间的增加不会带来任何好处。
意识到自己之前制造了混乱，这位Scala爱好者很快就把自己变成了团队中最优秀、最有帮助的成员之一，这一切都是因为他被要求为自己想要的项目提供一个商业理由。这种对正当性认识的提高不仅使他成为一个更好的软件开发人员，而且形成一个更强大、更健康的团队。
作为后记，两位关键的开发人员一直坚持到项目的最后。
继续以管理分层堆栈为例，传达设计原则的另一种有效技术是通过图形化的解释，说明开发团队可以对什么或不能对什么做决定。图22-13中的图示是控制分层堆栈的图形（以及指南）的示例。
在图22-13中，架构师将提供每一类第三方库的内容以及指导（设计原则）的示例，说明开发人员能和不能做什么（本章第一节中描述的方框）。
例如，以下是为任何第三方库定义的三个类别：
特殊用途
这些是用于类似PDF呈现、条形码扫描和不需要编写自定义软件的情况的特定库。
一般用途
这些库是开发语言API之上的包装器，它们包括像Apache Commons和Guava for Java等内容。
框架
这些库用于持久化（如Hibernate）和控制反转（如Spring）。换句话说，这些库构成了应用程序的整个层或结构，具有很强的侵入性。
一旦分类好了之后（前面的分类只是一个例子，可以有更多的定义），架构师便围绕这个设计原则创建一个边界。请注意，在图22-13所示的示例中，对于这个特定的应用或项目，架构师已经指定对于特殊用途的库，开发人员可以做决定而无需咨询架构师。但是请注意，对于一般用途，架构师已经指出，开发人员可以进行重叠分析和论证以提出建议，但使用该类库需要架构师的批准。最后，对于框架库，这是架构师的决定。换句话说，开发团队甚至不应该对这些类型的库进行分析；架构师已经决定对这些类型的库承担责任。
总结
使开发团队高效是一项艰巨的工作。它需要大量的经验和实践，以及强大的人际交往能力（我们将在本书后续章节中讨论）。也就是说，本章中描述的关于弹性领导、利用检查表和通过有效沟通设计原则提供指导的简单技术实际上是有效的，并且已经证明能够有效地使开发团队更聪明、更有效地工作。
有人可能会质疑架构师在此类活动中的角色，而不是将使团队高效的工作分配给开发经理或项目经理。我们强烈反对这个前提。软件架构师不仅为团队提供技术指导，还领导团队完成架构的实现。软件架构师和开发团队之间的密切协作关系允许架构师观察团队动态，从而促进使团队更有效的转变。这正是技术架构师与高效软件架构师的区别所在。
