38 Actions and Insights to Become a Better Software Architect
几年前，我被问到：“你是如何成为软件架构师的？”。我们谈到了必要的技能，经验以及建立知识所花费的时间和精力。此外，我描述了我所采取的步骤，我积极使用或尝试过的技术以及我在职业和非职业生涯中学到的知识。
这次谈话引发了我自己的思考，我开始为个人成长构建这个主题。“是什么让一个优秀的软件架构师？”，我想，“我怎样才能改进成为更好的软件架构师呢？”。我读过文章和书籍，当然还和我公事的同事交谈。今天，我想与你分享我对我的见解的概述，我认为哪些技能最重要，以及如何改进它们以成为（更好的）软件架构师。
什么是软件架构师？
在我们深入研究细节之前，让我们先看看两个定义。
软件架构师是一名软件专家，负责制定高级设计并指定技术标准，包括软件编码标准，工具和平台。领先的专家被称为首席架构师。
（来源： 维基百科：软件架构师 ）
软件体系结构是系统的基本组织，由其组件，它们彼此之间以及与环境的关系以及决定系统设计和发展的原则来表示。
（来源： 软件架构手册 ）
架构级别
架构可以在抽象的几个“级别”完成。该级别影响必要技能的重要性。由于可能存在许多可能的分类，我最喜欢的分段包括以下3个级别：
- 应用级别 ：最低级别的体系结构。专注于一个应用。非常详细，低级别的设计。通常在一个开发团队内进行沟通
- 解决方案级别 ：中级架构。专注于满足业务需求的一个或多个应用（业务解决方案）。一些高级别，但主要是低级别设计。多个开发团队之间的沟通。
- 企业级 ：最高级别的架构。专注于多种解决方案。高级抽象设计，需要由解决方案或应用架构师详细说明。整个组织的沟通。
有时架构师也被视为不同利益相关者之间的“粘合剂”。三个例子：
- 横向 ：业务和开发人员或不同开发团队之间的沟通桥梁。
- 垂直 ：开发人员和经理之间的沟通桥梁。
- 技术 ：将不同的技术或应用相互集成。
软件架构师的典型活动
要了解架构师需要的必要技能，我们首先需要了解典型的活动。以下（非最终）列表从我的角度包含最重要的活动：
- 定义并决定开发技术和平台
- 定义开发标准，例如编码标准，工具，审查流程，测试方法等。
- 支持识别和理解业务需求
- 设计系统并根据要求做出决策
- 记录并传达架构定义，设计和决策
- 检查并查看体系结构和代码，例如，检查是否正确实现了定义的模式和编码标准
- 与其他架构师和利益相关者合作
- 为开发人员做培训和咨询
- 详细说明并将更高级别的设计细化为更低级别的设计
注意：体系结构是一种持续的活动，尤其是在敏捷软件开发中应用时。因此，这些活动一次又一次地完成。
软件架构师的重要技能
为了支持安排的活动，需要具备特定技能。根据我的经验，阅读书籍和讨论，我们可以将其归结为每个软件架构师应具备的这10项技能：
设计，决定，简化，编码，文档，沟通，估计，平衡，咨询，市场
让我们逐一介绍。对于每一项技能，我已经制定了一些行动或见解，以便在该领域进行改进。
（1）设计
什么可以做出一个好的设计？这可能是最重要和最具挑战性的问题。我将区分理论和实践。根据我的经验，混合使用两者是最有价值的。让我们从理论开始：
- 了解基本设计模式 ：模式是架构师开发可维护系统所需的最重要工具之一。通过模式，你可以重用设计，使用经过验证的解决方案来解决常见问题。由“四人帮”（GoF）撰写的“设计模式：可重复使用的面向对象软件的元素”一书是每个从事软件开发的人必读的内容。虽然20多年前发布的模式，仍然是现代软件架构的基础。例如，本书中描述了模型 - 视图 - 控制器（MVC）模式，该模式应用于许多领域或者是更新模式的基础，例如MVVC 。
- 深入研究模式和反模式 ：如果你已经了解所有基本的GoF模式，那么请使用更多软件设计模式扩展你的知识。或者深入了解你感兴趣的领域。我在应用集成方面最喜欢的书之一是Gregor Hohpe撰写的“ 企业集成模式”一书。本书适用于各种领域，每当两个应用需要交换数据时，无论是来自某些遗留系统的传统文件交换还是现代微服务架构。
- 了解品控措施 ：定义架构不是目的。为什么定义，应用和控制指南和编码标准是有理由的。你这样做是因为质量和非功能性要求。你希望拥有一个可维护，可靠，适应性强，安全，可测试，可扩展，可用等系统。实现所有这些质量属性的一个方面是应用良好的架构工作。你可以开始在维基百科上了解有关品控措施的更多信息。
理论很重要。如果你不想成为象牙塔架构师，那么实践同样甚至更重要。
- 尝试并理解不同的技术堆栈 ：如果你想成为更好的架构师，我认为这是最重要的活动。尝试（新）技术堆栈并了解它们的起伏。不同的或新的技术带有不同的设计思路和模式。你很可能不会从翻阅抽象幻灯片中学到任何东西，而是通过自己尝试并感受到痛苦或缓解。架构师不仅要有广泛的知识，还应该在某些领域有深厚的知识。掌握所有技术堆栈并不重要，但是了解你所在领域最重要的技术堆栈却相当重要。同时尝试不在你所在领域的技术，例如，如果你对SAP R/3有深入了解，你还应该尝试使用JavaScript，反之亦然。尽管如此，双方都会对SAP S/4 Hana的最新进展感到惊讶。例如，你可以自己尝试并免费参加openSAP课程。好奇并尝试新事物。还要尝试几年前你不喜欢的东西。
- 分析和理解应用模式 ：查看任何当前框架，例如Angular 。你可以在实践中学习很多模式，例如Observables 。试着理解它在框架中的应用方式，为什么要这样做。如果你真的很专注，请深入了解代码并了解它是如何实现的。
- 好奇并参加用户组 ：例如，在德国，我们在每个大的城市都有Java用户组（JUG），讨论各种主题，从低级编码到高级架构主题。我非常喜欢这些活动，因为它们可以增强你的思维能力和个人网络。
（2）决定
架构师需要能够做出决策并指导项目或整个组织朝着正确的方向发展。
-
知道什么是重要的：不要浪费时间做不重要的决定或活动。了解重要的事情。据我所知，没有一本书有这些信息（如果你知道的话，请告诉我）。我个人最喜欢的是这两个特征，在判断某些事情是否重要时我通常会考虑这两个特征：
（1）概念完整性 ：如果你决定以一种方式做某件事，坚持下去，即使有时候有其他方式可以做得更好。通常，这会导致更直接的整体概念，简化可理解性并简化维护性。
（2）一致性 ：例如，如果你定义和应用命名约定，它不是大写或小写的问题（真的！），而是要以相同的方式应用于任何地方的问题。 - 优先考虑 ：一些决策非常关键。如果他们没有及早采取足够的解决方法，往往不太可能在以后去除，并且是维护的噩梦，或者更糟糕的是，开发人员会停止工作，直到做出决定。在这种情况下，有时做出“坏”决定甚至更好，而不是没有决定。但在落到这种情况之前，请考虑即将到来的决策的优先级。有不同的方法可以做到这一点。我建议看一下在敏捷软件开发中广泛使用的加权最短作业优先（ Weighted Shortest Job First，WSJF）模型。特别是时间关键性和降低风险的度量对于估计架构决策的优先级至关重要。
- 了解自己的能力：不要做出不属于你职权范围的事情。这是至关重要的，因为如果不加以考虑，它可能会破坏你作为架构师的地位。为了避免这种情况，请与你的同行澄清你的责任以及属于你的角色的部分。如果有多个架构师，那么你应该尊重当前部署的架构级别。作为一个较低级别的架构师，你最好是只提出对更高级别的架构的建议而不是决策。此外，我建议始终与同行一起检查关键决策。
- 评估多个选项：如果涉及决策，请始终布置多个选项 。在我参与的大多数情况下，总是有不止一种可能的（好的）选择。只有一个选项在两个方面是不好的：（1）似乎你没有正确地完成你的工作，（2）它阻碍做出正确的决定。通过定义度量，可以基于事实而不是直觉来比较选项，例如许可证成本或成熟度。这通常会带来更好，更可持续的决策。此外，它还可以将决策兜售给不同的利益相关者。此外，如果你没有被恰当评估过的选项，在讨论时可能会败下风。
（3）简化
请记住解决问题的原则Occam的Razor，表达的是更倾向于简单。我将原则解释如下：如果你对解决问题的解决方案有太多假设可能会出错，或导致不必要的复杂的解决方案。应该减少（简化）假设以得到一个好的解决方案。
- 摇动解决方案 ：为了简化解决方案，“摇动”解决方案并从不同位置查看解决方案通常是有助的。尝试通过自上而下和自下而上思考来塑造解决方案。如果你有数据流或流程，那么首先从左到右，再从右到左思考。提出诸如以下问题：“在一个完美的世界中，你的解决方案会发生什么？”或者：“公司/人X会做什么？”（X可能不是你的竞争对手，而是GAFA公司之一 。）这两个问题迫使你按照奥卡姆剃刀（Occam的Razor）这个建议减少假设。
- 退后一步 ：经过激烈而漫长的讨论，通常会产生高度复杂的涂鸦。你永远不应该把这些视为最终结果。退后一步：再次看一下大局（抽象层面）。它还有意义吗？然后再次在抽象层面上进行重构并重构。有时停止讨论并在第二天继续讨论是有助的。至少我的大脑需要一些时间来处理并提出更好，更优雅和更简单的解决方案。
- 分而治之 ：通过将问题分成更小的部分来简化问题。然后独立解决它们。然后验证这些小块是否匹配在一起。退一步看看整体情况。
- 重构并不邪恶 ：如果找不到更好的想法，那么从一个更复杂的解决方案开始是完全可以的。如果解决方案遇到麻烦，你可以稍后重新考虑解决方案并应用你的研究。重构不是邪恶的。但在开始重构之前，请记住（1）有足够的自动化测试，以确保系统的正常功能和（2）利益相关者的支持。要了解有关重构的更多信息，我建议阅读“ 重构。改进现有代码的设计“由Martin Fowler撰写 。
（4）编码
即使作为最具抽象层次的架构的企业架构师，你仍然应该知道开发人员每天都在做什么。如果你不明白这是怎么做的，你可能会遇到两个主要问题：
（1）开发人员不接受你的说法
（2）你不了解开发人员的挑战和需求。
- 有一个侧面项目 ：这样做的目的是尝试新的技术和工具，以了解如何在今天和未来完成开发。经验是观察，情感和假设的结合（ Kurt Schneider的 “软件工程中的经验和知识管理” ）。阅读教程或一些优点和缺点是好的。但这只是“书本知识”。只有当你自己尝试一些事情时，你才能体验到情感，并且可以建立关于为什么事情好或坏的假设。使用技术的时间越长，你的假设就会越好。这将有助于你在日常工作中做出更好的决策。当我开始编程时，我没有代码自动完成，只有一些实用程序库来加速开发。显然，在这种背景下，我今天会做出错误的决定。今天，我们拥有大量的编程语言，框架，工具，流程和实践。只有你对主要趋势有一些经验和粗略概述，你才能参与对话并将开发引导到正确的方向。
- 找到合适的东西试试 ：你不能尝试一切。这根本不可能。你需要更加结构化的方法。我最近发现的一个来源是ThoughtWorks的技术雷达 。他们将技术，工具，平台，语言和框架分为四类：采用，试用，评估和保留。采用（Adopt） 意味着“为企业使用做好准备的强烈感觉”， 试用（Trial）意味着“企业应该在一个能够处理风险的项目中尝试”， 评估（Assess）意味着“探索它如何影响你的企业”，而保留（Hold）意味着“谨慎处理”。通过这种分类，可以更容易地了解新事物及其准备情况，以便更好地判断下一个要探索的趋势。
（5）文档
架构文档有时很重要，有时也不那么重要。重要文档有如架构决策或编码指南。在编码开始之前经常需要初始文档，需要不断改进。其他文档可以自动生成，因为代码也可以是文档，例如UML类图。
- 清洁代码 ：如果做得对，代码是最好的文档。一个好的架构师应该能够从错误的代码中判断好的代码。罗伯特·C·马丁（Robert C. Martin）的书“ 清洁代码 ” （ Clean Code）是一本非常好的资源，可以更好地了解好坏代码。
- 尽可能生成文档 ：系统正在快速变化，很难更新文档。无论是以CMDB形式的API还是系统格局：基础信息通常变化太快，无法手动更新相应的文档。示例：对于API，如果你是模型驱动的，则可以根据定义文件自动生成文档，或者直接从源代码生成文档。有很多工具，我认为Swagger和RAML是学习更多知识的好起点。
- 尽必要多，尽可能少 ：无论你需要记录什么，例如决策文件，一次只关注一件事情，只包括这一件事的必要信息。广泛的文档很难阅读和理解。其他信息应存储在附录中。特别是对于决策文件而言，告诉一个令人信服的故事更为重要，而不仅仅是抛出大量的论点。此外，这可以节省你和你的同事的时间，他们需要花很多时间阅读它。看看你过去做过的一些文档（源代码，模型，决策文件等）并问自己以下问题：“是否包含了所有必要的信息以便理解它？”，“确实需要哪些信息，哪个可以省略？“和“文档是否有红线？”。
- 了解有关架构框架的更多信息 ：此点也可以应用于所有其他“技术”点。我把它放在这里，因为像TOGAF或Zachmann这样的框架提供了在文档站点上感觉很重的“工具”，尽管它们的附加价值不仅限于文档。在这样的框架中获得认证将教会你更系统地处理架构。
（6）沟通
根据我的观察，这是最被低估的技能之一。如果你在设计方面很出色但无法传达你的想法，你的想法可能只会产生较小的影响，甚至无法成功。
- 了解如何沟通你的想法 ：在板上或活动挂图上进行协作时，必须知道如何正确使用它以构建你和同事的想法。我发现这本书“UZMO - 用你的笔思考”是一个很好的资源，可以提高我在这方面的技能。作为一名架构师，你通常不仅参加会议，通常还需要开会并协调会议。
- 与大型团体进行对话 ：向你的小型或大型团体展示你的想法应该是可行的。如果你对此感到不舒服，请开始向你最好的朋友展示。慢慢扩大小组。这是你只能通过做并离开你的个人舒适区来学习的东西。请耐心等待，这个过程可能需要一些时间。
- 找到合适的沟通级别：不同的利益相关者有不同的兴趣和观点。他们需要在他们的层面上单独解决。在沟通之前，请回过头来检查你要共享的信息是否具有正确的级别，包括抽象性，内容，目标，动机等。 示例 ：开发人员通常对解决方案的细节很感兴趣，而经理更喜欢知道哪个选项可以节省大部分资金。
- 经常沟通 ：如果没有人知道，那么精彩的架构就毫无价值。定期并在每个（组织）级别上分发目标架构及其背后的思想。与开发人员，架构师和经理安排会议，向他们展示所需或定义的方式。
- 保持透明：定期沟通只能部分缓解缺失的透明度。你需要让决策背后的理由透明化。特别是，如果人们没有参与决策过程，就很难理解并遵循其背后的决定和理由。
- 随时准备发表演讲：总有人有问题，你想立即给出正确的答案。尝试始终将最重要的幻灯片放在可以显示和解释的整合套件中。它为你节省了大量时间，为你自己提供了安全保障。
（7）估计和评估
- 了解基本的 项目管理 原则 ：作为架构师或首席开发人员，你经常被要求进行估算以实现你的想法：多长时间，多少钱，多少人，哪些技能等等？当然，如果你计划引入新的工具或框架，你需要为这些“管理”问题找到答案。最初，你应该能够进行粗略估计，例如天，月或年。不要忘记它不仅仅是实现，还有更多的活动要考虑，比如需求工程，测试和修复bug。因此，你应该了解所使用的软件开发过程的活动。你可以应用以获得更好的估算的一件事是使用过去的数据并从中推导出你的预测。如果你没有过去的数据，你也可以尝试使用Barry W. Boehm的 COCOMO等方法。如果你部署在敏捷项目中，请了解如何正确估算和规划 ： Mike Cohn撰写的“敏捷估算和规划”一书提供了该领域的可靠概述。
-
评估“未知”架构 ：作为架构师，你还应该能够判断以前从未见过的架构。这不是一项容易的任务，但你可以通过手头有一套对每个架构都很常见的问题做好准备。它不仅涉及架构，还涉及系统的管理方式，因为这也为你提供了质量方面的内容。我建议总是准备一些问题并准备好使用。一般问题的一些想法：
（1） 设计实践 ：架构遵循哪些模式？它们是否因此被正确使用？设计是否遵循红线或是否存在不受控制的增长？是否存在明确的结构（clear structure）且关注点分离（separation of concerns）？
（2） 开发实践 ：已制定并遵循规范准则了吗？代码如何版本化？部署实践如何？
（3） 质量保证 ：测试自动化覆盖范围如何？静态代码分析到位并取得良好效果了吗？同行评论到位了吗？
（4） 安全性 ：哪些安全概念到位了？内置安全性如何？渗透测试或自动安全分析工具到位并定期使用了吗？
（8）平衡
- 质量是有代价的：早些时候我谈到了质量和非功能性要求。如果你过度使用架构，它将增加成本，并可能降低开发速度。你需要平衡架构和功能需求。应避免过度工程化。
-
解决相互矛盾的目标： 矛盾目标的典型例子是短期和长期目标。项目往往倾向于构建最简单的解决方案，而架构师则考虑到长期愿景。通常，简单的解决方案不适合长期解决方案，并且有可能在以后丢弃（沉没成本）。为避免执行错误的方向，需要考虑两件事：
（1）开发人员和企业需要了解长期愿景及其益处，以便适应他们的解决方案。
（2）负责预算的经理需要参与了解财务影响。没有必要直接使用100％的长期愿景，但是开发的部件应该适合它。 - 冲突管理 ：架构师通常是具有不同背景的多个群体之间的粘合剂。这可能会导致不同层次的沟通发生冲突。为了找到既能反映长期战略目标的平衡解决方案，架构师通常也有助于克服冲突。我关于传播理论的出发点是Schulze von Thun的“四耳模型” 。基于这个模型，可以显示和扣除很多。但是这个理论需要一些实践，这应该在交流研讨会上体验。
（9）咨询和教练
在咨询和指导方面， 积极主动可能是最好的。如果有人问你，通常为时已晚。在架构网站上清理是你想要避免的。你需要以某种方式预见接下来的几周，几个月甚至几年，并为下一步做好准备。
- 有一个愿景 ：如果你被部署在一个项目中，无论是传统的瀑布方式还是敏捷模式，你总是需要对你想要实现的中期和长期目标有所了解。这不是一个详细的概念，但更多的是每个人都可以工作的路线图。由于你无法一次实现所有目标（这是一个旅程），我更喜欢使用成熟度模型（maturity models）。它们提供了一个清晰的结构，可以很容易地理解，并且每次都能提供当前的进展状态。对于不同的方面，我使用不同的模型，例如开发实践或持续交付。成熟度模型中的每个级别都有明确的要求，这些要求遵循SMART标准 ，以判断你是否已达到目标。我找到的一个很好的例子是持续交付 。
- 建立一个 实践社区（community of practice） （CoP） ：在共同利益集团之间交流经验和知识有助于分发想法和标准化方法。例如，你可以在一个房间内每三个月左右召集所有JavaScript开发人员和架构师，并讨论过去和当前的挑战以及如何解决这些挑战或新的方法和途径。架构师可以分享，讨论和调整他们的愿景，开发人员可以分享经验并向同行学习。这样的回合对企业而言也是非常有益的，因为它有助于建立更强大的网络并分发想法。另请参阅SAFe框架中的文章社区实践（Communities of Practice） ，该文章在敏捷环境中解释了CoP概念。
- 举行开门会议 ：误解或含糊不清的一个原因是缺乏沟通。预定一个固定的时间段，例如每周30分钟，与同行交换热门话题。这次会议不设议程，所有事情都可以讨论。尝试当场解决小事。安排更复杂主题的后续工作。
（10）市场
你的想法很棒，你已经很好地传达了它们，但仍然没有人愿意关注？那么你可能缺乏营销技巧。
-
激励和说服 ：公司如何说服你购买产品？他们展示了它的价值和好处。但这不仅仅是因为有5个要点。它们很好地包裹它并使其尽可能容易消化。
（1） 原型 ：展示你的想法的原型。有很多工具可用于创建原型。在喜欢SAP的企业环境中，请查看build.me ，你可以在其中快速轻松地创建外观漂亮且可点击的UI5应用。
（2） 显示视频 ：你还可以显示一个展示你的想法或至少方向的视频，而不是“无聊的幻灯片”。
但是，请不要过度营销：从长远来看，内容是王道。如果你的话没有实现，这将在长期内损害你的声誉。 - 争取你的想法并坚持不懈 ：人们有时候不喜欢你的想法，或者他们懒得跟随他们。如果你真的相信你的想法，你应该继续追随他们并为之“战斗”。这有时是必要的。具有长期目标的架构决策往往不是最简单的：开发人员不喜欢它们，因为它们开发起来更复杂。经理们不喜欢他们，因为他们在短期内更贵。这是你坚持不懈和谈判的工作。
- 寻找盟友 ：建立或实施自己的想法可能很难甚至是不可能的。尝试找到能够支持并帮助说服别人的盟友。使用你的网络。如果还没有，请立即开始构建。你可以先和你（开明的）同行谈谈你的想法。如果他们喜欢它，或者至少是它的一部分，那么如果他们被其他人问到，他们很可能会支持你的想法（“X的想法很有趣。”）。如果他们不喜欢它，请问为什么：也许你错过了什么？或者你的故事不够令人信服？下一步是找到具有决策权的盟友。要求开诚布公的讨论。如果你害怕讨论，请记住，有时你需要离开你的舒适区。
- 重复一遍，相信它 ：“[...]研究表明，反复接触意见会让人们相信这种观点更为普遍，即使该意见的来源只是一个人。”（来源： 金融品牌 ）如果你经常发布一些消息，那么它可以帮助你更轻松地说服人们。但请注意：从我的角度来看，应该明智地使用这样的策略，因为它可能适得其反，作为糟糕的营销手段。
呼吁采取行动
让我知道你的经历以及你如何努力提高你的架构技能。根据你的反馈，我将提出更深入的文章。
网友评论