# 成为一个更好的架构师
本文翻译于[SoftwareArchitect](https://github.com/justinamiller/SoftwareArchitect),原创翻译，有删减，介意请查看原文，转载请联系我。
多年前，有人问我:"如何成为软件架构师?"。我认为需要必要的技能，经验以及积累知识所需的时间和奉献精神。
### 1. 内容
* 软件架构师的定义
* 软件架构的级别
* 软件架构师的常规工作内容
* 软件架构师的重要技能
* 架构师技术路线图
### 2. 软件架构师的定义
在开始之前，让我们先看看这个定义。
* 软件架构师是一位软件专家，他可以进行高层设计选择并决定技术标准，包括软件编码标准，工具和平台。首席专家被称为首席架构师。（来源：Wikipedia: Software Architect）
### 3. 软件架构的级别
架构可以被抽象成很多个级别，不同的人会有不同的分发，这里我更喜欢分成三个级别：
* **应用程序级别**：最低的体系结构级别。专注于一个单一的应用程序。非常详细的底层设计。通常在一个开发团队中进行沟通
* **解决方案级别**：中级架构。专注于满足业务需求（业务解决方案）的一个或多个应用程序。有一些高层次，但主要是低层次的设计。多个开发团队之间的沟通。
* **企业级别**：最高级别的体系结构。专注于多种解决方案。高层次的抽象设计，需要解决方案或应用程序架构师对其进行详细说明。整个组织的沟通，更多详情见[链接](https://github.com/justinamiller/EnterpriseArchitecture)
### 4. 软件架构师的常规工作内容
要了解架构师所需的必要技能，我们首先需要了解常规工作内容。我认为以下（非最终）清单包含最重要的工作内容：
* 定义和决定开发技术和平台
* 定义开发标准，例如编码标准，工具，审查流程，测试方法等。
* 支持识别和理解业务需求
* 设计系统并根据需求做出决策
* 记录并传达架构定义，设计和决策
* 检查并回顾架构和代码，例如，检查定义的模式和编码标准是否正确实施
* 与其他架构师和利益相关者合作
* 指导并咨询开发人员
* 将高级设计改进为低级设计并详细说明。注意：架构是一项连续的工作，尤其是在将其应用于敏捷软件开发中时。因此，这些工作一遍又一遍地进行。
### 5. 软件架构师的重要技能
为了支撑常规工作内容，需要特定技能。根据我的经验，阅读书籍和讨论，我们可以将其归结为每个软件架构师应具备的以下10种技能：
```
设计，决定，简化，编码，文档，沟通，估计，平衡，咨询，市场
```
#### （1）设计
什么是好的设计？这可能是最重要和最具挑战性的问题。我将在理论和实践之间进行区分。以我的经验，两者的结合是最有价值的。让我们从理论开始：
* **了解基本的设计模式**：模式是架构师开发可维护系统所需的最重要工具之一。使用模式，您可以重复使用设计，以通过可靠的解决方案解决常见问题。由GoF编写的《设计模式：可重用的面向对象软件的要素》一书是所有从事软件开发的人必读的书。尽管该模式已发布20多年，但它们仍然是现代软件体系结构的基础。例如，本书描述了模型-视图-控制器（MVC）模式，该模式在许多领域都得到了应用，或者是更新模式的基础，例如MVVM。
* **深入研究模式和反模式**：如果您已经了解所有基本的GoF模式，则可以使用更多的软件设计模式来扩展您的知识。或更深入地研究您感兴趣的领域。我最喜欢的应用程序集成之一是Gregor Hohpe撰写的“ Enterprise Integration Patterns”一书。无论两个应用程序需要交换数据，无论是来自某些旧系统的旧式文件交换还是现代微服务体系结构的交换，这本书都适用于各个领域。
* **了解质量度量**：定义架构不是终点。它有定义，应用和控制指南和编码标准的原因。您出于质量和非功能性要求而这样做。您想要一个可维护，可靠，适应性强，安全，可测试，可伸缩，可用等的系统。要实现所有这些质量属性，一件事情就是应用良好的架构工作。您可以开始更多地了解维基百科上的质量度量。理论很重要。如果您不想成为象牙塔架构师，那么实践同样重要，甚至更为重要。
* **尝试并了解不同的技术堆栈**：如果您想成为一名更好的架构师，我认为这是最重要的活动。试用（新）技术堆栈，并了解它们的兴衰。不同或新技术具有不同的设计方面和模式。您很可能从翻阅抽象幻灯片中不会学到任何东西，而是自己尝试一下，并感到痛苦或缓解。架构师不仅应该具有广泛的知识，而且在某些领域还应具有深厚的知识。掌握所有技术堆栈并不重要，但要对您所在地区的最重要知识有深入的了解。另外，请尝试不使用您所处领域的技术，例如，如果您深入SAP R / 3，则还应该尝试JavaScript，反之亦然。尽管如此，双方仍会对SAP S / 4 Hana的最新进展感到惊讶。例如，您可以自己尝试，然后免费在openSAP上课程。好奇并尝试新事物。还可以尝试一些您几年前不喜欢的东西。
* **分析和理解应用模式**：查看任何当前框架，例如Angular。您可以在实践中研究很多模式，例如“可观察物”。尝试了解它如何在框架中应用，为什么要这样做。而且，如果您真的很专心，请更深入地研究代码并了解其实现方式。
* **充满好奇并作为一个用户**。
#### （2）决定
架构师需要能够做出决定并指导项目或整个组织朝正确的方向发展。
* **知道什么是重要的**：不要浪费时间进行无关紧要的决定或活动。了解重要的事情。据我所知，没有一本书包含这些信息（如果您知道的话，请告诉我）。我个人最喜欢的是这两个特征，我通常会在评估某些重要事项时考虑这些特征：
1. 概念完整性：如果您决定以一种方式来做，那就坚持下去，即使有时最好以其他方式去做。通常，这会导致更简单的总体概念，简化可理解性并简化维护
2. 一致性：例如你定义了应用的命名，不用关心是大写还是小写，但是要做到所有的地方都是一个标准，一个表达方式。
* **优先排序**：某些决定至关重要。如果不及早采取措施，就会需要很多的解决方法，这些措施通常不太可能在以后删除，并且是维护的噩梦，或者更糟的是，开发人员只能停止工作，直到做出决定。在这种情况下，有时最好做出“错误”的决定而不是没有做决定。但是在遇到这种情况之前，请考虑优先考虑即将做出的决定。有不同的方法可以这样做。我建议看一下在敏捷软件开发中广泛使用的加权最短作业优先（WSJF）模型。特别是时间紧迫性和风险降低措施对于评估架构决策的优先级至关重要。
* **了解自己的能力**：不要决定能力之外的事情。这很关键，因为如果不考虑的话，它可能会严重破坏您作为架构师的地位。为避免这种情况，请与您的同伴明确您要承担的责任以及角色的一部分。如果架构师不止一个，那么您应该尊重当前部署的架构级别。作为较低级别的架构师，您最好提出有关高层架构的建议，而不是决策。此外，我建议始终与同伴一起检查关键决策。
* **评估多个选项**：涉及决策时，请始终布置多个选项。在我参与的大多数情况下，都有不止一种可能的（好的）选择。仅选择一个选项在两个方面都是不利的：（1）您似乎没有正确地完成工作，（2）阻碍了做出正确的决定。通过定义度量，可以基于事实而不是直觉来比较选项，例如许可费用或期限。这通常会导致更好和更可持续的决策。此外，可以轻松地将决策出售给不同的利益相关者。此外，如果您没有正确评估选项，则在讨论中可能会遗漏参数。
#### （3）简化
请记住解决问题的原则Occam’s Razor（它更偏爱简单）。 我将原理解释为：如果您对问题的假设太多而无法解决，则可能会出错或导致不必要的复杂解决方案。 应该减少（简化）假设以得出好的解决方案。
* **摇动解决方案**：为了简化解决方案，通常有助于“摇动”解决方案并从不同位置查看它们。尝试通过自上而下和自下而上的方式来塑造解决方案。如果您有数据流或流程，请首先从左到右，再从右到左思考。提出以下问题：“在完美的世界中您的解决方案会发生什么？”或：“ X公司/人会做什么？”（X可能不是您的竞争对手，而是GAFA公司之一。）这两个问题都迫使您减少Occam’s Razor建议的假设。
* **退后一步**：经过长时间的深入讨论，通常会得出高度复杂的涂鸦。您永远都不应将这些视为最终结果。退后一步：再次查看全局（抽象级别）。还是有意义吗？然后再次在抽象级别上进行遍历并进行重构。有时，它有助于停止讨论并在第二天继续。至少我的大脑需要一些时间来处理并提出更好，更优雅，更简单的解决方案。
* **分而治之**：通过将问题分成更小的部分来简化问题。然后独立解决它们。然后验证小块是否匹配。退后一步以查看总体情况。
* **重构不是邪恶的**：如果找不到更好的主意，那么从更复杂的解决方案开始是完全可以的。如果解决方案遇到麻烦，您可以稍后重新考虑解决方案并应用您的学习。重构不是邪恶的。但是在开始重构之前，请记住要进行以下工作：（1）进行足够的自动化测试，以确保系统的正确功能；（2）从利益相关者获取支持。要了解有关重构的更多信息，建议阅读“Refactoring. Improving the Design of Existing Code”，作者是Martin Fowler。
#### （4）编码
即使作为企业架构师（最抽象的体系结构级别），您仍然应该知道开发人员的日常工作。而且，如果您不了解如何完成此操作，则可能会遇到两个主要问题：
1. 开发人员不会接受您的说法。
2. 您不了解开发人员的挑战和需求。
* **有一个附带项目**：此项目的目的是尝试新技术和工具，以了解当今和未来的开发方式。经验是观察，情感和假设的结合（Kurt Schneider的“软件工程中的经验和知识管理”）。阅读教程或一些利弊是好的。但这仅仅是“书籍知识”。仅当您自己尝试事物时，您才能体验到情绪并建立关于事物好坏的假设。而且，您使用某项技术的时间越长，您的假设就会越好。这将帮助您在日常工作中做出更好的决定。当我开始编程时，我没有代码完成，只有一些实用程序库可以加快开发速度。显然，在这种背景下，我今天会做出错误的决定。今天，我们拥有大量的编程语言，框架，工具，过程和实践。只有您对主要趋势有一定的经验和粗略的了解，才能参与对话并引导开发朝正确的方向发展。
* **找到正确的事物进行尝试**：您无法尝试所有事物。这根本是不可能的。您需要一种更有条理的方法。我最近发现的一种来源是ThoughtWorks的Technology Radar。他们将技术，工具，平台，语言和框架分为四类：采用，试用，评估和保留。 “采用”表示“强烈准备为企业使用做好准备”，“试用”表示“企业应该在一个可以处理风险的项目中进行尝试”，“评估”表示“研究它如何影响您的企业”，“持有”表示“谨慎处理”。通过这种分类，更容易获得新事物的概述及其准备情况，以更好地评估下一步要探索的趋势。
#### （5）文档
架构文档有时或多或少地很重要。 重要文档是例如体系结构决策或代码准则。 编码开始之前通常需要初始文档，并且需要不断完善。 其他文档可以自动生成，因为代码也可以是文档，例如 UML类图。
* **干净的代码**：如果操作正确，代码是最好的文档。一个好的架构师应该能够区分好的代码和坏的代码。罗伯特·C·马丁（Robert C. Martin）所著的“清洁代码”一书是了解更多关于好坏代码的宝贵资源。
* **在可能的情况下生成文档**：系统日新月异，很难更新文档。无论是关于API还是以CMDB形式出现的系统格局：基础信息经常变化太快而无法手动更新相应的文档。示例：对于API，如果您是模型驱动的，则可以基于定义文件自动生成文档，也可以直接从源代码生成文档。为此，存在许多工具，我认为Swagger和RAML是学习更多内容的一个很好的起点。
* **尽可能多地，尽可能少地进行**：无论您需要记录什么文档（例如决策文件），都一次尝试仅关注一件事，并且仅包含关于这件事的必要信息。大量的文档很难阅读和理解。附加信息应存储在附录中。特别是对于决策文件，讲一个有说服力的故事而不是仅仅发表大量论据，更为重要。此外，这为您和您的同事节省了很多时间，而后者需要阅读。看看您过去做过的一些文档（源代码，模型，决策文件等），然后问自己以下问题：“是否包含所有必要的信息才能理解它？”，“确实需要哪些信息，并且可以省略吗？”和“文档中是否有红线？”。
* **了解有关架构框架的更多信息**：该点也可以应用于所有其他“技术”点。我把它放在这里，是因为TOGAF或Zachmann之类的框架正在提供“工具”，这些工具在文档站点上感觉很沉重，尽管它们的附加值并不限于文档。在这样的框架中获得认证可以教会您更系统地解决体系结构。
#### （6）沟通
根据我的观察，这是最被低估的技能之一。如果您的设计精湛，却无法传达您的想法，那么您的想法可能会受到较小的影响，甚至无法成功。
* **了解如何交表达您的想法**：在董事会或活动挂图上进行协作时，必须了解如何正确使用它，以构筑您和您的同行的思想。我发现《 UZMO-用笔思考》是提高我在这一领域技能的好资源。作为架构师，您通常不仅会参加会议，而且通常需要主持会议并主持会议。
* **与大群人进行演讲**：向小群或大群人展示您的想法对您来说应该是可行的。如果您对此感到不舒服，请开始向您最好的朋友介绍。慢慢扩大小组。这是您只能通过做和离开自己的舒适区来学习的东西。请耐心等待，此过程可能需要一些时间。
* **找到正确的沟通水平**：不同的利益相关者有不同的兴趣和看法。需要在其级别上对它们进行单独处理。在进行交流之前，请退后一步并检查您要共享的信息是否具有正确的级别，有关抽象性，内容，目标，动机等。示例：开发人员通常对解决方案的很少细节感兴趣，而经理则对此感兴趣。宁愿知道哪个选项可以节省最多的钱。
* **经常交流**：如果没有人知道，一个出色的架构将毫无价值。定期并在每个（组织）级别上分发目标体系结构及其背后的思想。安排与开发人员，建筑师和管理人员的会议，以向他们展示所需或已定义的方式。
* **保持透明**：定期交流只能部分缓解缺少的透明度。您需要使决策背后的原因透明化。特别是，如果人们不参与决策过程，则很难理解和遵循其背后的决策和理由。
* **随时准备做一个演讲**：总是会有人提出问题，而您想立即给出正确的答案。尝试始终将最重要的幻灯片放在一个可以显示和解释的合并集中。它为您节省了大量时间，并为您提供安全保护。
#### （7）估计
* **了解基本的项目管理原则**：作为架构师或首席开发人员，经常会要求您提供估计以实现您的想法：多长时间，花费多少，多少人，哪些技能等？当然，如果您打算引入新的工具或框架，则需要为此类“管理”问题提供答案。最初，您应该能够进行粗略的估算，例如几天，几个月或几年。并且不要忘记，这不仅涉及实现，还有更多活动需要考虑，例如需求工程，测试和修复错误。因此，您应该了解所使用的软件开发过程的活动。您可以应用以获得更好的估计的一件事是使用过去的数据并从中得出您的预测。如果您没有过去的数据，也可以尝试使用Barry W. Boehm的COCOMO之类的方法。如果您部署在敏捷项目中，请学习如何进行估算和正确计划：Mike Cohn撰写的《敏捷估算和规划》一书对此领域提供了扎实的概述。
* **评估“未知”架构**：作为架构师，您还应该能够评估架构在当前或将来上下文中的适用性。这不是一件容易的事，但是您可以通过准备一系列常见于每种架构的问题来为它做准备。它不仅涉及架构，还涉及系统的管理方式，因为这也使您了解质量。我建议始终准备一些问题并准备使用。一些一般性问题的想法：
1. 设计实践：体系结构遵循哪些模式？因此，它们是否正确使用？设计遵循红线还是增长不受控制？是否有清晰的结构和关注点分离？
2. 开发实践：制定并遵循了代码准则？代码如何版本化？部署实践？
3. 质量保证：测试自动化范围？静态代码分析到位并取得良好结果？同行评论到位？
4. 安全性：有哪些安全概念？内置安全性？渗透测试或自动安全分析工具是否到位并经常使用？
#### （8）平衡
* **质量是有代价的**：前面我谈到了质量和非功能性需求。如果您过度使用体系结构，则会增加成本并可能降低开发速度。您需要平衡架构和功能需求。应避免过度设计。
* **解决矛盾的目标**：矛盾的目标的一个典型示例是短期和长期目标。项目通常倾向于构建最简单的解决方案，而架构师则具有长远的眼光。通常，简单的解决方案不适合长期解决方案，并且有被以后抛弃的风险（降低成本）。为了避免实现错误的方向，需要考虑两点：
1. 开发人员和企业需要了解长期愿景及其收益，以适应其解决方案
2. 负责预算的经理需要参与以了解财务影响。不必直接将100％的远景图放置在适当的位置，但是发达的图块应该适合其中。
* **冲突管理**：架构师通常是具有不同背景的多个小组之间的粘合剂。这可能会导致不同级别的通信发生冲突。为了找到一个能够反映长期战略目标的平衡解决方案，通常架构师的作用就是帮助克服冲突。关于传播理论的起点是舒尔茨·冯·图恩的“四耳模型”。基于此模型，可以显示并推论很多。但是，该理论需要一些实践，在交流研讨会上应该有经验。
#### （9）咨询
在咨询和辅导方面，积极主动可能是您最好的选择。 如果询问您，通常为时已晚。 而您想要避免在项目现场上进行清理。 您需要以某种方式预见接下来的几周，几个月甚至几年的时间，并为下一步做好准备。
* **有远见**：如果您部署一个项目，无论是传统的瀑布式方法还是敏捷方法，您始终需要对要实现的中长期目标有一个远见。这不是一个详细的概念，而是一个通往每个人都可以工作的路线图。由于您无法一次完成所有工作（这是一段旅程），因此我更喜欢使用成熟度模型。它们给出了易于使用的清晰结构，并且每次都给出了当前的进度状态。对于不同的方面，我使用不同的模型，例如开发实践或持续交付。成熟度模型中的每个级别都有明确的要求，这些要求遵循SMART准则，以便轻松衡量是否已达到要求。我发现一个很好的例子是持续交付。
* **建立实践社区（CoP）**：在共同兴趣小组之间交流经验和知识有助于分发思想和标准化方法。例如，您可以每三个月左右将所有JavaScript开发人员和架构师聚集在一个房间中，讨论过去和当前的挑战以及如何解决它们或采用新的方法论和方法。架构师可以共享，讨论和调整其愿景，开发人员可以共享经验并向同行学习。这样的回合不仅可以为企业带来极大的好处，也可以为个人本身带来极大的好处，因为它有助于建立更强大的网络并传播思想。还可以查看SAFe框架中的文章实践社区，该文章在敏捷环境中解释了CoP概念。
* **进行公开会议**：误解或模棱两可的原因之一是缺乏沟通。阻止固定时间段，例如每周30分钟，用于与同行交流热门话题。本届会议没有任何议程可以讨论。尝试当场解决小事。安排对更复杂主题的后续行动。
#### （10）市场
您的想法很棒，您已经很好地传达了他们的想法，但仍然没人愿意遵循吗？那么您可能缺乏营销技巧。
* **激励并说服**：公司如何说服您购买产品？他们证明了它的价值和好处。但不仅仅是5点。他们包装得很好，并使其尽可能容易消化。
1. 原型：显示您的想法的原型。有很多用于创建原型的工具。对于喜欢SAP的企业，[请访问build.me](http://xn--build-6u8ohmj49d.me)，在其中您可以快速轻松地创建外观漂亮且可单击的UI5应用程序。
2. 使用视频：除了“无聊的幻灯片”，您还可以显示一个视频，该视频可以演示您的想法或至少是方向。但是请不要过度营销：从长远来看，内容为王。如果您的话不正确，从长远来看，这将损害您的声誉。
* **为您的想法而奋斗并坚持不懈**：人们有时不喜欢您的想法，或者他们懒得遵循。如果您真的对自己的想法深信不疑，则应不断追求并“奋斗”。有时这是必要的。具有长期目标的体系结构决策通常不是最容易的：开发人员不喜欢它们，因为它们的开发更加复杂。经理们不喜欢它们，因为它们在短期内更昂贵。这是您要坚持不懈并进行谈判的工作。
* **寻找盟友**：很难独自建立或执行您的想法，甚至是不可能的。尝试找到可以支持和说服他人的盟友。使用您的网络。如果还没有，请立即开始构建。您可以从与（思想开放的）同事讨论您的想法开始。如果他们喜欢它，或者至少喜欢它的一部分，那么如果别人提出来，他们很可能会支持您的想法（“ X的想法很有趣。”）。如果他们不喜欢，问为什么：也许您错过了什么？还是您的故事不够令人信服？下一步是找到具有决定权的盟友。要求开放的讨论。如果您担心讨论，请记住，有时您需要离开舒适区。
* **重复，相信它**：“ \[…]研究表明，反复接触某个观点会使人们相信该观点更为普遍，即使该观点仅来自一个人。”（来源：《金融品牌》）经常发布一些消息，这可以帮助说服人们。但请注意：从我的角度来看，应该明智地使用这种策略，因为它可能适得其反，成为糟糕的营销技巧。
### 6. 架构师技术路线图
### 7. 参考
1. [SoftwareArchitect](https://github.com/justinamiller/SoftwareArchitect)
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://trumandu.gitbook.io/java-architect-tutorial/xu-lun/cheng-wei-yi-ge-geng-hao-de-jia-gou-shi.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.