软件架构师（软件架构师之路）

什么是软件架构师？

• 软件架构师是做出高级设计选择并规定技术标准的软件专家，包括软件编码标准、工具和平台。 （来源：维基百科：软件架构师）
• 软件架构是系统的基本组织，由其组件、它们彼此之间和与环境的关系以及确定系统设计和演化的原则来表示。 （来源：软件架构手册）

软件架构师层次

架构可以在几个“层次”的抽象上完成。水平会影响必要技能的重要性。由于可能有许多分类，我最喜欢的细分包括这 3 个级别：

• 应用程序级别：架构的最低级别。专注于一个单一的应用程序。非常详细，低级的设计。沟通通常在一个开发团队内进行。
• 解决方案级别：架构的中级。专注于满足业务需求的一个或多个应用程序（业务解决方案）。一些高级，但主要是低级设计。沟通是在多个开发团队之间进行的。
• 企业级：架构的最高级别。专注于多种解决方案。高级抽象设计，需要由解决方案或应用程序架构师详细说明。沟通遍及整个组织。

有时建筑师也被视为不同利益相关者之间的“粘合剂”。三个例子：

• 水平：在业务和开发人员或不同开发团队之间架起沟通的桥梁。
• 垂直：在开发人员和管理人员之间架起沟通的桥梁。
• 技术：将不同的技术或应用相互集成

工作日常

要了解架构师所需的必要技能，我们首先需要了解日常的工作。从我的角度来看，以下列表包含最重要的活动：

• 定义和决定开发技术和平台
• 定义开发标准，例如编码标准、工具、审查流程、测试方法等。
• 支持识别和理解业务需求
• 设计系统并根据需求做出决策
• 记录和交流架构定义、设计和决策
• 检查和审查架构和代码，例如检查定义的模式和编码标准是否正确实施
• 与其他架构师和利益相关者合作
• 指导和咨询开发人员
• 细化高级设计并将其细化为低级设计

架构是一项持续的活动，尤其是当它应用于敏捷软件开发时。因此，这些活动一遍又一遍地进行着。

重要技能

为了支持已布置的活动，需要特定技能。根据我的经验，阅读书籍和讨论，我们可以将其归结为每个软件架构师应具备的以下十项技能：

• 设计
• 决策
• 简化
• 代码
• 文档
• 交流
• 评估
• 平衡
• 咨询
• 市场

(1) 设计

什么是好的设计？这可能是最重要和最具挑战性的问题。我将区分理论和实践。根据我的经验，两者兼而有之是最有价值的。让我们从理论开始：

• 了解基本设计模式：模式是架构师开发可维护系统所需的最重要工具之一。借助模式，您可以重用设计以通过经过验证的解决方案来解决常见问题。John Vlissides、Ralph Johnson、Richard Helm、Erich Gamma 所著的《设计模式：可重用的面向对象软件的元素》一书是软件开发人员的必读之书。尽管这些模式是在 20 多年前发布的，但它们仍然是现代软件架构的基础。例如，本书描述了模型-视图-控制器（MVC）模式，该模式在许多领域都有应用，或者是新模式的基础，例如模型-视图-视图模型（MVVM）。
• 深入研究模式和反模式：如果您已经了解所有基本的四人组模式，那么可以通过更多的软件设计模式扩展您的知识，或者深入研究您感兴趣的领域。我最喜欢的有关应用程序集成的书籍之一是 Gregor Hohpe 撰写的《企业集成模式》。这本书适用于两个应用程序需要交换数据的各个领域，无论是来自某些遗留系统的老式文件交换还是现代微服务架构。
• 了解质量措施：定义架构并不是终点。定义、应用和控制指南和编码标准是有原因的。您这样做是因为质量和非功能性要求。您希望拥有一个可维护、可靠、适应性强、安全、可测试、可扩展、可用等的系统。实现所有这些质量属性的一个环节是应用良好的架构工作。您可以开始在 Wikipedia 上了解有关质量度量的更多信息。理论很重要。如果您不想成为象牙塔建筑师，练习同样重要，甚至更重要。
• 尝试并了解不同的技术堆栈：如果你想成为一个更好的建筑师，我认为这是最重要的活动。尝试（新）技术堆栈并了解它们的起伏。不同的或新技术伴随着不同的设计方面和模式。你很可能不会从仅仅翻阅抽象幻灯片中学到任何东西，而是通过自己尝试并感受到痛苦或缓解。架构师不仅应该拥有广泛的知识，而且在某些领域也应该拥有深厚的知识。掌握所有技术栈并不重要，但要对你所在领域最重要的技术栈有深刻的理解。此外，尝试不属于您的领域的技术，例如，如果您深入研究 SAP R/3，您也应该尝试 JavaScript，反之亦然。尽管如此，双方都会对 SAP S/4 Hana 的最新进展感到惊讶。例如，您可以自己尝试并免费参加 openSAP 的课程。保持好奇心并尝试新事物。也试试几年前你不喜欢的东西。
• 分析和理解应用模式：查看任何当前框架，例如 Angular。您可以在实践中学习很多模式，例如 Observables。尝试了解它是如何在框架中应用的，为什么这样做。如果您真的很投入，请更深入地了解代码并了解它是如何实现的。
• 保持好奇并参加用户组。聚会

