如何成为一名软件架构师(翻译)

什么是软件架构师？

• 软件架构师是一位软件专家，他可以进行高层设计选择并决定技术标准，包括软件编码标准，工具和平台。 （来源：维基百科：软件架构师）
• 软件体系结构是系统的基本组织，由其组件，它们之间的相互关系以及与环境的关系以及确定系统设计和演进的原理来表示。 （来源：软件体系结构手册）

架构水平

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

• 应用程序级别：最低的体系结构级别。专注于一个单一的应用程序。非常详细的底层设计。通常在一个开发团队中进行沟通。
• 解决方案级别：中级架构。专注于满足业务需求（业务解决方案）的一个或多个应用程序。一些高层次但主要是低层次的设计。多个开发团队之间的沟通。
• 企业级别：最高的体系结构级别。专注于多种解决方案。高层次的抽象设计，需要解决方案或应用程序架构师对其进行详细说明。整个组织的沟通。请参阅链接以了解更多信息。

有时，架构师也被视为不同利益相关者之间的“胶水”。三个例子：

• 横向：桥接业务与开发人员或不同开发团队之间的沟通。
• 纵向：在开发人员和管理人员之间架起沟通桥梁。
• 技术：将不同的技术或应用程序相互集成

典型活动

要了解架构师所需的必要技能，我们首先需要了解典型活动。我认为以下列表包含最重要的活动：

• 定义和决定开发技术和平台

• 定义开发标准，例如编码标准，工具，审查过程，测试方法等。

• 支持识别和理解业务需求

• 设计系统并根据需求做出决策

• 记录并传达架构定义，设计和决策

• 检查并检查体系结构和代码，例如，检查定义的模式和编码标准是否正确实施

• 与其他架构师和利益相关者合作

• 指导并咨询开发人员

• 细化并将上层设计精简为下层设计

  注意：体系结构是一项连续的活动，尤其是在将其应用于敏捷软件开发中时。因此，这些活动一遍又一遍地进行。

重要技能

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

• Design(设计)
• Decide(决策)
• Simplify(简化)
• Code(代码)
• Document(文档)
• Communicate(沟通)
• Estimate(估算与评估)
• Balance(平衡)
• Consult(咨询指导)
• Market(市场)

设计

什么是好的设计？这可能是最重要和最具挑战性的问题。我将在理论和实践之间进行区分。两者的结合是最有价值的。让我们从理论开始：

• 了解基本的设计模式：模式是架构师开发可维护系统所需的最重要工具之一。使用模式，您可以重用设计，以通过成熟的解决方案解决常见问题。John Vlissides，Ralph Johnson，Richard Helm和Erich Gamma撰写的《设计模式：可重用的面向对象软件的要素》一书是所有软件开发人员必读的。尽管这些模式已经发布了20多年，但它们仍然是现代软件体系结构的基础。例如，本书描述了模型-视图-控制器（MVC）模式，该模式在许多领域都得到了应用，或者是较新模式的基础，例如模型-视图-视图模型（MVVM）。
• 深入研究模式和反模式：如果您已经了解所有基本的四位数模式，则可以使用更多的软件设计模式扩展您的知识，或者更深入地研究您感兴趣的领域。我最喜欢的有关应用程序集成的书之一是Gregor Hohpe撰写的“ Enterprise Integration Patterns”。无论两个应用程序需要交换数据，无论是来自某些旧系统的老式文件交换还是现代微服务体系结构，本书都适用于各个领域。
• 了解质量衡量标准：定义架构并不是终点。有定义，应用和控制指南和编码标准的原因。您出于质量和非功能性要求而这样做。您想要一个可维护，可靠，适应性强，安全，可测试，可扩展，可用等的系统。要实现所有这些质量属性，一项工作就是应用良好的架构工作。您可以开始在Wikipedia上了解有关质量度量的更多信息。理论很重要。如果您不想成为象牙塔架构师，那么实践同样重要，甚至更为重要。
• 尝试并了解不同的技术堆栈：我认为这是最重要的活动，如果您想成为一名更好的架构师。试用（新）技术堆栈，并了解它们的兴衰。不同或新技术具有不同的设计方面和模式。您很可能没有从翻阅抽象幻灯片中学到任何东西，而是自己尝试一下并感觉到痛苦或缓解。架构师不仅应该具有广泛的知识，而且在某些领域还应该具有深刻的知识。掌握所有技术堆栈并不重要，但要对您所在地区的最重要知识有深入的了解。另外，请尝试您所不熟悉的技术，例如，如果您对SAP R / 3有所了解，则还应该尝试JavaScript，反之亦然。尽管如此，双方仍会对SAP S / 4 Hana的最新进展感到惊讶。例如，您可以自己尝试，并免费在openSAP上课程。好奇并尝试新事物。还可以尝试一些您几年前不喜欢的东西。
• 分析和理解应用模式：查看任何当前框架，例如Angular。您可以在实践中研究很多模式，例如，可观察值。尝试了解它如何在框架中应用，为什么要这样做。而且，如果您真的很专心，请更深入地研究代码并了解其实现方式。
• 好奇并参加交流。meetup

