几乎所有 IT 公司或初创公司都需要一位专家来确定高级设计、使用的编程语言、工具和平台。这位专家被称为软件架构师。
软件架构师将优化开发流程并最终在每个业务战略中发挥重要作用。谁可以成为软件架构师？软件架构师应该具备哪些能力或技能？软件架构师在 IT 公司或初创企业中的职能和角色是什么？本文将彻底考察软件架构师的工作。
什么是软件架构师？
在更详细地讨论之前，让我们先看看这个定义。软件架构师是做出高级设计选择并确定技术标准（包括编码标准、工具和平台）的软件专家。软件架构专业知识的下一个级别称为首席架构师。 （来源：维基百科：软件架构师）
软件架构是系统的基础，由其组件、组件之间的关系以及与环境的关系以及决定系统设计和演化的原则来表示。 （来源：软件架构手册）
与大多数高级职位一样，没有明确的标准来表明这一职能。然而，软件架构师的职业生涯有一些特征、素质和职责范围，让我们注意以下软件架构师特征：
交际性
对于软件架构师来说，这个特征是绝对必须 电话号码库 的。这是因为他们每天都用业务语言与客户、各级经理、业务分析专家、开发人员进行对话。软件架构师的语言简洁、清晰、有说服力。此特性很重要的另一个原因是，由于软件架构师参与所有决策过程，因此通常必须做出妥协以使所有相关方受益。
广泛而深入的技术知识
这是显而易见的，因为没有强大的 IT 背景就不可能成为一名软件架构师。除此之外，软件架构师不仅必须对技术领域有很好的理解，而且还必须对业务等其他事物有很好的理解。软件架构师还必须能够准备文档、报告和图表。
责任重大
就该决定背后的风险而言，软件架构师的决定通常是最“昂贵”的。如果开发人员犯了一个错误，也只会损失他几天的工作时间。与此同时，如果软件架构师犯了错误，尤其是在复杂的项目中，损失可能会持续数年。
抗压力
这项工作充满了快速变化的需求、不同背景的利益相关者以及不同的商业文化。当问题发生时，软件架构师需要快速响应。因此，该区域具有较高的压力。当工作带来快乐时，它总是会更加令人愉快。所以，如果你只是为了钱而选择这个职位，那就再想一想了。
管理技能
这包括组织和领导技能。领导一支由不同背景的专家组成的团队的良好能力至关重要。
分析能力
最重要的任务之一是以系统对象的形式表示抽象问题的能力，可以对其进行评估、设计和开发。
软件架构师的主要职责
主要职责是从项目启动、产品发布到 适合您家的玄关桌 附加软件 开发的整个过程中提供技术支持。其他职责是：
确定项目利益相关者的业务需求；
根据收到的要求设计整个系统；
在高层选择系统架构和系统的各个组件；
选择每个组件的实现技术以及组件之间的连接；
架构审查；
代码审查；
编写项目和支持文档；
在公司内制定集成开发标准；和
在发布后系统的下一次迭代期间控制架构。
创建正确的架构来解决手头的问题只是软件架构师职责的一小部分。他们还必须：
对系统架构的控制；
控制时间和期限；
控制软件与系统架构的同步；
进行绩效质量控制；
为工具和环境选择提供必要的输入；
与管理层和利益相关者互动；
解决纠纷；
解决技术问题；
了解并规划进化路径；
如果需要的话规划新技术；和
管理与架构相关的风险识别和风险缓解策略。
因此，要成为一名软件架构师，您必须始终保持学习和改进的开放态度。了解多种技术堆栈是必须的：语言服务器、iOS、Android 等等。
你必须勤奋地阅读大量的专业文献，并找几位导师来请教问题。参加研讨会或课程。成为一名软件架构师并不容易，至少需要几年的时间。
软件架构师的类型
专业化在每个专业领域都是司空见惯的。例如，在医学领域，我们认识外科、心脏病学、眼科等领域的专家。例如，在管理领域，当该领域的知识量超过合理限度时，就需要专业化的资源经理、公关经理，甚至清洁经理。由于软件架构是一门广泛的知识，因此专门化以提高生产力非常重要。以下是软件架构师的划分类型：
系统架构师
最低的架构级别。专注于一个应用程序。低层次的设计，但非常详细。沟通通常只在一个开发团队内部进行。系统架构师的职责范围通常如下：
监督一个系统并在其中建立连接。
专注于开发的技术组件。
帮助项目经理做出管理决策。
拥有深入的技术知识。
解决方案架构师
建筑学中级水平。专注于满足业务需求的一个或多个应用程序（业务解决方案）。低层次设计到高层次。多个开发团队之间的沟通。解决方案架构师的职责范围通常如下：
参与业务讨论。
在多个系统之间创建连接。
提供多个团队之间的沟通。
设计系统之间的连接。
充当业务和技术需求之间的中介。
企业架构师
建筑的最高水平。专注于多种解决方案。高层抽象设计，需要由解决方案架构师或应用程序架构师详细说明。整个组织的沟通。企业架构师的职责范围通常如下：
负责公司内部的一切发展
使用所创建系统的高级抽象。
在整个公司范围内提供技术交流。
不涉及编码。
专注于业务组件。
拥有广泛的技术知识。
有时建筑师也被视为利益相关者之间沟通问题的“粘合剂”。举个例子：
横向：在业务和不同开发人员或开发团队之间架起沟通桥梁。
垂直：架起开发人员和管理者之间沟通的桥梁。
技术：将不同的技术或应用程序相互集成。
软件架构师必须具备的技能
为了支持软件架构师的复杂活动，需要特殊技能。以下是每个软件架构师必须具备的 10 项技能：设计、决策、简化、编码、文档、沟通、估计、平衡、咨询、市场。我们来一一讨论。
设计
什么才是好的设计？这也许是最重要的问题。让我们区分一下理论和实践。
理论
了解设计模式的基础知识：模式是架构师开发可维护系统所需的最重要的工具之一。借助模式，您可以通过经过验证的解决方案重用设计来解决常见问题。四人组 (GoF)撰写的《设计模式：可重用面向对象软件的元素》一书是参与软件开发领域的每个人的必读之作。尽管它们是 20 多年前发布的，但它们仍然构成了现代软件架构的基础。例如，本书中描述的模型-视图-控制器（MVC）模式应用于许多领域，或者是新模式（例如 MVVM）的基础。
深入研究模式和反模式：如果您已经了解所有基本的 GOF 模式，那么可以通过更多软件设计模式来扩展您的知识。或者更深入地挖掘您感兴趣的领域。阅读 Gregor Hohpe 撰写的《企业集成模式》一书。本书适用于两个应用程序需要交换数据的广泛领域，无论是某些遗留系统的老式文件交换还是现代微服务架构。
了解质量衡量标准：定义架构并不是最终目标。这就是定义、实施和控制指南和规范标准的原因。您这样做是因为质量和非功能要求。您希望拥有一个可维护、可靠、适应性强、安全、可测试、可扩展、可用等的系统。实现所有这些质量属性的方法是实施良好的工作架构。您可以开始在维基百科上了解有关质量衡量标准的更多信息。
理论很重要。如果你不想成为象牙塔建筑师，实践可能更重要
实践
尝试并了解不同的技术堆栈：如果您想成为更好的架构师，这是最重要的活动。尝试（新）技术堆栈并了解它们的优点和缺点。不同的技术有不同的设 计方面和模式。如果不亲自尝试并亲自体验其好处或优点，您很可能不会从只是翻阅幻灯片中学到任何东西。
建筑师不仅应该在多个领域拥有广泛而且深入的知识。不必掌握所有技术堆栈，但对您所在领域中最重要的技术堆栈有深入的了解。
分析和理解应用模式：查看当前框架趋势，例如 Angular。您可以在实践中学习许多模式，例如Observables。尝试了解它在框架中是如何实现的以及为什么这样做。如果您真的很专注，请更深入地研究代码并了解它是如何实现的。
始终保持好奇心并加入用户组：例如，在印度尼西亚，有 Java 用户组 (JUG)，其中讨论各种主题，从低级编码到高级架构主题。加入社区可以增强您的思维并扩大您的个人网络。
决定
架构师必须能够做出决策并指导项目或整个组织朝正确的方向发展。
知道什么更重要：不要把时间浪费在不重要的决定或活动上。只学习重要的事情。
确定优先级：始终考虑对您将做出的每个决定进行优先级排序。有多种方法可以做到这一点。看一下在敏捷软件开发中广泛使用的加权最短作业优先（WSJF）模型。尤其是时间紧迫性和风险降低对于估计架构决策的优先级非常重要。
了解你的能力：不要做出超出你能力范围的事情。这非常重要，因为如果您不小心，可能会严重损害您作为建筑师的地位。为了避免这种情况，请与您的朋友明确您的职责以及您工作的一部分。此外，始终与同事反复核对重要决策。
评估多种选择：在做出决定时，始终考虑不止一种选择。通过拥有多个选项，所有选项都可以根据事实进行比较，而不是直觉，例如许可费用或成熟度。这也使您在会议期间更容易说服利益相关者您的论点。
简化
记住奥卡姆剃刀问题解决的原则，强调简单化。如果你有太多的假设来解决问题，你可能会错或导致不必要的复杂解决方案。必须减少（简化）假设才能获得最佳解决方案。
逆向解决方案：要得到简单的解决方案，请逆向解决方案并从不同的角度看它。尝试通过自上而下然后自下而上的思考来创建解决方案。如果你有数据流或处理数据，那么首先从左到右思考，然后再从右到左尝试。提出这样的问题：“这个理想的解决方案发生了什么？”或者：“公司/X 将做什么？” （其中X可能不是你的竞争对手，而是GAFA公司之一）。正如奥卡姆剃刀所建议的那样，这两个问题都迫使您减少假设。
退后一步：经过激烈而漫长的讨论，结果通常是非常复杂的多页涂鸦。您永远不应该将其视为最终结果。退后一步：再次反思大局（抽象层面）。这还有道理吗？然后在抽象层面再做一遍，重构。有时，停止讨论并在第二天继续进行会有所帮助。至少大脑需要时间来处理并产生更好、更优雅、更简单的解决方案。
分而治之：通过将问题分成更小的部分来简化问题。然后分别完成。之后验证零件是否组装在一起。退一步看全貌。
重构：如果找不到更好的想法，请尝试更复杂的解决方案。如果解决方案最终会产生新的问题，您可以稍后回想并应用您所学到的知识。重构并不是一个坏主意。 \
但在此之前，请记住：（a）足够的自动化测试以确保系统的正确功能，以及（b）利益相关者的支持。要了解有关重构的更多信息，您可以阅读“重构”。改进现有代码的设计”作者：Martin Fowler。
代码
即使你是一个企业架构师，架构最抽象的一点，你也要知道开发人员每天在做什么。如果您不知道如何去做，您可能会面临两个主要问题：(a) 开发人员不会尊重您的考虑，(b) 您不了解开发人员的挑战和需求。
有一个副业项目：目标是尝试新技术和工具来了解当前状况和对未来的预测。经验是观察、情感和假设的组合（Kurt Schneider 的“软件工程中的经验和知识管理”）。
阅读教程或优缺点指南是一件好事。但这只是教科书上的知识，只有直接尝试，你才会体验到情感并能够建立假设。您的飞行时间越多，您的假设就越好。这也将帮助您在日常任务中做出更好的决策。
找到正确的尝试：你不可能尝试所有的事情。您需要一种更加结构化的方法。一项值得研究的资源是 ThoughtWorks 的技术雷达。他们将技术、工具、平台、语言和框架分为四类：采用、试用、评估和保留。
采用意味着“有信心准备好用于企业需求
尝试意味着“公司必须在一个能够克服风险的 afb 目录 项目中进行尝试”。评估的意思是“评估它将对公司产生的影响程度”。 Hold 的意思是“谨慎行事”。通过这种分类，可以更轻松地了解新内容以及他们是否准备好评估应该探索哪些趋势。
文件
架构文档可能重要也可能不重要。重要文档，例如架构决策或代码指南。在编码开始之前需要初始文档，并且需要持续改进。可以自动创建其他文档，因为代码也可以用作文档，例如 UML 类图。
干净的代码：如果做得正确，代码就是最好的文档。一个和坏代码。 Robert C. Martin 所著的《Clean Code》一书是了解更多关于好代码和坏代码的优秀资源。
尽可能生成文档：系统变化很快，并且很难更新文档。无论是 API 还是 CMDB 形式的系统环境：基本信息通常变化太快，无法保持文档最新。
尽可能多，尽可能少：大量的文档很难阅读和理解。附加信息应存储在附录中。特别是对于决策文件来说，讲述一个令人信服的叙述比仅仅抛出一堆论点更重要。
了解更多架构框架：这一点可以应用到所有其他技术点。 TOGAF 和 Zachmann 等框架提供的工具让人感觉文档很重，尽管它们的优势不仅仅限于文档。获得此类框架的认证可以教会您更系统地处理架构。
通讯
如果你在设计方面很出色，但无法传达你的想法，那么你就不太可能产生影响，甚至可能会失败。
了解如何传达您的想法：在手动媒体中演示时，您必须了解如何组织您的想法并将其直观地呈现给会议参与者。 “ UZMO – 用笔思考”一书是提高该领域技能的重要资源。作为一名架构师，您通常不仅要参加会议，还要提高会议的效率并主持会议。
保持透明：您需要使每个决定背后的原因变得透明。尤其是，如果人们不参与决策过程，就很难理解、遵守决策及其背后的原因。
估计和评估
了解项目管理的基本原则：不要忘记，这不仅仅是实施，还有很多活动需要考虑，例如需求工程、测试和修复错误。
如果您处于敏捷项目中，请学习如何正确估计和计划：Mike Cohn 的《敏捷估计和计划》一书提供了该领域的清晰概述。
评估“未知”架构：作为架构师，您还必须能够评估架构对于当前或未来环境的适用性。而且这不仅仅是架构的问题，还涉及系统如何管理的问题，因为它与质量密切相关。
平衡
有价格，有质量：您需要平衡架构要求和功能要求。应避免过度工程化。
冲突管理：软件架构师通常成为不同背景的多个群体之间的桥梁。不同的背景可能会引发冲突。从舒尔茨·冯·图恩的《四耳模型》一书中学习沟通理论，掌握冲突管理。
咨询和指导
有一个愿景：设定一个您想要实现的中长期愿景，无论您使用什么方法。由于您无法立即实现所有目标，因此成熟度模型是正确的使用方法。
该模型结构清晰，易于理解，并始终提供进度状态。对于不同的方面，使用不同的模型，例如开发实践或持续交付。成熟度模型中的每个级别都有遵循 SMART 标准的 要求，以使测量更容易。
建立实践社区 (CoP)：在具有共同兴趣的群体之间交流经验和知识有助于传播想法和标准化。例如，您可以在一个房间中为所有 JavaScript 开发人员和架构师聚集并打开一个讨论论坛。另请参阅SAFe 框架中的实践社区文章，其中解释了敏捷环境中 CoP 的概念。
举行公开会议：误解的根源之一是缺乏沟通。划出一个时间段，例如每周 30 分钟，与同事交流当前的话题。尝试当场解决小问题。为更复杂的主题安排未来的会议。
市场
您有一个绝妙的想法并成功地传达了它，但没有人愿意遵循？您可能缺乏营销技巧。
创建原型：展示您的想法的原型。有许多用于原型设计的工具。对于热爱 SAP 的公司，请查看 build.me，您可以在其中快速轻松地构建美观、可点击的 UI5 应用程序。
但请不要过度营销：从长远来看，内容为王。如果你的诺言没有兑现，从长远来看将会损害你的声誉。
重复，相信：研究表明，反复接触某种观点会让人们相信该观点更普遍，即使该观点的来源只有一个人。” （来源：金融品牌）
如果你经常发表你的想法，它可以帮助你更容易地说服人们。但请保持警惕，这种策略必须明智地使用，因为它可能会成为一种糟糕的营销伎俩，适得其反。
有兴趣成为一名软件架构师吗？
如果您在阅读本文后有兴趣成为一名软件架构师，或者突然想到尝试在这条道路上发展职业，请确保您确实想要它。
首先，人们往往害怕新事物。新的职位，新的压力，与已经舒适的现状背道而驰。当然，选择并不总是取决于您愿意在多大程度上改变生活中的某些事情。同时，它也可能取决于您的家庭、经济承诺、父母和其他因素。
其次，这个技能领域需要几年的时间。成为软件架构师的过程并不是一朝一夕就能完成的。然而，即使你没有明确的计划，最好开始采取一些小步骤来推动你前进，而不是停留在同一个地方。
在IT界站在同一个地方，就是个人人生停滞和束缚的代名词，看看下面的T型技能，说明专家如何纵向和横向发展。
软件架构师
建筑师的成长与他所拥有的理论尤其是实践专业知识的平台数量以及掌握的学科领域的数量密切相关。架构师职业发展的目标处于“M型”点——即多平台&多领域。
