28.结语

28 Epilogue 结语

Don’t let it end like this. Tell them I said something.
不要让它就这样结束。 告诉他们我说了些什么

—Pancho Villa

您已到达旅程的尽头。 辛苦了

我们希望您能从本书中找到一些有价值的收获。 我们建议该列表应包括以下内容：

1. 什么是架构，为什么重要，什么影响以及什么影响。
2. 架构在业务，技术，项目和专业环境中扮演的角色。
3. 架构和质量属性之间的至关重要的共生关系，如何指定质量属性要求，以及您快速沉浸在十几种最重要的质量保证中。
4. 如何捕获对体系结构的架构上重要的要求。
5. 如何设计架构，对其进行记录，指导其实施，对其进行评估，以查看其是否适合您的需求，对其进行反向工程以及围绕该项目进行管理。
6. 如何评估架构的成本和收益，在架构上胜任意味着什么，以及如何将架构用作整个软件产品线的基础。
7. 当前技术前沿上的系统的架构概念和模式：边缘应用程序和云。

好。 怎么办？

用一本令人振奋的命令来结束本书并设计出色的系统是非常诱人的。 但事实是，生活并非如此简单。

本书的作者共同在软件架构教学方面拥有大量令人尴尬的多年经验。 我们在教室里为学生提供此类书籍，从工业短期课程到从“有抱负”到“老手”的各行各业的软件架构师，我们都通过这种方式教书。而且，我们经常知道， 学生会认真学习我们所提供的知识，他们走进的组织在架构上不像现在的学生那么精明，而且我们的学生没有实践的方法将所学知识付诸实践。

如果您尚不存在，大多数人将无法为要分配给您的项目指定基于架构的哲学。 您将无法说“这个敏捷项目需要首席软件架构师！”，如果团队负责人认为敏捷方法不允许任何总体设计，那么它就会坚持下去。 您将不会说：“我们将在项目进度表中包括明确的架构评估”，并且每个人都遵守。 您将不会说：“我们将使用Views and Beyond方法和模板作为我们的体系结构文档”，并遵守您的指示。

为了避免您将所有时间都花在吸收本书上的时间上是浪费在迷茫的事业上，我们希望在本书结尾时提供一些建议，以将您所学的知识带入专业领域：

1. 说正确的语言。 您现在知道架构是达到目的的手段，而不是目的本身。 您组织中的决策者通常关心目标，而不是手段。 他们关心的是产品，而不是那些产品的架构。 他们关心确保产品在市场上具有竞争力。 并且他们关心执行组织的营销和业务策略。 他们可能不会以结构上重要的术语来表达他们的担忧，而是以您必须翻译的市场术语来表达。
2. 说正确的语言，第2部分。项目经理关心降低技术风险，可靠和切合实际的日程安排和预算，以及计划这些产品的生产。 在某种程度上，您可以证明专注于这些架构是合理的，那么您更有可能成功地获得执行本书中所倡导的一些实践的自由。 您确实可以证明这一关注点是正确的：健全的架构是无与伦比的降低风险策略，可靠的工作估算器和生产方法的良好预测器。
3. 参与进来。将架构问题插入项目的最好方法之一是向没有机会看到它的利益相关者展示其价值。需求工程师就是一个很好的例子。通常，他们会与客户和用户会面，捕捉他们的疑虑，将其写下来，然后将要求从围栏（通常是很高的围栏）上扔给设计师。挑战这种种族隔离！尝试参与需求捕获活动。邀请自己参加会议。假设作为架构师，您想通过直接从马口中听到问题来理解问题。这将使您与需要帮助设计，评估和处理文档的非常重要的利益相关者接触。此外，这将使您有机会为需求捕获过程增加价值。因为您可能会考虑一种设计方法，所以您可能会提供比客户所想的更好的质量属性响应，这可能会使我们的营销人员感到非常满意。或者，您也许能够及早发现麻烦的需求，并帮助推动客户做出完全适当但在架构上更可口的质量检查响应。另外，您可以自己联系组织的营销人员。他们通常是提出产品概念的人。您最好了解他们如何做到这一点，最终您可以指出可能使用相同架构的现有产品的有用变化，从而为他们提供帮助。
4. 这是经济，愚蠢的。思考并以经济术语表达您的观点。如果您认为架构贸易研究，架构文档或架构评估，或确保代码与架构相符是您的项目的好主意，请为其提出业务案例。尽管有漫画中尖尖的老板，但经理们确实是（在这里相信我们）理性的人。但是他们的目标很广泛，几乎总是与经济学有关。您应该能够辩解道理，例如，当系统进行重大更改时，生成架构文档的更新版本是值得的（例如）。您应该能够辩称，与没有指导性架构的情况下进行的那些相同活动相比，使用新架构文档进行的活动将更少出错（因此成本更低）。保持文档更新的工作量远远少于预期的节省量。您可以在电子表格中插入一些数字作为此参数。这些数字不一定是准确的，只是合理的，它们仍然可以证明您的情况。
5. 开始游击运动。在您的组织中找到志趣相投的人，并培养他们对架构的兴趣。开始一个自带的午餐时间阅读和讨论小组，讨论小组讨论书籍，书籍章节或论文，甚至有关架构的博客。例如，您的小组可以阅读本书中有关架构能力的一章，并讨论您希望组织采用哪些实践以及采用这些实践需要采取什么措施。或者，小组可以就架构的联合文档模板达成一致，或者提出适用于您的集体项目的一组质量属性方案。尤其吸引人的是提出一套适用于您正在构建的系统的模式。或从您的单个项目中提出一个令人烦恼的设计问题，然后让小组为之编写书面解决方案。或者让该小组作为其他项目的巡回架构评估团队提供服务。您的小组应定期定期召开会议，并采取一系列具体的具体目标。热心且敬业的领导者（您呢？）的重要性是谁，他们渴望成熟于组织的架构实践，所以不要夸大其词。宣传您的会议，宣传您的结果，并不断要求更多成员加入您的论坛。
6. 享受小胜利。您不必一夜之间改变世界。您所做的每一项改进都会使您和您的组织处在比以前更好的地方。

