你是个软件架构师吗.pdfVIP

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