软件开发和软件架构之间有一条微妙的线。有人会说，这条线根本不存在，架构只是开发者设计过程的简单延伸。

图片来自 Pexels

另外一部分人则说，这是一条巨大的鸿沟，只有少数出类拔萃的开发者才能跨越，这些开发者都认为你必须不断地向上抽象，避免陷入令人生厌的实现细节的泥沼。

如果以务实的眼光看，那这两者之间必定存在某个平衡点，但这接着也提出了问题：如何从开发者变成架构师?

将软件架构从软件设计和开发中区分开来的关键因素包括：规模的上升、抽象层次的上升， 以及做出正确的设计决策带来的影响的上升等等。

软件架构就在于能有一个全局视角、能具备更大的视野，理解软件系统作为一个整体是如何工作的。

这些因素对区分软件开发和软件架构也许有帮助，但还是无法解释一些人如何从开发转到了架构。

进一步地，对于如何识别哪些人将会成为出色的架构师，作为 HR 如何发现这些人，以及自己是不是一名架构师，上述定义也无能为力。

1、经验

尽管经验是一个很好的衡量指标，但你应该看得更深。

没有人是在一夜之间或一次升职就成为软件架构师的。架构师是一个角色，而非级别。

这是一个演进的过程，在这个过程中你会不断获得承担架构师角色所需的经验与自信。

架构师身上有许多不同的品质，而他们过去的经验通常是承担这个角色所需能力的一种很好的度量。

架构师角色包括很多方面，因此需要在更深的层次地去理解架构师在不同方面展现出来的参与度、影响力、领导力和责任。

宽泛地说，大部分项目的软件架构过程可以分成两个阶段：定义阶段和交付阶段。

2、软件架构的定义

架构的定义过程似乎相当直接：确定需求，然后设计一个满足这些需求的系统。

但实际上并没有这么简单，由于参与程度和对待自己角色的认真程度各有不同，软件架构的角色也有很大的区别。

如下图所示，角色的架构定义部分可以进一步分解为几个子部分：

①非功能性需求的管理

软件项目经常将注意力放在用户的功能特性上，而很少问用户有什么非功能需求或系统性能要求。

有时需求方会告诉我们说“系统必须足够快”，但这种表述太主观了。要满足非功能需求，那这些需要必须是具体的、可测量、可实现以及可测试的。

大部分非功能需求本质上是技术性的，而且通常对软件架构有很大影响。理解非功能需求是架构师角色的核心能力之一，但试图理解这些需求与质疑这些需求的合理性有所不同。

毕竟，你见过多少真正需要 7x24 小时运行的系统呢?

②架构定义

弄清了非功能需求后，下一步就要思考如何定义架构，解决需求方提出的问题。

我们可以说每个软件系统都有架构，但不是每个软件系统都有现成的架构。这才是关键点。

软件定义过程需要思考如何在给定的限制下满足提出的需求，进而解决问题。架构定义过程是在项目的技术方面引入结构、规范、原则和领导力的过程。

定义架构软件架构师的工作，但从头设计一个软件系统与扩展一个现有系统还是有很大的差别。

③技术选型

技术选择通常是一个愉快的过程，但当考虑到成本、授权、供应商关系、技术策略 、兼容性、互操作性、支持、部署、升级策略、终端用户环境等问题时，挑战往往相当大。

这些因素综合起来，经常会把一个简单的选择某些东西，例如设计一个功能丰富的客户端，变成一场噩梦。

接下来还有另一个问题：这些技术能否像期望的那样运行。

技术选型的本质管理风险：在复杂性或不确定性较高的地方减少引入风险，在可能带来收益的地方适当接受风险。

技术决策需要考虑所有的因素并需要评审和评估，包括软件项目的核心组件，以及开发过程会用到的库和框架。

如果正在进行架构定义，你需要确信自己的技术选型是正确的。同样地，为一个新系统开展评估技术与向现有系统引入新技术有着很大的区别。

④架构评估

如果让你来设计软件，需要问自己：我的架构能否工作?

对于我来说，这样的架构可以工作：满足非功能需求，为其他部分的代码提供了必要的 基础设施，为解决底层业务的问题提供了一个平台。

软件最大的问题之一就是复杂性和抽象，很难从 UML 图或代码去想象出软件运行时的特点。

在软件开发的过程中，会采用多种测试技术确保交付的系统在上线之后能正常工作。为什么不对架构设计采用同样的方式呢?

如果可以测试架构，就可以证明该架构可以正常工作。这项工作做得越早，就越能减少项目失败的风险。而不是简单寄希望于它能正常工作。

