网站架构师的工作内容( 你是如何成为一名软件架构师的的师？|Miller )

　　网站架构师的工作内容(

你是如何成为一名软件架构师的的师？|Miller

)

　　作者 | 贾斯汀·米勒

　　翻译 | 洪文

　　编辑 | 席燕

　　出品 | CSDN（ID：CSDNnews）

　　几年前，有人问我，“你是如何成为一名软件架构师的？” 我们讨论了建立知识所需的必要技能、经验以及时间和投资。此外，我详细介绍了我所采取的步骤、我积极使用或尝试过的技术，以及我在专业和非专业方面学到了什么。

　　什么是软件架构师？

　　在深入了解细节之前，让我们看一下两个定义。

　　软件架构师是软件专家，他们做出高级设计选择并指定技术标准，包括软件编码标准、工具和平台。

　　首席专家称为首席架构师。（来源：维基百科：软件架构师）

　　软件架构是系统的基本组织，由其组件、组件之间的关系及其与环境的关系以及确定系统设计和开发的原则来表示。（来源：软件架构手册）

　　架构级别

　　架构可以在几个抽象“级别”上完成。此级别影响必要技能的重要性。有很多可能的分类，我最喜欢的细分包括这三个级别：

　　应用程序级别：最低的架构级别。专注于单一应用程序。非常详细的低级设计，通常在开发团队内部进行沟通。解决方案级别：中间架构级别。专注于满足业务需求的一个或多个应用程序（业务解决方案）。有些是高级设计，但大多是低级设计。多个开发团队之间的沟通。企业级：最高架构级别。专注于多种解决方案。需要解决方案或应用程序架构师详细说明的高级抽象设计。跨组织的沟通。有关详细信息，请参阅链接 ()。

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

　　水平：业务与开发人员或不同开发团队之间的沟通桥梁。

　　垂直：开发人员和管理人员之间的沟通桥梁。

　　技术：将不同的技术或应用相互集成。

　　软件架构师的典型活动

　　为了了解架构师所需的必备技能，我们首先需要了解他们的典型活动。在我看来，以下（非最终）活动是最重要的：

　　请注意：架构是一项持续的活动，尤其是当它应用于敏捷软件开发时。因此，重复这些活动。

　　软件架构师的重要技能

　　需要特定技能来支持预定的活动。根据我的经验、阅读书籍和讨论，我们可以将其归结为每个软件架构师应该具备的以下 10 项技能：设计、决策、简化、代码、文档、沟通、评估、平衡、咨询、营销。

　　让我们一一解释。对于每项技能，我建议采取一些行动或洞察力以进行后续改进。

