您是软件架构师吗？

本文摘自2019年英文博客您是软件架构师吗？.

由于翻译水平有限，因此本文中存在一些遗漏或错误. 如有疑问，请参阅原始文本.

以下是翻译.

在软件开发（软件开发）和软件体系结构（软件体系结构）之间有一条微妙的界限. 有人会说这条线根本不存在，架构只是开发人员设计过程的延伸. 其他人则表示，这是一个巨大的鸿沟，只有少数杰出的开发人员可以克服. 这些开发人员认为，您必须不断抽象（总是抽象）抽象，并避免陷入混乱之中. 意识到生活无聊的细节的泥潭. 如果您从务实的角度看待这两者，那么必须在两者之间取得平衡，但这又引发了一个问题: 您如何从开发人员转变为建筑师？

将软件体系结构与软件设计与开发区分开的关键因素包括: 规模的增长，抽象级别的增长以及做出正确的设计决策的影响的增长. 软件体系结构是要具有整体视图和全局视图，以了解软件系统整体的工作原理. 这些因素可能有助于区分软件开发和软件体系结构，但它们仍无法解释某些人如何从开发转向体系结构. 此外，确定谁将成为优秀的建筑师，如果您是HR会如何找到这些人以及您是否是建筑师也无济于事.

经验是一个很好的衡量标准，但您需要更深入地研究.

没有人在一夜之间或晋升后成为软件架构师. 架构师是角色，而不是职级. 这是一个不断发展的过程，您将在其中不断发展担任这一角色所需的经验和信心.

建筑师具有许多不同的素质，他们过去的经验通常可以很好地衡量他们承担这一角色的能力. 架构师的角色包括很多方面，因此您需要更深入地了解他们的参与，影响力，领导力和不同方面的责任.

从广义上讲，大多数项目的软件体系结构过程可以分为两个阶段: 先定义体系结构，然后交付体系结构.

定义体系结构的过程似乎非常简单: 确定需求，然后设计满足这些需求的系统. 但是实际上，这并不是那么简单. 由于您的参与度和对角色的重视程度不同，因此软件体系结构的角色也会发生很大变化. 如下图所示，体系结构定义部分的作用可以进一步细分为几个子部分.

软件项目通常专注于用户的功能需求（功能）软件架构师，很少询问用户他们有什么非功能需求（或系统性能）. 有时需求方会告诉我们“系统必须足够快”，但是这种说法过于主观. 为了满足非功能性需求，这些需求必须是特定的，可测量的，可实现的和可测试的.

大多数非功能性需求本质上是技术性的，通常会对软件体系结构产生重大影响. 了解非功能性需求是架构师角色的核心能力之一. 但是，尝试理解这些要求与质疑它们是否合理之间是有区别的. 毕竟，您看到多少系统真正需要7x24小时的运行时间？

在澄清了非功能性需求之后，下一步就是考虑如何定义体系结构并解决需求方提出的问题. 我们可以说每个软件系统都有一个体系结构，但是并不是每个软件系统都有一个定义的体系结构. 这是关键点.

软件定义过程需要考虑在给定约束下如何满足建议的要求，然后解决问题. 体系结构定义过程是在项目的技术方面引入结构，规范，原则和领导力的过程. 定义体系结构是您作为软件架构师的工作，但是从头开始设计软件系统和扩展现有系统却大不相同.

技术选择通常是一个令人愉快的过程软件架构师，但是在考虑诸如成本，许可，供应商关系，技术战略，兼容性，互操作性，支持，部署，升级策略，最终用户环境等问题时，挑战也是大. 综合考虑，这些因素通常会使选择某些东西（例如功能丰富的客户端）的简单任务变成一场噩梦.

下一个问题是这些技术是否会起作用.

技术选择全都与风险管理有关；降低高复杂性或不确定性区域中的风险，并允许将风险引入可能带来收益的区域. 技术决策需要考虑所有因素，并需要进行审查和评估. 这包括软件项目的主要构建块，以及开发过程中使用的库和框架. 如果要定义体系结构，则需要确保技术选择正确. 同样，评估新系统的技术与将技术添加到现有系统中非常不同.

如果您设计软件，则需要问自己: 我的体系结构可以工作吗？

对我来说，即使是以下架构也可以工作: 满足非功能性要求；为其余代码提供必要的基础；并解决潜在的业务问题提供了一个平台.