(2) 决策

架构师需要能够做出决策并引导项目或整个组织朝着正确的方向前进。

• 知道什么是重要的：不要在不重要的决定或活动上浪费时间。了解什么是重要的。据我所知，没有一本书包含这些信息。我个人最喜欢的是这两个特征，我在评估某件事是否重要时通常会考虑这些特征：概念完整性：如果您决定以一种方式做事，请坚持下去，即使有时以不同的方式做事会更好。通常，这会导致更直接的整体概念、易于理解和易于维护。统一性：例如，如果您定义和应用命名约定，则它不是关于大写或小写，而是以相同的方式将其应用到任何地方。
• 优先级：一些决定非常关键。如果他们没有及早采取足够的解决方法，这些解决方法通常不太可能在以后被删除，并且是维护的噩梦，或者更糟糕的是，开发人员只是停止工作，直到做出决定。在这种情况下，有时做出“糟糕”的决定比没有决定更好。但在遇到这种情况之前，请考虑优先考虑即将做出的决定。有不同的方法可以做到这一点。我建议看一下在敏捷软件开发中广泛使用的加权最短工作优先 (WSJF) 模型。特别是时间紧迫性和风险降低措施对于估计架构决策的优先级至关重要。
• 了解你的能力：不要决定不属于你能力的事情。这是至关重要的，因为如果不加以考虑，它可能会严重破坏您作为架构师的地位。为避免这种情况，请与您的同事澄清您有哪些责任以及您的角色的一部分。如果有不止一位架构师，那么您应该尊重您当前部署的架构级别。作为较低级别的架构师，您最好提出更高级别架构的建议而不是决策。此外，我建议始终与同行一起检查关键决策。
• 评估多个选项：如果涉及到决策，请始终列出多个选项。在我参与的大多数案例中，有不止一种可能的（好的）选择。只选择一个选项在两个方面是不好的：首先，您似乎没有正确地完成您的工作，其次它阻碍了做出正确的决定。通过定义措施，可以根据事实而不是直觉来比较选项，例如许可成本或成熟度。这通常会导致更好和更可持续的决策。此外，它可以轻松地将决策出售给不同的利益相关者。此外，如果您没有正确评估选项，您可能会在讨论时错过争论。

(3) 简化

请记住解决问题的原则奥卡姆剃刀，它指出更喜欢简单。我将原理解释如下：如果您对要解决的问题有太多假设，那么您的解决方案可能是错误的或导致不必要的复杂解决方案。应该减少（简化）假设以得出一个好的解决方案。

• 摇动解决方案：为了简化解决方案，通常有助于“摇动”解决方案并从不同位置查看它们。尝试通过自上而下和自下而上的思考来塑造解决方案。如果您有数据流或流程，那么首先从左到右再从右到左思考。提出以下问题：“在完美世界中，您的解决方案会发生什么变化？” 或者：“公司/个人 X 会做什么？” （X 可能不是你的竞争对手，而是 GAFA（谷歌、苹果、Facebook 和亚马逊）公司之一。）这两个问题都迫使你减少奥卡姆剃刀建议的假设。
• 退后一步：经过激烈和长时间的讨论，结果往往是高度复杂的涂鸦。您永远不应该将这些视为最终结果。退后一步：再看大局（抽象层面）。它仍然有意义吗？然后在抽象级别再次遍历它并重构。有时它有助于停止讨论并在第二天继续。至少我的大脑需要一些时间来处理并想出更好、更优雅、更简单的解决方案。
• 分而治之：通过将问题分成更小的部分来简化问题。然后独立解决。然后验证小块是否匹配在一起。退后一步，看看这方面的整体情况。
• 重构不是邪恶的：如果找不到更好的想法，从更复杂的解决方案开始是完全可以的。如果解决方案遇到麻烦，您可以稍后重新考虑解决方案并应用您的学习。重构并不邪恶。但在开始重构之前，请记住：(1) 有足够的自动化测试到位，以确保系统的正确功能和 (2) 利益相关者的支持。要了解有关重构的更多信息，我建议阅读“重构。改进现有代码的设计”，Martin Fowler。

