Question

软件开发和架构之间的界线很诡异。有些人会告诉你这个界线并不存在，架构就是由开发者负责的设计流程的延伸。另一些人则说这是一个巨大的深渊，只有志向远大的开发者才能跨过，他们坚信必须尽可能地抽象，而不拘泥于讨厌的实现细节。跟往常一样，这中间有一种务实的平衡，但它也带来了一个有趣的问题：你如何在两者之间穿梭？

一些常被用于区分软件架构和软件设计的关键因素包括规模的扩大、抽象层级的增加、做出正确设计决策的意义等。软件架构就是总览全貌，看清“大局”，才能理解软件系统整体如何工作。

这可能有助于区分软件设计和架构，然而不一定有助于理解软件开发者如何转换到软件架构的角色。此外，对于辨别谁会成为一个好的软件架构师，以及要如何招聘到他们，也没有帮助。

经验是一个好的评价标准，但你需要看得更深

你需要从软件架构师身上寻找许多不同的品质，他们过去的经验往往能很好地评判他们承担这个角色的能力。既然软件架构师是一个变化的角色，你就要看得更深，才能理解参与度、影响力、领导力和责任感的水平，这些在多个不同领域都已经论证过。结合我对软件架构角色的定义，每个部分都能够且应该单独评估。毕竟，软件设计过程看起来相当简单，要做的就是搞清楚需求，设计一个能满足它们的系统。但在现实中可不是这么简单，人们承担的软件架构角色可能千差万别。比如下面这些。

1.架构驱动力：捕捉和挑战一套复杂的非功能需求，还是简单地假设它们的存在。

2.设计软件：从零开始设计一个软件系统，还是扩展已有的。

3.技术风险：证明你的架构能够工作，还是盲目乐观。

4.架构演化：持续参与和演化你的架构，还是把它交给“实现团队”。

5.编写代码：参与交付的实践部分，还是袖手旁观。

6.质量保证：保证质量并选择标准，还是反其道而行之或无所作为。

其中大部分可以归结为是承担寻找方案的责任还是推诿问题。

模糊的界线

不管你认为软件开发与架构之间的界线是捉摸不透还是深渊，人们对于软件架构角色的经验水平各不相同。此外，软件开发和架构之间的界线某种程度上是模糊的。大多数开发者都不会在某个星期一早上醒来之后，突然宣称自己变成架构师了。我肯定不是的，我通往软件架构的道路很大程度上也是一个演化的过程。说了这么多，很可能不少软件开发者已经为承担部分软件架构的角色做好了准备，不论他们的头衔是什么。

跨越界线是我们的责任

给一个软件系统的架构出力和为之负责之间，有一个很大的差异，那就是构成软件架构角色所需的，跨越不同领域融会贯通的技能、知识和经验。能否跨越软件开发者和架构师的界线，取决于我们自己。作为个人，我们要清楚自己的经验水平，以及为了提升它我们需要关注什么。