⑤架构协作

与世隔绝的软件系统很少见，大部分软件系统都是需要靠人来理解。开发人员需要理解后按照架构实现;需求方出于安全、数据库、运维、支持等角度，也可能对架构实现感兴趣。

软件要成功，就需要与这些需求方紧密合作，保证架构能够和环境成功集成。不幸的是，即便在开发组内架构协作都很少发生，更遑论外部的需求方了。

3、软件架构的交付

架构交付的部分也是类似，软件架构的角色会随着参与度不同而有所区别。

①拥有更大的视野

要确保架构成功落地，必须得有人在软件开发的整个生命周期内拥有更大的视野，向大家描绘远景。如有必要跟随项目一起演进，承担将交付责任。

如果你定义了一个架构，那始终保持对架构的参与和演进是很有意义的，而不是将它交给 “实现团队”。

②领导力

把控大图是技术领导力的一部分，但在软件项目交付期间还有其它一些事情要做，包括向大家介绍任务的重要性、提供技术规范、做技术决策，以及具备决策权威。

作为架构师，你需要承担技术领导力，保证所有的事情都考虑到了而且团队走在正确的道路上。

软件架构师的位置天然与领导力有关。虽然听起来显而易见，但很多团队中的架构师可能会认为，成功交付并不是他们需要考虑的问题，进而丧失了必要的技术领导力。

③培训与指导

培训团队和指导下属是大部分软件开发项目中容易被忽视的一项活动，导致的后果：一些团队成员并没有得到他们应该得到的帮助。

虽然技术领导力是关于对项目整体进行掌舵，但也有一些时候个人需要帮助。而且，培训团队和指导下属提供了一种增强队员技能和提升他们职业生涯的方式。

这是架构师职责的一部分，而且很显然，为团队培训架构和设计技能与助他们解决代码问题之间有着显著的区别。

④质量保障

如果交付工作做的太差的话，即使拥有世界上最好的架构和最强的领导力，项目仍然会失败。

质量保障是架构师角色中的很大一部分工作，但并非仅仅是代码审核。例如，需要提供基准性能指标时，意味着需要引入标准和工作守则。

从软件开发的角度讲，这包括编码标准、设计原则、源代码分析工具等。

可以肯定地说，大部分项目的质量保障做的并不够。因此你需要辨别出哪些是重要的，并优先保证这些部分被执行。

对我来说，一切对架构有重要影响的、对业务非常关键的、复杂的或能够可视化的东西都是重要的。

这需要脚踏实地，意识到你无法保障所有方面，但实际做一些工作总比什么都不做好。

⑤设计、开发与测试

软件架构师角色的最后任务就是设计、开发和测试。作为一名工作在一线的架构师，并不意着你必须参与每天的写代码任务。而是持续参与到项目中，积极主动地去帮助打造软件并实现交付。

话已至此，我们不禁要说，为什么每天写代码不应该成为架构师角色的一部分呢?

大部分架构师都是经验丰富的程序员，因此保持这项技能的状态是有意义的。

除此之外，架构师还能经历团队成员都会经历的痛苦，在此过程中可以帮助他们从开发的角度理解他们设计出来的架构。

一些公司明令禁止架构师参与编码工作，因为觉得架构师太宝贵了，不应该从事编码这样普通的工作。

显然，这种态度是错误的。如果不让他们参与成功交付的过程，那又为什么让他们花费精力设计架构呢?

当然，有些情况下让架构师参与写代码确实不太可行。例如一个大型项目通常意味着需要思考的架构很大，不一定有时间参与到实现过程。

但通常来说，写代码的架构师只会比只会旁观的架构师更加高效和快乐。

4、你是一名软件架构师吗?

不论软件开发和软件架构之间的那条线是神话还是鸿沟，本文讨论的内容都说明了软件架构师这个角色，经验随着实际参与项目的程度以及对待架构师角色的认真程度不同而不同。

大部分开发者都不会周一早上醒来就能宣称自己是一名软件架构师。我自己当然不是这样，成为架构师的过程是一个演进的过程。

其实，一部分开发者可能已经在承担部分软件架构师的角色了，虽然他们的职位并没有体现出这一点。

参与一个软件系统的架构和亲自设计一个软件架构有很大不同。持续精进技能、知识和跨多领域的经验成就了软件架构师的角色。

跨越软件工程师和软件架构师的主动权在自己手上。而首先要做的，就是了解目前自己的经验所处的层次。

作者：arthurchiao，本文翻译自 2019 年的一篇英文博客 "Are You A Software Architect?"

编辑：陶家龙

出处：