(4) 代码

即使作为最抽象的架构级别的企业架构师，您仍然应该知道开发人员每天都在做什么。如果您不了解这是如何完成的，您可能会面临两个主要问题：

1. 开发者不会接受你的说法。
2. 您不了解开发人员的挑战和需求。

• 有一个副业: 这样做的目的是尝试新的技术和工具，以了解现在和未来的开发方式。经验是观察、情感和假设的结合（Kurt Schneider 的“软件工程中的经验和知识管理”）。阅读教程或一些利弊是好的。但这只是“书本知识”。只有当你自己尝试事物时，你才能体验到情绪，并能建立起关于事物为什么好或坏的假设。你使用技术的时间越长，你的假设就会越好。这将帮助您在日常工作中做出更好的决定。当我开始编程时，我没有代码完成，只有一些实用程序库来加速开发。显然，在这种背景下，我今天会做出错误的决定。今天，我们拥有大量的编程语言、框架、工具、流程和实践。只有当您对主要趋势有一定的经验和粗略的了解时，您才能参与对话并引导开发朝着正确的方向发展。
• 找到合适的东西去尝试：你不能尝试所有的东西。这简直是​​不可能的。您需要一种更有条理的方法。我最近发现的一个来源是 ThoughtWorks 的技术雷达。他们将技术、工具、平台、语言和框架分为四类：采用：“企业使用准备就绪的强烈感觉”。试用：“企业应该在一个可以应对风险的项目中进行尝试”。评估：“探索它如何影响您的企业”持有：“谨慎处理”。

通过这种分类，可以更轻松地了解新事物及其准备情况，以便更好地评估接下来要探索的趋势。

(5) 文档

架构文档有时更重要，有时更不重要。重要的文档例如架构决策或代码指南。在编码开始之前通常需要初始文档，并且需要不断完善。其他文档可以自动生成，因为代码也可以是文档，例如 UML 类图。

• 干净的代码：如果做得好，代码是最好的文档。一个好的架构师应该能够区分好代码和坏代码。Robert C. Martin 所著的“Clean Code”一书是了解更多关于好代码和坏代码的一个非常好的资源。
• 尽可能生成文档：系统变化很快，很难更新文档。无论是 API 还是 CMDB（配置管理数据库）形式的系统架构：底层信息经常变化太快，无法手动更新相应的文档。示例：对于 API，如果您是模型驱动的，您可以根据定义文件自动生成文档，或者直接从源代码生成文档。为此存在很多工具，我认为 Swagger 和 RAML 是了解更多信息的良好起点。
• 尽可能多，尽可能少：无论您需要记录什么，例如决策文件，尝试一次只关注一件事，并且只包含这件事的必要信息。大量的文档很难阅读和理解。附加信息应存储在附录中。特别是对于决策文件来说，讲述一个令人信服的故事而不是仅仅抛出大量论据更为重要。此外，这为您和您必须阅读它的同事节省了大量时间。查看您过去完成的一些文档（源代码、模型、决策文件等）并问自己以下问题：“是否包含所有必要的信息来理解它？”、“哪些信息是真正需要的？哪个可以省略？” 和“文档是否有红线？”。
• 了解有关架构框架的更多信息：这一点也可以应用于所有其他“技术”点。我把它放在这里，因为像 TOGAF 或 Zachmann 这样的框架正在提供在文档方面感觉很重的“工具”，尽管它们的附加价值不仅限于文档。在这样的框架中获得认证可以教你更系统地处理架构。

(6) 沟通

根据我的观察，这是最被低估的技能之一。如果您在设计方面很出色，但无法传达您的想法，那么您的想法可能影响较小，甚至无法成功。