软件的最大问题之一是软件的复杂性和抽象性，这使得很难从UML图或代码中可视化软件的运行时特征. 在软件开发过程中，我们将使用各种测试技术来确保交付的系统上线后可以正常工作. 为什么不对建筑设计使用相同的方法？如果您可以测试您的体系结构，那么您可以证明它有效. 这项工作越早完成，就可以在不仅仅期望其正常运行的情况下降低项目失败的风险.

隔离的软件系统很少见，大多数软件系统都要求人们理解它. 开发人员需要了解它并根据体系结构进行实现；需求方也可能从安全性，，操作和维护以及支持的角度对其实施感兴趣. 为了使软件成功，您需要与这些要求苛刻的各方紧密合作，以确保体系结构可以成功地与环境集成. 不幸的是，架构协作很少在开发团队内部发生，更不用说外部需求方面了.

架构交付的部分也类似. 软件体系结构的作用会随着参与程度的不同而变化.

要确保成功实施该体系结构，必须掌握整个概况，并描述软件开发整个生命周期的前景（出售愿景）. 如有必要，请跟随项目一起发展，并对项目的成功交付承担责任. 如果您定义一个架构，那么始终参与并不断发展该架构，而不是将其交给“实施团队”总是很有意义的.

控制全局是技术领导力的一部分，但是在交付软件项目期间还有其他事情要做. 包括: 向所有人介绍（重要性），提供技术规格，做出技术决策并有权做出此类决策.

作为一名架构师，您需要承担技术领导职务，以确保考虑到所有问题并且确保团队走上正确的道路. 软件架构师的职位自然是关于领导力的. 尽管这听起来很明显，但是许多团队的架构师可能认为成功交付并不是他们需要考虑的问题，因此没有所需的技术领导力.

培训团队和指导下属的活动在大多数软件开发项目中都很容易被忽略. 结果是一些团队成员得不到应有的帮助. 尽管技术领导者将指导整个项目，但有时个人需要帮助. 此外，培训团队和教练下属提供了一种增强团队技能和职业发展的方法.

这应该完全属于软件架构师的职权范围，而且很显然，在对团队进行体系结构和设计技能方面的培训与帮助他们解决代码问题之间仍然存在差距.

如果交付太差，即使拥有世界上最好的架构和最强大的领导能力，该项目仍将失败.

质量保证是架构师角色的很大一部分，但它不仅仅是代码审查. 例如，您需要具有基准性能指标，这意味着要引入标准和工作实践. 从软件开发的角度来看，这包括编码标准，设计原则和源代码分析工具. 我们可以肯定地说大多数项目的质量保证还不够，因此您需要确定重要的方面并优先确保这些部分得到实施. 对我而言，所有对体系结构有重要影响，对业务至关重要，对复杂或高度可视化都至关重要. 您需要务实，认识到您不能保证一切，但是做部分总比什么都不做好.

软件架构师角色的最后任务是设计，开发和测试. 成为一线架构师并不意味着您必须参加日常编码任务，而是必须继续参与该项目并积极帮助构建和交付它. 到目前为止，我们不禁要说，为什么每天不编写代码都应成为架构师的一部分？大多数架构师都是经验丰富的程序员，因此保持这种技能的地位很有意义. 此外，架构师还可以体验团队成员将经历的痛苦. 在此过程中，他们可以帮助他们从开发角度理解他们设计的体系结构. 一些公司明确禁止其架构师参与编码，因为他们认为自己的架构师太有价值，不应从事诸如编码这样的普通工作. 显然，这种态度是错误的. 如果您不让他们参与成功交付的过程，那么为什么还要花精力设计架构？

当然，在某些情况下，让架构师参与编写代码确实是不可行的. 例如，大型项目通常意味着需要考虑全局，因此不需要时间参与实施过程. 但总的来说，写代码的建筑师比只看代码的建筑师更高效，更快乐.

将软件开发与软件体系结构之间的界限视为神话还是鸿沟，本文讨论的内容表明，软件架构师担任此角色的经验取决于他们对项目的参与程度以及他们的认真程度. 关于你的角色的变化大多数开发人员不会在星期一早上醒来，而是声称自己是软件架构师. 当然，我不是那样的. 成为建筑师的过程是一个进化的过程. 实际上，一些开发人员可能已经承担了某些软件架构师的角色，尽管他们的职衔并未显示这一点.

参与软件系统的体系结构和亲自设计软件体系结构之间存在很大差异. 跨多个领域的技能，知识和经验的不断提高，创造了软件架构师的角色.

跨越软件工程师和软件架构师的计划是您的，而要做的第一件事就是了解您当前的经验水平.

原始地址

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/jisuanjixue/article-193700-1.html