　　(1）设计

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

　　了解基本设计模式：模式是架构师开发可维护系统所需的最重要工具之一。使用模式，您可以重用设计以通过可靠的解决方案解决常见问题。《设计模式：可重用的面向对象软件的元素》四人组 (GoF) 是任何从事软件开发工作的人的必读之书。尽管这些模式已经发布了 20 多年，但它们仍然是现代软件架构的基础。例如，本书描述了模型-视图-控制器 (MVC) 模式，该模式已在许多领域中使用，或者是 MVVM 等较新模式的基础。深入研究模式和反模式：如果您已经了解所有基本的 GoF 模式，您可以通过更多的软件设计模式扩展您的知识，或者更深入地挖掘您感兴趣的领域。我最喜欢的应用程序集成书籍之一是 Gregor Hohpe 的“企业集成模式”。每当两个应用程序需要交换数据时，无论是来自某些遗留系统的老式文件交换还是现代微服务架构，本书都适用于各个领域。了解质量指标：定义架构并不是终点。它解释了为什么要定义、应用和控制指南和编码标准。这样做是因为质量和非功能性要求。您需要一个可维护、可靠、适应性强、安全、可测试、可扩展、可用的系统。实现所有这些质量属性的一种方法是应用良好的架构工作。您可以在 Wikipedia 上了解有关质量测量的更多信息。理论很重要。如果你不想成为象牙塔建筑师，

　　尝试并理解不同的技术栈：如果你想成为一名更好的架构师，我认为这是最重要的活动。尝试（新）技术堆栈，看看它们是如何兴衰的。不同的或新技术具有不同的设计领域和模式。很可能你不会从仅仅翻阅抽象幻灯片中学到任何东西，而是自己尝试一下。架构师不仅应具有广泛的知识，还应在某些领域具有深厚的知识。掌握所有技术并不重要，重要的是对您所在领域中最重要的技术有扎实的了解。还可以尝试一些你不熟悉的技术，例如，如果你对 SAP R/3 有深入的了解，你应该尝试 JavaScript，反之亦然。尽管如此，双方都会对 SAP S/4 Hana 的最新发展感到惊讶。例如，您可以自己尝试并免费参加 openSAP 课程。保持好奇心并尝试新事物。也试试几年前你不喜欢的东西。

　　分析和理解应用程序模式：查看当前的任意框架，例如 Angular。您可以在实践中学习很多模式，例如可观察模式。尝试了解它是如何在框架中应用的以及为什么。如果您是真正的专业人士，请深入研究代码并查看它是如何实现的。

　　保持好奇心并密切关注用户群。

　　(2）决定

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

　　知道什么是重要的：不要把时间浪费在不重要的决定或活动上。了解重要的事情。据我所知，没有一本书收录此信息（如果有，请告诉我）。我个人最喜欢的是这两个特征，我在评估重要事物时通常会考虑这一点： 1）概念完整性：如果您决定以一种方式做事，请坚持下去，即使有时以不同的方式做事会更好。通常，这会导致更简单的整体概念，更易于理解和维护。2）一致性：例如，如果您定义并应用命名约定，则与大小写无关，而是在任何地方都以相同的方式应用它。优先级：有些决定很关键。不及早采取足够的解决方案可能会产生以后不太可能消除的问题，维护的噩梦，或者更糟糕的是，开发人员在做出决定之前就停止工作。在这种情况下，做出一个“糟糕”的决定比根本没有决定要好。但在此之前，请考虑优先考虑您即将做出的决定。有不同的方法可以做到这一点。我建议首先查看在敏捷软件开发中广泛使用的加权最短作业 (WSJF) 模型。特别是，时间紧迫性和风险降低的度量是确定架构决策优先级的关键。了解你的能力：不要决定不在你能力范围内的事情。这一点很关键，因为如果不加以考虑，它会严重损害您作为建筑师的地位。为避免这种情况，您应该与同事明确您的职责和角色。如果有不止一位建筑师，那么您应该尊重当前部署的架构级别。作为较低级别的架构师，您最好为较高级别的架构提出建议，而不是做出决策。此外，我建议经常与同事一起审查关键决策。评估多个选项：如果要做出决定，请始终列出多个选项。在我参与的大多数情况下，有不止一个（好的）选择。只有一个选择是不好的，有两个方面：1）看来你的工作做得不好；2）它妨碍了做出正确的决定。通过定义指标，可以根据事实而不是直觉（例如许可成本或成熟度）来比较选项。这通常会导致更好和更可持续的决策。此外，决策可以轻松地出售给不同的利益相关者。还，如果选项没有正确评估，讨论中可能会遗漏参数。(3） 简化

　　请记住解决问题的奥卡姆剃刀原则，即偏好简单。我将此原则解释为：如果您对要解决的问题有太多假设，则可能会出错或导致不必要的复杂解决方案。为了得到一个好的解决方案，应该减少（简化）假设。

　　检查解决方案：为了简化解决方案，通常需要“摇动”解决方案，从不同位置查看它们。尝试通过自上而下和自下而上的思考来形成解决方案。如果您有数据流或流程，请先考虑从左到右，然后再考虑从右到左。问这样的问题：“在理想的环境中，您的解决方案将如何变化？” 或者：“公司/个人 X 会做什么？” （X 可能不是你的竞争对手，而是一个。）这两个问题都迫使你减少奥卡姆剃刀所建议的假设。退后一步：经过激烈而冗长的讨论，结果往往是高度复杂的涂鸦。您永远不应该将这些视为最终结果。退后一步：再次查看全局（抽象级别）。这还有意义吗？然后在抽象级别再次重构。有时它有助于停止讨论并在第二天继续讨论。至少我的大脑需要一些时间来处理并想出更好、更优雅、更简单的解决方案。分而治之：通过将问题分成更小的部分来简化问题。然后独立解决。然后验证块是否匹配。退后一步，看看大局。重构并不是一件坏事：如果找不到更好的解决方案，从更复杂的解决方案开始是完全可以的。如果您在解决方案上遇到问题，您可以稍后重新考虑解决方案并应用您的学习。重构并不是一件坏事。但是在开始重构之前，请记住（1) 有足够的自动化测试来确保系统的正常功能；要了解有关重构的更多信息，我建议阅读 Martin Fowler' 的书重构。改进现有代码的设计”。（4）代码

　　即使作为企业架构师（最抽象的架构级别），您仍然应该了解开发人员在日常工作中所做的事情。如果您不了解这是如何完成的，您可能会面临两个主要问题：

　　1）开发者不会接受您的索赔。

　　2）您不了解开发人员的挑战和需求。

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

　　找到合适的尝试：你不能尝试所有事情。这根本不可能。您需要一种更有条理的方法。我最近发现的一个是来自 ThoughtWorks 的技术雷达。他们将技术、工具、平台、语言和框架分为四类：采用、试用、评估和保留。Adopt 意味着“完全准备好供企业使用”，“trial”意味着“企业应该在可以处理风险的项目中进行尝试”，“evaluate”意味着“研究它如何影响您的业务”，“retain”意味着“处理警告”。通过这种分类，可以更轻松地了解新内容及其准备情况，以便更好地评估接下来要探索的趋势。

　　(5）文档

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

　　干净的代码：如果做得好，代码是最好的文档。一个好的架构师应该能够区分好代码和坏代码。Robert C. Martin 所著的“清洁代码”一书是学习更多关于好代码和坏代码的宝贵资源。

　　尽可能生成文档：系统日新月异，更新文档可能很困难。无论是 API 还是 CMDB 形式的系统环境：底层信息经常变化太快，无法手动更新相应的文档。例如：对于 API，如果你是模型驱动的，你可以从定义文件中自动生成文档，或者直接从源代码生成文档。有很多工具可以帮助你，我认为 Swagger 和 RAML 是一个很好的学习起点。

　　如果没有必要，尽可能少：无论您需要记录什么文档（例如决策文档），尝试一次只关注一件事，并且只收录关于该事物的必要信息。大量的文档很难阅读和理解。附加信息应存储在附录中。特别是对于决策文件，讲一个有说服力的故事比仅仅发表大量论据更重要。此外，这可以为您和您的同事节省大量时间，因为他们必须阅读它。查看您过去完成的一些文档（源代码、模型、决策文件等）并问自己以下问题：“是否收录所有必要的信息才能理解它？”、“哪些信息真的需要是的，哪些可以省略？” 和 ”

　　了解有关架构框架的更多信息：这也适用于所有其他“技术”方面。我把它放在这里是因为像 TOGAF 或 Zachmann 这样的框架提供了在文档站点上很重要的“工具”，尽管它们的附加价值不仅限于文档。在这样的框架中获得认证将教会你更系统地处理架构。

　　(6）通讯

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

　　了解如何传达您的想法：当您在白板或活动挂图上进行协作时，重要的是要知道如何正确使用它来组织您和您同事的想法。我发现“UZMO - Thinking With Your Pen”一书是提高我在这方面技能的绝佳资源。作为架构师，你经常不仅需要参加会议，还要推动和协调会议。向大型团队展示：向小型或大型团队展示您的想法应该是可行的。如果您对此感到不舒服，请开始向您最好的朋友展示它。慢慢扩大群体。这是你只能通过做和离开你的个人舒适区来学习的东西。对自己要有耐心，这个过程可能需要一些时间。找到合适的沟通水平：不同的利益相关者有不同的利益和观点。他们需要在他们的级别上单独处理。在交流之前，先退后一步，检查一下你要分享的信息在抽象、内容、目的、动机等方面是否正确。例如：开发人员通常对解决方案的几个细节感兴趣，而管理人员则对解决方案感兴趣。更感兴趣的是知道哪种选择最具成本效益。经常沟通：如果没有人知道，一个伟大的架构是毫无价值的。目标架构及其背后的想法会定期在每个（组织）级别发布。安排与开发人员、架构师和经理的会议，向他们展示所需或定义的方法。保持透明：定期沟通只能部分缓解缺乏透明度。他们需要在他们的级别上单独处理。在交流之前，先退后一步，检查一下你要分享的信息在抽象、内容、目的、动机等方面是否正确。例如：开发人员通常对解决方案的几个细节感兴趣，而管理人员则对解决方案感兴趣。更感兴趣的是知道哪种选择最具成本效益。经常沟通：如果没有人知道，一个伟大的架构是毫无价值的。目标架构及其背后的想法会定期在每个（组织）级别发布。安排与开发人员、架构师和经理的会议，向他们展示所需或定义的方法。保持透明：定期沟通只能部分缓解缺乏透明度。他们需要在他们的级别上单独处理。在交流之前，先退后一步，检查一下你要分享的信息在抽象、内容、目的、动机等方面是否正确。例如：开发人员通常对解决方案的几个细节感兴趣，而管理人员则对解决方案感兴趣。更感兴趣的是知道哪种选择最具成本效益。经常沟通：如果没有人知道，一个伟大的架构是毫无价值的。目标架构及其背后的想法会定期在每个（组织）级别发布。安排与开发人员、架构师和经理的会议，向他们展示所需或定义的方法。保持透明：定期沟通只能部分缓解缺乏透明度。退后一步，检查您要分享的信息在抽象、内容、目的、动机等方面是否正确。例如：开发人员通常对解决方案的少数细节感兴趣，而管理者更感兴趣的是了解哪个选项最具成本效益。经常沟通：如果没有人知道，一个伟大的架构是毫无价值的。目标架构及其背后的想法会定期在每个（组织）级别发布。安排与开发人员、架构师和经理的会议，向他们展示所需或定义的方法。保持透明：定期沟通只能部分缓解缺乏透明度。退后一步，检查您要分享的信息在抽象、内容、目的、动机等方面是否正确。例如：开发人员通常对解决方案的少数细节感兴趣，而管理者更感兴趣的是了解哪个选项最具成本效益。经常沟通：如果没有人知道，一个伟大的架构是毫无价值的。目标架构及其背后的想法会定期在每个（组织）级别发布。安排与开发人员、架构师和经理的会议，向他们展示所需或定义的方法。保持透明：定期沟通只能部分缓解缺乏透明度。开发人员通常对解决方案的少数细节感兴趣，而管理人员更感兴趣的是知道哪个选项最具成本效益。经常沟通：如果没有人知道，一个伟大的架构是毫无价值的。目标架构及其背后的想法会定期在每个（组织）级别发布。安排与开发人员、架构师和经理的会议，向他们展示所需或定义的方法。保持透明：定期沟通只能部分缓解缺乏透明度。开发人员通常对解决方案的少数细节感兴趣，而管理人员更感兴趣的是知道哪个选项最具成本效益。经常沟通：如果没有人知道，一个伟大的架构是毫无价值的。目标架构及其背后的想法会定期在每个（组织）级别发布。安排与开发人员、架构师和经理的会议，向他们展示所需或定义的方法。保持透明：定期沟通只能部分缓解缺乏透明度。安排与开发人员、架构师和经理的会议，向他们展示所需或定义的方法。保持透明：定期沟通只能部分缓解缺乏透明度。安排与开发人员、架构师和经理的会议，向他们展示所需或定义的方法。保持透明：定期沟通只能部分缓解缺乏透明度。

　　您需要对决定背后的理由保持透明。特别是，如果人们不参与决策过程，就很难理解和遵循决策及其背后的理由。准备好说话：总会有问题，你想马上给出正确的答案。尝试将最重要的幻灯片放在一起，以便展示和解释。它可以为您节省大量时间，并给您一种安全感。（7）评估了解基本的项目管理原则：作为架构师或首席开发人员，您经常被要求评估实施您的想法：多长时间，多少人，多少技能等？当然，如果您计划引入一个新的工具或框架，你需要对这些“管理”问题有一个答案。最初，您应该能够粗略估计多少天、几个月或几年。不要忘记这不仅仅是关于实现，还有更多的活动需要考虑，例如需求工程、测试和错误修复。因此，您应该了解所使用的软件开发过程的活动。您可以应用以获得更好的估计的一件事是使用过去的数据并从中得出您的预测。如果你没有过去的数据，你也可以试试 Barry W. Boehm 的 COCOMO 方法。如果您部署在敏捷项目中，请学习如何正确评估和计划：Mike Cohn 的《敏捷估计和计划》一书提供了该领域的可靠概述。评估“未知”架构：作为架构师，您还应该能够评估架构对当前或未来环境的适用性。这不是一件容易的事，但是您可以通过手头的一组对每个架构都通用的问题来做好准备。这不仅与架构有关，还与系统的管理方式有关，因为这也为您提供了有关质量的内部信息。I 建议随时准备好一些问题。一般问题的一些想法：

　　1）设计实践：架构遵循什么模式？结果它们被正确使用了吗？设计是否遵循红线或失控？是否有清晰的结构和关注点分离？

　　2）开发实践：是否制定并遵循了代码指南？代码是如何版本化的？部署实践？

　　3）质量保证：测试自动化覆盖率？静态代码分析是否到位且结果良好？同行评审是否到位？

　　4）安全：哪些安全概念是合适的？内置安全性？渗透测试或自动化安全分析工具是否到位并定期使用？

　　(8）余额

　　质量是有代价的：我之前讨论了质量和非功能性需求。如果过度使用模式，则会增加成本并可能减慢开发速度。您需要平衡架构和功能需求。应避免过度设计。

　　解决冲突目标：冲突目标的典型例子是短期和长期目标。项目倾向于构建最简单的解决方案，而架构师则考虑长期愿景。通常，简单的解决方案不适合长期解决方案，并且有可能在以后被丢弃（沉没成本）。为避免执行方向错误，需要考虑两件事：

　　1）开发人员和企业需要了解长期愿景及其好处以适应他们的解决方案

　　2）需要让负责预算的经理参与进来，以了解财务影响。它不必是 100% 的长期愿景，但开发部分应该适合它。

　　冲突管理：架构师通常是具有不同背景的多个团队之间的粘合剂。这可能导致不同级别的沟通冲突。为了在反映长期战略目标的同时找到平衡的解决方案，架构师的角色往往是帮助克服冲突。关于传播理论，我的出发点是 Schultz von Thun 的“四耳模型”。很多东西都可以根据这个模型来展示和推断。但是，这个理论需要一定的实践，在交流讨论中应该有所体会。(9）咨询

　　在咨询和指导方面，积极主动可能是您最好的选择。如果有人问你，通常为时已晚。清理架构网站 是您要避免的事情。您需要以某种方式预见未来数周、数月甚至数年的时间，以便为您和您的公司做好准备，迎接未来。

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

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

　　动机和说服力：公司如何说服你购买产品？他们展示了它的价值和好处。但不仅仅是五个要点。它们包装得很好，使其尽可能容易消化。

　　1）原型：展示你想法的原型。有许多用于创建原型的工具。热爱 SAP 的企业，请访问 build.me，在这里您可以快速轻松地创建美观且可点击的 UI5 应用程序。

　　2）显示视频：您还可以显示视频来代替“无聊的幻灯片”来展示您的想法或至少是方向。但请不要过度营销：从长远来看，内容为王。如果你不遵守你所说的话，从长远来看，它可能会损害你的声誉。

　　为你的想法而奋斗并坚持下去：人们有时不喜欢你的想法，或者他们懒得去追随他们。如果你真的相信你的想法，你就应该继续追求和“战斗”。有时这是必要的。具有长期目标的架构决策通常不是最简单的：开发人员不喜欢它们，因为它们的开发更复杂。经理们不喜欢它们，因为它们在短期内更贵。这是你坚持和谈判的工作。寻找盟友：​​建立或实施自己的想法可能很困难，如果不是不可能的话。尝试寻找可以支持和帮助说服他人的盟友。使用您的网络。如果您还没有，请立即开始构建它。您可以从与同事讨论您的想法开始（思想开放）。如果他们喜欢你的想法，或者至少部分喜欢，当被问到时，他们可能会支持你的想法（“X 的想法很有趣”）。如果他们不喜欢，问为什么：也许你错过了什么？还是你的故事不够有说服力？下一步是寻找有决定权的盟友。要求进行公开讨论。如果您害怕讨论，请记住有时您需要走出舒适区。

　　重复，相信它：“[...] 研究表明，反复接触一种观点会让人们相信这种观点更普遍，即使它只是来自一个人。” （来源：金融品牌） 经常重复的信息，可以帮助说服人们。但请注意：从我的角度来看，应该明智地使用这种策略，因为它可能适得其反并成为一种糟糕的营销技巧。

　　架构师技术路线图

　　原文链接：;isappinstalled=0