如何成为更好的软件架构师？这篇3.8K的明星文章值得一读。

< p >几年前，有人问我，“你是怎么成为软件架构师的？”我们讨论了保留相关知识所需的必要技能、经验以及时间和精力此外，我还回顾了我走过的路，我使用或尝试过的技术，以及我从各种工作中学到的东西。

< p >架构师技术路线图

什么是软件架构师？

在深入讨论之前，让我们先看看两个定义:

吧。 软件架构师是做出高级设计决策并确定技术标准(包括软件编程标准、工具和平台)的软件专家他们中的主要专家是总建筑师。(来源:维基百科:软件架构师) 软件架构是系统的基本组织。这个组织主要体现在它的组件、组件之间的关系、组件和环境之间的关系以及决定系统设计和演化的原则上。(来源:维基百科:软件架构) 建筑的“等级”

框架可以抽象成以下“层次”不同的水平需要不同的技能。虽然有许多标准来划分等级，但我喜欢将架构分为三个等级:

级 应用层:最低层架构只关注一个应用程序级别很低，但非常详细。这方面的沟通通常是在开发团队中进行的。 解决方案级别:体系结构的中间层专注于满足业务需求的一个或多个应用程序(即业务解决方案)这些设计中有些是高水平的，但大多数是低水平的。这种层级式沟通开始涉及多个团队； 企业级:体系结构的顶级关注多个场景该体系结构的设计水平高且抽象，因此它还需要由架构师在方案层和应用程序层进行细化。这种层级要求多个组织进行沟通如果你想知道更多，请参考这个链接:https://github.com/justinamiller/EnterpriseArchitecture

有时，建筑师也被视为不同工作组之间的粘合剂这里有三个例子:

横向:沟通业务部门和开发人员或不同开发团队之间的沟通； 纵向:管理者和开发者之间的桥梁； 技术:不同技术或应用的集成软件架构师的日常工作

要理解建筑师的必要技能，我们必须首先知道建筑师主要做什么。我认为建筑师最重要的活动包括:

定义和确定所需的开发技术和平台； 定义开发标准，如编程标准、工具、审计程序、测试方法等。； 支持识别和理解业务需求； 根据需求设计系统并做出决策； 关于建筑定义、设计和决策的讨论记录； 检查并检查架构和代码，例如，检查之前确定的模式和编程标准是否正确实施； 与其他部门和建筑师合作； 对开发商的指导和咨询； 细化高级设计，并将其转化为低级设计。

注意:架构设计是一项持续的工作，尤其是在敏捷软件开发过程中因此，我们将一遍又一遍地重复这项工作。

软件架构师的基本技能

为了完成上述工作，建筑师需要具备一些特定的技能。根据我的个人经验、相关书籍和讨论，我们可以将它们归纳为以下10项技能:设计、决策、简化、编程、记录、沟通、评估、平衡、咨询和营销

接下来，我将逐一介绍这些技能。

设计

首先，也是最重要和最难回答的问题是“什么是好的设计？”我将从理论和实践两方面进行阐述。就我的经验而言，两者都是最好的。让我们先谈谈理论水平:

理解基本的设计模式:模式是架构师开发可维护系统所需的最重要的工具之一。基于这些模型，您可以用相同的模型将一些处理过其他问题的程序迁移到新的问题上。“设计模式:可重用面向对象软件的元素”是所有从事软件开发的人必须的。尽管这些模型是在20多年前发布的，但它们仍然是现代软件架构的基础。例如，书中的模型-视图-控制器(MVC)模式已经被应用于许多领域，并且它也是一些新模式的基础(例如MVVM)。 深入挖掘并研究模式和反模式:如果你对g of编写的模式有一个全面的理解，你可以学习更多的软件设计模式或者深入挖掘你感兴趣的领域。在应用集成领域，我最喜欢的书之一是Gregor Hohpe写的企业集成模型。当两个应用程序需要交换数据时，无论是来自一些遗留系统的老式文件交换还是现代微服务架构，本书的内容都是适用的。 理解质量度量:定义体系结构是不完整的，但也解释了为什么定义、应用和控制这些指南和编程标准。这是因为需要质量控制来满足一些非功能性要求。我们想要的是一个可维护、可靠、可适应、安全、可测试、可扩展和可用的系统。实现所有这些需求的方法是拥有一个好的架构设计方法。你可以在维基百科上了解更多关于质量测量的信息。理论非常重要，但如果你不想成为一名生活在象牙塔里的建筑师，实践同样重要，甚至更重要。 尝试理解不同的技术堆栈:我认为这是你成为更好的架构师的最重要的一步。尝试新的技术堆栈并了解其开发过程这些不同的技术有不同的设计概念和模式。只有浏览PPT不能学到很多东西，你需要自己尝试感受这项技术的快乐和悲伤。建筑师不仅要有广博的知识，还要在某些领域有深厚的积累。关键不在于掌握所有的技术，而在于对你所在领域最重要的技术有一个坚实的理解。你也可以在野外尝试一些技术。例如，如果你对SAP R/3有很深的理解，你应该尝试JavaScript，反之亦然。然而，双方都将对SAP S/4 Hana的最新进展感到惊讶例如，您可以尝试免费学习openSAP课程。保持好奇心，尝试新事物。你也可以尝试几年前你不喜欢的东西。 分析和理解应用模式:查看任何当前框架(例如角度)你可以在实践中学习许多模式(比如可观察的)，你也应该试着理解它是如何在框架中应用的，以及为什么要这样做。如果你是一个真正的专业人士，你需要更深入地学习代码，并理解它是如何实现的。 保持好奇心，关注用户群。

