《软件架构师》.pdf

开发和架构的界限难以捉摸。有些人告诉你它根本不存在，架构只是开发者们所做的设计过 程的简单扩展。 另外一些人认为这是一个鸿沟，它只能由那些做到高度抽象，而且不会陷 入实现细节的开发者才能跨越。通常，在这两个极端的观点中间某处有个可操作的平衡点； 不论如何，怎么从开发转换为架构师都是个有趣的问题。 经常被用来区分软件架构和软件设计开发的关键几点包括 伸缩性和抽象程度的增加以及作 出正确设计决策意义的增强。软件架构是通过一个全局的观点，宏观的视角来理解软件系统 作为一个整体如何工作。 即使这能够帮助区分软件开发和架构，它并不能帮助理解某人如何从开发提升到架构。 并 且，它也不能帮助识别谁能够成为一个好的软件架构师，如果你想雇人的话你如何去寻找他 们以及你是否是一个软件架构师。 经验可以判定但你需要更深入地了解 要成为一个软件架构师并不是一夜之间或者一个职位的提升就能简单达到的。这是个职责， 而不是头衔。这是个进化的过程，你将会逐步得到担当这个职责所需的经验和信心。 当你寻找架构师时，需要考虑各方面的素质，他们过去的经验往往是他们有能力担当这个职 责很好的判断。由于软件架构师的职责是多种多样的，所以你需要再深入了解他们在不同领 域的参与度，影响力，领导力和责任感。一般来说，在大多数项目中软件架构可分为两个阶 段，架构的定义，然后是它的交付。 软件架构的定义 架构的定义过程看起来非常简单明了。你需要做的是理解需求并设计一个系统来满足需求。 但实际上并没有那么简单，根据你不同的做法，软件架构的职责之间差距很大，以及如何 认真看待自己的职责而定。如下图所示，这个职责的架构定义部分，可以进一步细分成不同 的元素。  管理非功能性需求：软件项目经常陷入问用户要求是什么，什么是他们想要的功能， 但很少问他们需要什么非功能性需求（或系统质量）有时候，干系人会告诉我们，“这 个系统必须很快”，但是这太主观了。非功能性需求如果要满足的话需要明确，可度量， 可获得以及可测试。大多数非功能性需求本质上是技术层面的而且经常对软件架构有 很大的影响。理解非功能性要求是架构师职责非常重要的一个部分，但假设这些需求 是什么并不一定是对他们的挑战。你见过多少系统真正需要24x7 的运行呢？  架构定义：捕捉到了非功能性需求后，下一步是开始思考你打算如何去解决干系人 提出的这些问题并定义它的架构。公平的说每个软件系统都有一个架构，但并不是每 个软件系统都有一个定义好的架构。这正是问题的关键。架构定义过程让你想清楚你 打算怎么在兼顾需求和限制的情况下把问题解决好。架构定义是将结构，方针，原则 和领导力引入软件项目的技术层面。定义架构是作为软件架构师的工作，但是从头开 始设计一个软件系统和对已存在的系统扩展是相当不同的。  技术选型：技术选型通常是一个有趣的练习，但它也有公平的挑战,因为你需要综合 考虑成本、许可、供应商关系、技术策略、兼容性、协作性、支持、部署、升级的政 策以及最终用户环境等各方面。综合这些因素，通常会导致简单选择类似富客户端技 术而进入了完全的噩梦。接下来的问题就是这些技术是否能真正有用。技术选型是彻 头彻尾的风险管理；复杂性或不确定性太高的时候要减轻风险，当有机会或利益的时 候要引入风险。技术决策需要考虑多种因素，而且所有的技术决策需要被检查和评估。 这包含软件项目的主要组成部分乃至开发中引入的类库和框架。如果定义一个架构， 你还需要有信心认为选择这项技术是正确的。同样在技术评估中也还是存在开发新系 统和向现有的系统增加新技术的不同点。  架构评估：如果你设计软件，你需要问问自己你的架构是否有用。 对我来说，一个 架构是成功的，如果它满足非功能性需求，而且为其他部分的代码提供必要的基础， 并为解决和存在的业务问题提供足够的平台。软件的一个最大的问题就是它复杂而抽 象，导致很难从UML 图或代码本身去设想出运行时的特性。在软件开发周期中我们进 行了很多不同类型的测试，这样我们能够有信心我们发布的系统在推出时能够正常运 行。我们为什么不对架构也这样做呢？ 如果能够测试你的架构，那你就可以证明它是 有效的。如果你能尽早做到这一点，你就能减少项目失败的风险，而不是简单地希望 一切都好。  架构协作：任何一个软件都不是与世隔绝的，需要很多人理解它。 包括从需要理解 和切入架构的直接开发团队到其他对安全性、数据库、运营、维护、支持等有兴趣的 干