• 了解如何交流您的想法：在白板或活动挂图上进行协作时，必须知道如何正确使用它以构建您和您的同行的想法。我发现《UZMO — 用你的笔思考》这本书是提高我在这方面的技能的好资源。作为架构师，您通常不仅要参加会议，还需要推动会议并主持会议。
• 向大型团体发表演讲：向小型或大型团体展示您的想法对您来说应该是可行的。如果您对此感到不舒服，请开始向您最好的朋友展示。慢慢扩大小组。这是你只能通过实践和离开你的个人舒适区来学习的东西。对自己要有耐心，这个过程可能需要一些时间。
• 找到合适的沟通水平：不同的利益相关者有不同的兴趣和观点。他们需要在他们的层面上单独解决。在交流之前，请退后一步检查您要分享的信息是否具有正确的级别，包括抽象性、内容、目标、动机等。示例：开发人员通常对解决方案的极小细节感兴趣，而经理更愿意知道哪种选择最省钱。
• 经常交流：如果没有人知道，一个出色的架构是毫无价值的。定期在每个组织级别上分发目标架构及其背后的想法。安排与开发人员、架构师和经理的会议，向他们展示所需或定义的方式。
• 保持透明：定期沟通只能部分缓解缺失的透明度。您需要使决策背后的原因透明化。特别是，如果人们不参与决策过程，就很难理解和遵循其背后的决策和理由。
• 随时准备进行演示：总有人提出问题，您想立即给出正确的答案。尝试始终将最重要的幻灯片放在一个可以展示和解释的综合集中。它可以为您节省大量时间，并为您自己提供安全保障。

(7) 评估

• 了解基本的项目管理原则：作为架构师或首席开发人员，您经常被要求估算实现您的想法：多长时间，多少人，多少人，哪些技能等？当然，如果您打算引入新的工具或框架，您需要对这类“管理”问题有一个答案。最初，您应该能够给出一个粗略的估计，例如几天、几个月或几年。而且不要忘记，这不仅仅是关于实施，还有更多活动需要考虑，比如需求工程、测试和修复错误。因此，您应该了解所使用的软件开发过程的活动。您可以应用以获得更好的估计的一件事是使用过去的数据并从中得出您的预测。如果您没有过去的数据，您还可以尝试 Barry W. Boehm 的 COCOMO 等方法。如果您部署在敏捷项目中，
• 评估“未知”架构：作为架构师，您还应该能够评估架构对当前或未来环境的适用性。这不是一项容易的任务，但您可以通过手头的一组问题来为它做好准备，这些问题对于每种架构都是常见的。它不仅关乎架构，还关乎系统的管理方式，因为这也让您了解质量。我建议始终准备好一些问题并准备好使用。一般问题的一些想法：设计实践：架构遵循哪些模式？因此，它们是否被正确使用？设计是否遵循红线或是否存在不受控制的增长？是否有清晰的结构和关注点分离？开发实践：已制定并遵循代码指南？代码是如何版本化的？部署实践？质量保证：测试自动化覆盖率？静态代码分析到位且效果好？同行评审到位了吗？安全性：有哪些安全概念？内置安全性？渗透测试或自动化安全分析工具是否到位并经常使用？

(8) 平衡

• 质量是有代价的：之前我谈到了质量和非功能性要求。如果您过度使用架构，则会增加成本并可能降低开发速度。您需要平衡架构和功能需求。应避免过度工程。
• 解决矛盾的目标：矛盾目标的一个典型例子是短期和长期目标。项目通常倾向于构建最简单的解决方案，而架构师则有长远的眼光。通常，简单的解决方案不适合长期解决方案，并且有可能在以后被抛弃（沉没成本）。为避免执行错误的方向，需要考虑两件事：开发人员和企业需要了解长期愿景及其好处，以便调整他们的解决方案和负责预算的经理需要参与以了解财务影响。没有必要直接拥有 100% 的长期愿景，但开发的部分应该适合它。
• 冲突管理：架构师通常是具有不同背景的多个群体之间的粘合剂。这可能会导致不同沟通层次上的冲突。为了找到一个也反映长期战略目标的平衡解决方案，架构师的角色通常是帮助克服冲突。我关于传播理论的出发点是 Schulze von Thun 的“四耳模型”。基于这个模型，可以显示和扣除很多东西。但是这个理论需要一些实践，应该在传播研讨会中体验。

(9) 咨询和指导

在咨询和指导方面，积极主动可能是您能做的最好的事情。如果你被问到，通常为时已晚。在架构站点上进行清理是您想要避免的事情。你需要以某种方式预见接下来的几周、几个月甚至几年，并为接下来的步骤做好准备。