第

号决定

架构师需要做出决策来引导项目甚至整个公司朝着正确的方向发展。

区分轻重缓急:不要把时间浪费在不重要的决定和工作上；学会分清轻重缓急。就我个人而言，我更喜欢通过以下两个特征来判断一个事件是否重要: 概念上的完整性:如果你一开始就决定了一个想法，坚持下去，即使有时使用不同的方法更好。这样，整体概念将越来越清晰，可理解性将得到提高，维护过程将得到简化。一致性:例如，如果您定义并应用一个命名约定，它不是关于大写或小写，而是以相同的方式应用于任何地方。优先级:有些决定非常关键。如果不及早采取适当的解决办法，将来无法解决的问题很可能会产生。这对于维护人员来说是一场噩梦，或者更糟糕的是，开发人员在做出这个决定之前无法继续工作。在这种情况下，先做一个“糟糕”的决定比什么都不做更好。但是在这发生之前，你需要知道哪些决定应该被优先考虑。有许多方法可以做到这一点我建议先看看加权最短分配优先(WSJF)模型，它在敏捷软件开发中被广泛使用。尤其是时间关键度和风险降低，其度量是评估架构决策优先级的关键。 认识你的能力:不要对超出你能力的事情做决定这很重要，因为如果不考虑，它可能会严重损害你作为建筑师的地位。为了避免这种情况，你应该向你的同事阐明你的职责和角色。如果有不止一个架构师，那么您应该只负责当前负责的架构层次。作为一个较低层次的架构师，您应该为更高层次的架构提出建议，而不是做出决策。此外，我建议你经常和同事一起检查重要的决定。 评估多个选项:在做决定时总是列出多个选项在我参与的大多数案例中，有不止一个可能的(极好的)选择。错误的选择有两个主要特征:(1)你似乎没有很好地完成工作；(2)阻碍做出正确的决定定义度量标准后，您可以根据事实(如许可成本或成熟度)而不是直觉来比较选项。这通常会让你做出更好、更可持续的决定。此外，将决策扩展到其他部门会更容易。但是如果你没有正确的评估选项，你可能会在最后的讨论中失去一个重要的论点。

简化版

永远记住奥卡姆剃刀原则，即简单就是正义我对这个原则的理解如下:如果你的解决方案是在许多假设的基础上提出的，那么你的解决方案很可能是错误的或极其复杂的。此时，您应该减少(简化)一些假设，以获得更好的解决方案。

多角度观察解决方案:为了简化解决方案，您经常需要调整解决方案的观察角度。例如，您可以尝试通过自上而下和自下而上的思维来获得解决方案。如果您有一个数据流或流程，首先考虑从左到右，然后考虑从右到左。在简化的过程中，问问你自己，“在一个完美的世界里，你需要对你的解决方案做任何修改吗？”或者“公司/某人会怎么做?”?ゥ这两个问题可以帮助你根据奥卡姆剃刀原理简化你的假设。 退一步说:经过紧张而漫长的讨论，你通常会得到一些极其复杂的计划。永远不要把它们当成最终结果。“后退一步”意味着:从宏观角度重新审视问题。目前的计划还有意义吗？然后在抽象层次上重构该方案。有时候，暂停讨论并在第二天继续是个不错的选择。至少对我来说，我的大脑需要一些时间来处理信息，并想出更好、更优雅、更简单的解决方案。 分而治之:将大问题分解成小问题，然后分别解决小问题，并验证这些小方案是否匹配最后，退一步看整体情况。