决策

架构师需要能够做出决定，并指导项目或整个组织朝正确的方向发展。

• 知道重要的事情

  ：不要浪费时间进行无关紧要的决定或活动。了解重要的事情。据我所知，没有一本书包含这些信息。我个人最喜欢的是这两个特征，我通常会在评估某些重要事项时考虑这些特征：

  1. 概念完整性：即使您决定以一种方式做到这一点，也要坚持下去，即使有时最好以其他方式做。通常，这会导致更简单的总体概念，简化可理解性并简化维护。
  2. 一致性：例如，如果您定义和应用命名约定，则不是大写或小写，而是以相同的方式将其应用于所有地方。

• 优先：某些决定非常关键。如果不及早采取足够的解决方法，那么通常不太可能在以后删除这些解决方法，这是维护的噩梦，或者更糟的是，开发人员只是停止工作直到做出决定。在这种情况下，有时最好做出“坏”决定，而不是没有决定。但是在遇到这种情况之前，请考虑优先考虑即将做出的决定。有不同的方法可以这样做。我建议看一下在敏捷软件开发中广泛使用的加权最短作业优先（WSJF）模型。特别是时间紧迫性和风险降低措施对于评估架构决策的优先级至关重要。

• 了解您的能力：不要决定您能力之外的事情。这很关键，因为如果不考虑的话，它可能会严重破坏您作为架构师的地位。为避免这种情况，请与您的同伴明确您要承担的责任以及角色的一部分。如果架构师不止一个，那么您应该尊重当前部署的架构级别。作为较低级别的架构师，您最好提出有关高层架构的建议，而不是决策。此外，我建议始终与同伴一起检查关键决策。

• 评估多个选项：涉及决策时，请始终布置多个选项。在我参与的大多数情况下，都有不止一种可能的（好的）选择。仅选择一个选项在两个方面都是不好的：首先，似乎您的工作做得不好，其次，它阻碍了做出正确的决定。通过定义度量，可以基于事实而不是直觉，例如许可成本或成熟度，对选项进行比较。这通常会导致更好和更可持续的决策。此外，可以轻松地将决策出售给不同的利益相关者。此外，如果您没有正确评估选项，则在讨论中可能会遗漏参数。

简化

请记住Occam的Razor解决问题的原则，该原则要求更简单。我将原理解释为：如果您对问题的假设太多而无法解决，则可能会出错或导致不必要的复杂解决方案。应该减少（简化）假设以得出好的解决方案。

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

代码

即使作为企业架构师（最抽象的体系结构级别），您仍然应该知道开发人员的日常工作。而且，如果您不了解如何完成此操作，则可能会遇到两个主要问题：

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