通过后门将架构审查纳入组织

如果您在网络上搜索“代码审查计算机科学”，则会发现数百万次匹配，它们描述了代码审查以及执行代码审查的步骤。 如果您搜索“设计评论计算机科学”，那么您会发现有用的内容很少。

其他学科通常会练习和教授设计评论。 搜索“设计评论”，您会发现许多热门歌曲以及相关说明。 设计是试图解决特定问题（无论是美术问题，用户界面设计问题还是软件问题）的任何类型的决策集。 重要的设计问题的解决方案应经过同行评审，就像代码应经过同行评审一样。

大量数据指出，在生命周期中越早发现并解决问题，发现和解决问题的成本就越低。 设计先于代码，因此进行适当的设计审查似乎在直观和经验上都是合理的。 此外，围绕评估的文档（包括原始设计文档和评论）对于新开发人员而言都是宝贵的学习工具。 在许多组织中，开发人员经常切换系统，因此他们不断学习。

这种观点并未得到普遍认同。 一家大型软件公司的软件工程师告诉我，即使该组织渴望编写和审阅设计文档，也很少发生。 高级开发人员倾向于将他们的评论限制在粗略的范围内。 另一方面，高级开发人员非常重视代码审查。 我的软件工程师朋友针对这种情况提供了两种可能的解释：

1. 代码评审是影响构建内容的最后机会：“对其进行审查或与之一起使用。”这种解释假定高级开发人员不相信设计审查的输出是可操作的，因此要等到以后再参与。 过程。
2. 代码比设计更具体，因此更易于评估。 此说明假定高级开发人员无法理解设计。

我认为这两种解释都不具有说服力，但我无法提出更好的解释。

怎么办？

该软件工程师所做的是寻找可以秘密执行设计审查的替代流程。 该个人注意到，当组织进行代码审查时，经常会问诸如“您为什么这样做？”之类的问题。 这些问题的结果是对基本原理的讨论。 因此，个人将为问题编写解决方案，将其提交给代码审查，然后等待将导致基本原理讨论的问题。

设计评审是对设计决策及其基本原理进行介绍的评审。 通常，会探索设计替代方案。 是以代码审查还是设计审查的名义完成此任务，并不比完成任务重要。

当然，我朋友的秘密方法有缺点。 编写可能不得不扔掉的解决方案效率很低。 此外，将设计评论嵌入代码审查意味着最终将设计和审查嵌入代码审查工具中，从而很难在该工具中搜索设计和设计依据。 但是，这些低效率与为特定问题寻求错误解决方案的低效率相形见绌。

—LB

软件系统架构的实践和纪律已经成熟。 您可以为加入一个一直努力并且仍在努力，变得更加有纪律，更可靠，更有生产力和更有效率的职业，以创造能够改善其利益相关者生活的系统而感到自豪。 有了这样的想法，现在该到书本式结束的时候了：继续并设计出色的系统。 您的前任设计的系统已经改变了世界。 轮到你了。