你是个软件架构师吗？

编者按： 本文作者 Simon Brown ，在三月的 QCon London 上发表了同样主题的演讲《 Software Architecture for Developers 》。

开发和架构的界限难以捉摸。有些人告诉你它根本不存在，架构只是开发者们所做的设计过程的简单扩展。 另外一些人认为这是一个鸿沟，它只能由那些做到高度抽象，而且不会陷入实现细节的开发者才能跨越。通常，在这两个极端的观点中间某处有个可操作的平衡点；不论如何，怎么从开发转换为架构师都是个有趣的问题。

经常被用来区分软件架构和软件设计开发的关键几点包括 伸缩性和抽象程度的增加以及作出正确设计决策意义的增强。软件架构是通过一个全局的观点，宏观的视角来理解软件系统作为一个整体如何工作。

即使这能够帮助区分软件开发和架构，它并不能帮助理解某人如何从开发提升到架构。 并且，它也不能帮助识别谁能够成为一个好的软件架构师，如果你想雇人的话你如何去寻找他们以及你是否是一个软件架构师。

经验可以判定但你需要更深入地了解

要成为一个软件架构师并不是一夜之间或者一个职位的提升就能简单达到的。 这是个职责，而不是头衔。这是个进化的过程，你将会逐步得到担当这个职责所需的经验和信心。

当你寻找架构师时，需要考虑各方面的素质，他们过去的经验往往是他们有能力担当这个职责很好的判断。由于软件架构师的职责是多种多样的，所以你需要再深入了解他们在不同领域的参与度，影响力，领导力和责任感。一般来说，在大多数项目中软件架构可分为两个阶段，架构的定义，然后是它的交付。

软件架构的定义

架构的定义过程看起来非常简单明了。 你需要做的是理解需求并设计一个系统来满足需求。 但实际上并没有那么简单，根据你不同的做法，软件架构的职责之间差距很大，以及如何认真看待自己的职责而定。如下图所示，这个职责的架构定义部分，可以进一步细分成不同的元素。

1. 管理非功能性需求：软件项目经常陷入问用户要求是什么，什么是他们想要的功能，但很少问他们需要什么非功能性需求（或系统质量）有时候，干系人会告诉我们，“这个系统必须很快”，但是这太主观了。非功能性需求如果要满足的话需要明确，可度量，可获得以及可测试。大多数非功能性需求本质上是技术层面的而且经常对软件架构有很大的影响。理解非功能性要求是架构师职责非常重要的一个部分，但假设这些需求是什么并不一定是对他们的挑战。你见过多少系统真正需要 24x7 的运行呢？
2. 架构定义：捕捉到了非功能性需求后，下一步是开始思考你打算如何去解决干系人提出的这些问题并定义它的架构。 公平的说每个软件系统都有一个架构，但并不是每个软件系统都有一个定义好的架构。这正是问题的关键。架构定义过程让你想清楚你打算怎么在兼顾需求和限制的情况下把问题解决好。架构定义是将结构，方针，原则和领导力引入软件项目的技术层面。定义架构是作为软件架构师的工作，但是从头开始设计一个软件系统和对已存在的系统扩展是相当不同的。
3. 技术选型：技术选型通常是一个有趣的练习，但它也有公平的挑战, 因为你需要综合考虑成本、许可、供应商关系、技术策略、兼容性、协作性、支持、部署、升级的政策以及最终用户环境等各方面。综合这些因素，通常会导致简单选择类似富客户端技术而进入了完全的噩梦。接下来的问题就是这些技术是否能真正有用。技术选型是彻头彻尾的风险管理；复杂性或不确定性太高的时候要减轻风险，当有机会或利益的时候要引入风险。技术决策需要考虑多种因素，而且所有的技术决策需要被检查和评估。这包含软件项目的主要组成部分乃至开发中引入的类库和框架。如果定义一个架构，你还需要有信心认为选择这项技术是正确的。同样在技术评估中也还是存在开发新系统和向现有的系统增加新技术的不同点。
4. 架构评估：如果你设计软件，你需要问问自己你的架构是否有用。 对我来说，一个架构是成功的，如果它满足非功能性需求，而且为其他部分的代码提供必要的基础，并为解决和存在的业务问题提供足够的平台。软件的一个最大的问题就是它复杂而抽象，导致很难从 UML 图或代码本身去设想出运行时的特性。在软件开发周期中我们进行了很多不同类型的测试，这样我们能够有信心我们发布的系统在推出时能够正常运行。我们为什么不对架构也这样做呢？ 如果能够测试你的架构，那你就可以证明它是有效的。如果你能尽早做到这一点，你就能减少项目失败的风险，而不是简单地希望一切都好。
5. 架构协作：任何一个软件都不是与世隔绝的，需要很多人理解它。 包括从需要理解和切入架构的直接开发团队到其他对安全性、数据库、运营、维护、支持等有兴趣的干系人。要想让一个软件项目成功，你需要和所有的系统干系人紧密协作来保证架构和所在的环境很好的集成。不幸的是，现状是与开发团队的架构协作很少发生，更不要说外部干系人了。