• 有一个辅助项目：这样做的目的是尝试新技术和工具，以了解当今和未来的开发方式。经验是观察，情感和假设的结合（Kurt Schneider撰写的“软件工程中的经验和知识管理”）。阅读教程或一些利弊是好的。但这仅仅是“书籍知识”。仅当您自己尝试事物时，您才能体验到情绪并建立关于事物好坏的假设。使用技术的时间越长，您的假设就会越好。这将帮助您在日常工作中做出更好的决定。当我开始编程时，我没有代码完成，只有一些实用程序库可以加快开发速度。显然，在这种背景下，我今天会做出错误的决定。今天，我们拥有大量的编程语言，框架，工具，过程和实践。只有您对主要趋势有一定的经验和粗略的了解，才能参与对话并引导开发朝着正确的方向发展。

• 找到正确的事物进行尝试

  ：您无法尝试所有事物。这根本不可能。您需要一种更有条理的方法。我最近发现的一种来源是ThoughtWorks 的

  Technology Radar

  。他们将技术，工具，平台，语言和框架分为四类：

  • 采纳：“强烈的意愿为企业使用做好准备”。
  • 试用：“企业应该在一个可以处理风险的项目中进行尝试”。
  • 评估：“探索它如何影响您的企业”
  • 举行：“谨慎处理”。

通过这种分类，更容易获得新事物的概述及其准备情况，以更好地评估下一步要探索的趋势。

文档

架构文档有时越来越重要。重要文档是例如体系结构决策或代码准则。编码开始之前通常需要初始文档，并且需要不断完善。其他文档可以自动生成，因为代码也可以是文档，例如UML类图。

• 干净的代码：如果操作正确，代码是最好的文档。一个好的架构师应该能够区分好的代码和坏的代码。罗伯特·C·马丁（Robert C. Martin）所著的“清洁代码”一书是了解更多关于好坏代码的宝贵资源。
• 尽可能生成文档：系统正在快速变化，很难更新文档。无论是关于API还是以CMDB（配置管理数据库）形式出现的系统格局：基础信息经常变化太快而无法手动更新相应的文档。示例：对于API，如果您是模型驱动的，则可以基于定义文件自动生成文档，也可以直接从源代码自动生成文档。为此，存在许多工具，我认为Swagger和RAML是学习更多内容的一个很好的起点。
• 尽可能少：无论您需要记录什么文档（例如决策文件），都应尝试一次只关注一件事，并且仅包含关于这件事的必要信息。大量的文档很难阅读和理解。附加信息应存储在附录中。特别是对于决策文件，讲一个有说服力的故事而不是仅仅发表大量论据，更为重要。此外，这为您和您的同事节省了很多时间，而他们不得不阅读它。看看您过去做过的一些文档（源代码，模型，决策文件等），然后问自己以下问题：“是否包含所有必要的信息才能理解它？”，“确实需要哪些信息？可以省略吗？” 和“文档中是否有红线？”。
• 了解有关架构框架的更多信息：该点也可以应用于所有其他“技术”点。我把它放在这里，是因为TOGAF或Zachmann之类的框架正在提供“工具”，这些工具在文档站点上显得沉重，尽管它们的附加值并不限于文档。在这样的框架中获得认证可以教会您更系统地解决体系结构。

沟通

根据我的观察，这是最被低估的技能之一。如果您的设计精湛，却无法传达您的想法，那么您的想法可能会受到较小的影响，甚至无法成功。

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

估算与评估

• 了解基本的项目管理原则：作为架构师或首席开发人员，经常会要求您提供估计以实现您的想法：多长时间，多少人，多少技能，哪些技能等？当然，如果您打算引入新的工具或框架，则需要为此类“管理”问题提供答案。最初，您应该能够进行粗略的估算，例如几天，几个月或几年。并且不要忘记，这不仅涉及实现，还有更多活动需要考虑，例如需求工程，测试和修复错误。因此，您应该了解所使用的软件开发过程的活动。您可以应用以获得更好的估计的一件事是使用过去的数据并从中得出您的预测。如果您没有过去的数据，也可以尝试使用Barry W. Boehm的COCOMO之类的方法。如果您部署在敏捷项目中，