• 有远见：如果你被部署在一个项目中，无论是传统的瀑布式方法还是敏捷，你总是需要对你想要实现的中长期目标有一个远见。这不是一个详细的概念，而是一个人人都能工作的路线图。由于您无法一次完成所有事情（这是一段旅程），我更喜欢使用成熟度模型。它们给出了一个清晰的结构，可以很容易地使用，并且每次都给出当前的进度状态。对于不同的方面，我使用不同的模型，例如开发实践或持续交付。成熟度模型中的每个级别都有明确的要求，这些要求遵循 SMART 标准，以便于衡量您是否达到了目标。我发现的一个很好的例子是继续交付。
• 建立实践社区 (CoP)：在共同利益集团之间交流经验和知识有助于传播想法和标准化方法。例如，您可以每三个月左右将所有 JavaScript 开发人员和架构师聚集在一个房间里，并讨论过去和当前的挑战以及如何解决它们或新的方法论和方法。架构师可以分享、讨论和调整他们的愿景，开发人员可以分享经验并向同行学习。这样的一轮对企业和个人本身都非常有利，因为它有助于建立更强大的网络并传播想法。另请查看 SAFe 框架中的实践社区一文，该文章解释了敏捷环境中的 CoP 概念。
• 进行开放式会议：误解或模棱两可的来源之一是缺乏沟通。固定一个固定的时间段，例如每周 30 分钟，用于与同行交流热门话题。本次会议没有议程，一切都可以讨论。尝试当场解决小问题。安排对更复杂主题的跟进。

(10) 市场

您的想法很棒，并且您已经很好地传达了它们，但仍然没有人愿意遵循？那么你可能缺乏营销技巧。

• 激励和说服：公司如何说服您购买产品？他们展示了它的价值和好处。但不仅仅是 5 个要点。他们把它包裹得很好，让它尽可能容易消化。原型：展示你的想法的原型。有很多用于创建原型的工具。在喜欢 SAP 的企业中，请查看 build.me，您可以在其中快速轻松地创建美观且可点击的 UI5 应用程序。展示视频：除了“无聊的幻灯片”，您还可以展示展示您的想法或至少方向的视频。但请不要过度营销：从长远来看，内容为王。如果你的话不成真，从长远来看，这将损害你的声誉。
• 为你的想法而奋斗并坚持不懈：人们有时不喜欢你的想法，或者他们只是懒得追随它们。如果你真的被你的想法说服了，你就应该不断地去追求它们并“战斗”。这有时是必要的。具有长期目标的架构决策通常不是最简单的：开发人员不喜欢它们，因为它们的开发更复杂。经理们不喜欢它们，因为它们在短期内更贵。你的工作就是坚持不懈并进行谈判。
• 寻找盟友：​​靠自己建立或执行你的想法可能很困难，甚至是不可能的。尝试寻找可以支持和帮助说服他人的盟友。使用您的网络。如果您还没有，请立即开始构建它。您可以先与（思想开放的）同行讨论您的想法。如果他们喜欢它，或者至少部分喜欢它，那么如果其他人问起他们很可能会支持你的想法（“X 的想法很有趣。”）。如果他们不喜欢，问为什么：也许你错过了什么？还是你的故事不够有说服力？下一步是寻找具有决策权的盟友。要求开诚布公的讨论。如果您害怕讨论，请记住有时您需要离开舒适区。
• 重复它，相信它：“[…] 研究表明，反复接触某种观点会使人们相信这种观点更为普遍，即使该观点的来源只是一个人。” （来源：金融品牌）但请注意：从我的角度来看，应该明智地使用这种策略，因为它可能会适得其反，成为一种糟糕的营销技巧。

推荐书籍

• 重构。Martin Fowler改进现有代码的设计
• Gregor Hohpe 编写的企业集成模式
• 设计模式：可重用的面向对象软件的元素 John Vlissides、Ralph Johnson、Richard Helm、Erich Gamma
• Kurt Schneider的软件工程经验和知识管理
• Robert C. Martin 的清洁代码
• UZMO——用你的笔思考
• Mike Cohn 的敏捷估计和规划
• 设计数据密集型应用程序- Martin Kleppmann（如果您对数据、分析、数据科学做任何事情，这是必读的）。

架构师的技术路线图

解决方案架构师的类型