软件架构的发布

对于架构的发布也是同样，对于成功的软件项目参与程度的不同，也决定了软件架构职责的不同。

1. 拥有全局的视角：为了把一个架构成功地实现，我们需要具有全局的视角并把贯穿软件开发生命周期的愿景加以宣传与推广，必要的话在整个项目中展开和完善，并对成功发布负责。如果如果你定义了一个架构，参与并保持不断发展的架构才是有意义的，而不是选择把它传递给一个“执行小组”。
2. 领导力：拥有全局的视角是技术领导的一个方面，但是还有其他事情在软件项目发布阶段需要做。 这包括承担责任、提供技术指导、作出技术决策以及具有权力作出这些决定。作为架构师，你需要进行技术领导来确保每件事都被考虑到，而且团队在朝着正确的方向持续前进。软件架构师职位是需要内在领导力的，虽然这听起来很明显，但很多项目团队并没有获得他们所需要的技术领导，因为架构师认为一个成功的发布并不一定是他们所关注的问题。
3. 教练和指导：在大多数软件开发项目中，教练和指导经常不被重视，团队成员得不到他们需要的支持。 虽然技术领导是引导整个项目，但个人也经常需要帮助。除此以外，教练和指导提供了一个强化技能的方式，并帮助提升职业生涯。这应该是软件架构师份内的事，而且指导团队架构和设计与帮他们解决代码问题是截然不同的。
4. 质量保证：即使是世界上最好的架构和领导，很糟糕的交付也足以让一个具备其他成功条件的项目失败。质量保证在架构师职责中占很大一部分，但这并不只是简单做代码检查。 比如，你需要一个基线来确保，这意味着引入新的标准和工作实践。从一个软件开发的角度来说，这可能包括代码标准、设计原则和源码分析工具甚至于使用持续集成, 自动化单元测试以及代码覆盖工具。可以说大多数项目质量保证做的并不够，所以你需要搞清楚什么是重要的并给予它足够的保证。对于我来说，一个项目的重要部分包括架构上的重点，关键、复杂或高度可见的业务。你要关注实效并认识到你并不能保证一切，要知道做总比不做好。
5. 设计、开发和测试：软件架构师的职责范围的最后一件事是设计、开发和测试。作为一个实际动手的架构师并不是需要你每天都要写代码，但是它的确意味着你一直在参与项目，而且积极帮助打造和交付它。说了这么多，为什么每天写代码不应该成为一个架构师职责的一部分呢？大多数架构师都有写代码的经验，因此让这些技能保鲜是有意义的。而且，架构师能体会到团队里其他人的痛苦和感受，这样能让他们更好地理解他们的架构从开发角度看是什么样的。很多公司有政策阻止软件架构师从事写代码，因为架构师“去做那些廉价的工作太贵了” ，这显然是个错误的态度…如果架构师已经花了那么多时间精力为项目做架构，何必从政策上不允许他们多走一步来帮助项目达到最终的成功呢？当然，有些情况下卷入代码级别并不现实。比如，一个大的项目通常意味有一个更大的“全局观” 来考虑它，而且可能有时候你就是没有时间。但一般来说，一个写代码的架构师比只在旁边观望要更高效和快乐。

你是一个软件架构师吗？

不管你认为软件开发和架构之间的界限只是一个幻觉还是个巨大的鸿沟，以上强调了人们对整个软件架构中的经验水平往往有很大的差别，而这取决于他们怎么样工作以及他们如何认真地看待他们的职责。大多数开发人员不是在某一个星期一的早晨醒来就宣布自己成为一个软件架构师的。我当然也不是，我成为软件架构师的路线是一个渐进的过程。话虽如此，但很可能同样那些开发者已经做了一部分架构的工作，不论他们的职位名称是什么。

为软件系统的架构作出贡献和自己负责定义它有很大的区别，拥有持续的、跨不同领域的技能、知识和经验构成了软件架构的职责。跨越软件开发者和架构师的界限取决于你自己，但是首先你要明白你的经验水平，才能开始架构师之旅的第一站。

关于作者

你可以认为 Simon Brown 是一个写代码的软件架构师或者理解架构的软件开发者。当他没有用.NET 或 Java 开发软件的时候，Simon 通常在做咨询，指导或者培训。 Simon 还写过关于 Java 的书，在行业活动做过演讲，并且整合了一个叫 Software Architecture for Developers 的培训课程， 该课程基于他在 Coding the Architecture 描 述的软件架构。你可以通过 e-mail 或 Twitter 找到他。

查看英文原文： Are You a Software Architect?

给 InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家加入到 InfoQ 中文站用户讨论组中与我们的编辑和其他读者朋友交流。