• 评估“未知”架构

  ：作为架构师，您还应该能够评估架构在当前或将来上下文中的适用性。这不是一件容易的事，但是您可以通过准备一系列针对每个体系结构的常见问题为它做准备。它不仅与体系结构有关，而且与系统管理方式有关，因为这也为您提供了有关质量的内幕。我建议始终准备一些问题并准备使用。一般问题的一些想法：

  1. 设计实践：体系结构遵循哪些模式？因此，它们是否正确使用？设计遵循红线还是增长不受控制？是否有清晰的结构和关注点分离？
  2. 开发实践：制定并遵循了代码准则？代码如何版本化？部署实践？
  3. 质量保证：测试自动化范围？静态代码分析到位并取得良好结果？同行评论到位？
  4. 安全性：有哪些安全概念？内置安全性？渗透测试或自动安全分析工具是否到位并经常使用？

平衡

• 质量是有代价的：前面我谈到了质量和非功能性需求。如果您过度使用体系结构，将会增加成本并可能降低开发速度。您需要平衡架构和功能需求。应避免过度设计。

• **解决矛盾的目标: **

  矛盾的目标的一个典型示例是短期和长期目标。项目通常倾向于构建最简单的解决方案，而架构师则具有长远的眼光。通常，简单的解决方案不适合长期解决方案，并且有可能在以后被丢弃（降低成本）。为了避免实现错误的方向，需要考虑两点：

  1. 开发人员和企业需要了解长期愿景及其收益，以适应其解决方案和
  2. 负责预算的经理需要参与以了解财务影响。不必直接将100％的远景图放置在适当的位置，但是发达的图块应该适合其中。

• 冲突管理：架构师通常是具有不同背景的多个小组之间的粘合剂。这可能会导致不同级别的通信发生冲突。为了找到一个能够反映长期战略目标的平衡解决方案，通常架构师的作用就是帮助克服冲突。我关于传播理论的起点是舒尔茨·冯·图恩的“四耳模型”。基于此模型，可以显示和推论很多。但是，该理论需要一些实践，在交流研讨会上应该有经验。

咨询指导

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

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

市场

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

• 激励并说服

  ：公司如何说服您购买产品？他们证明了它的价值和好处。但不仅仅是5点。他们包装得很好，并使其尽可能容易消化。

  1. 原型：显示您的想法的原型。有很多用于创建原型的工具。对于喜欢SAP的企业，请访问build.me，在其中可以快速轻松地创建外观漂亮且可单击的UI5应用程序。
  2. 显示视频：除了“无聊的幻灯片”，您还可以显示一个视频，该视频可以演示您的想法或至少是方向。但是请不要过度营销：从长远来看，内容为王。如果您的话不正确，从长远来看，这将损害您的声誉。

• 为您的想法而奋斗并坚持不懈：人们有时不喜欢您的想法，或者他们太懒惰而无法遵循它们。如果您真的对自己的想法深信不疑，则应不断追求并“奋斗”。有时这是必要的。具有长期目标的架构决策通常不是最容易的：开发人员不喜欢它们，因为它们的开发更加复杂。经理们不喜欢它们，因为它们在短期内更昂贵。这是您要坚持不懈并进行谈判的工作。

• 寻找盟友：很难单独建立或实施自己的想法。尝试找到可以支持和说服他人的盟友。使用您的网络。如果还没有，请立即开始构建。您可以从与（思想开放的）同事讨论您的想法开始。如果他们喜欢它，或者至少喜欢它的一部分，那么如果别人提出要求，他们很可能会支持您的想法（“ X的想法很有趣。”）。如果他们不喜欢它，问为什么：也许您错过了什么？还是您的故事不够令人信服？下一步是找到具有决定权的盟友。要求开放的讨论。如果您担心讨论，请记住，有时您需要离开舒适区。

• 重复它，相信它：“ […]研究表明，反复接触某个观点会使人们相信该观点更为普遍，即使该观点仅来自一个人。” （来源：金融品牌）如果您经常发布很少的消息，则可以更轻松地说服人们。但请注意：从我的角度来看，应该明智地使用这种策略，因为它可能会适得其反，成为糟糕的营销技巧。

架构师的技术路线图