软件架构思想

记得我曾服务于一家软件公司任项目主管(项目总监)时，刚进公司时由于开发工作处于无序状态(也就是CMMI中定义的0级)，所有项目几乎均是一再延期、质量低下。于是我建议并得到公司老板的大力支持下，根据公司人员的当前能力并稍高一点要求，以并行开发模式SPP为主、借鉴部分CMMI3与RUP规范，制订了公司的开发流程、规范、模板与制度，并强调需求、架构与品质保证活动的作用。经过一段时间的培训后，我在试点项目评审项目经理报上来的工作量估算报告与项目开发计划时，询问项目经理工作量估算与计划安排的依据是什么？几乎绝大多数项目经理和参与工作量估算与计划安排的项目组成员无一例外的回答我：由于大家以前没有进行过这么规范的开发，对需求管理工具、系统建模工具使用不熟练，也不习惯写出这种规范的规约文档，因此完成这些文档必须使用这么多工期，而且即使这样，大家对写出来的文档能否通过品质保证活动的评审还忐忑不安呢！

于是我立刻找到老板与相关决策人员，要求暂停相关工作的继续推进，并采取针对性的培训、交流讨论、辩论强调等工作与措施，纠正大家思想认识上的错误和工作上的形式主义。 在会议上，部分相关决策人员反问我：他们说的是实情，有什么大惊小怪的呢？这涉及到软件架构的目的与目标。

软件架构的目的是依据软件工程的"早讨论、早交付、多反馈"的思想原则、与项目各涉众人员交流讨论软件系统——沟通。典型的沟通有：1、与最终用户沟通。为什么要开发这个软件系统呢？因为最终用户需要使用该软件系统辅助完成日常工作、管理某些信息、带来娱乐体验……对于软件系统，用户需求是千差万别、千变万化的，软件架构必须和所要提供的功能相适应。同时，用户要功能，出要质量。2、与客户沟通。最终为软件系统付费购买的是客户，客户在决定付费购买前会充分考虑软件系统与自身的业务目标、上线时间、预算限制、集成要求等等的符合性与适应性，而这些恰恰是软件架构必须考虑的重要约束。同时还必须关注客户所在领域的业务规则与业务限制。3、与开发设计编码测试实施人员沟通。软件系统完成软件架构后并不能直接使用，还必须依靠开发设计编码测试实施人员的共同努力才能形成最终可运行的交付物。一方面，在软件架构时，许多影响关键决策的非功能需求如可配置式部署、可扩展性、可重用性、可移植性、易理解性和易测试性都不是最终用户或客户主要关注的，而是开发设计编码测试实施人员重点关注的，它们都将深刻影响这些人员的工作难易程度与工作量，使这些人员的工作更顺畅或更艰难。另一方面，软件系统的架构设计得再好，如果不能有效的被这些人员充分理解和掌握，比如使用的技术目前这些人员没有掌握并且在一个较长的时间段内花费大量人力、物力、财力也无法保证很好掌握，将会给软件项目带来不可预知的冲击与风险。4、与管理人员沟通。当前软件系统变得越来越复杂而人员分工越来越细致，单兵作战、个人英雄主义不再是普遍的软件开发方式与现象，取而代之的是团队协同并行开发。要理清并管理不同开发人员之间的协同工作关系，就应该清楚开发人员各自负责的软件模块之间的关系——这正是软件架构的内容之一。这使得软件架构自然而然地成为开发管理的基础与帮手。因此软件架构必须考虑为管理人员进行分工管理、协调控制和评估监控等工作提供清晰的基础。

软件架构的目标是从面向业务的需求到面向技术的转换、清晰讲解软件系统的内部结构、通过与项目各涉众人员的及早充分沟通发现问题、指导并为软件系统的开发活动建立基础、提高软件系统质量、保证软件项目的成功。

一般而言，成功的软件架构会起到如下的作用：上承业务目标与业务需求，下接技术决策与开发指导，控制软件系统的复杂性，为组织开发奠定依据与基础，利于迭代开发和增量交付，提高软件质量和用户满意度，固化核心知识，提供可重用资产，缩短开发周期、降低成本。

因此，软件架构是软件系统包含的主要元素、重要约束与关键决策，以及它们之间的关系并如何进行协作交互，以满足软件系统的不同涉众需求。它是一个过程而不是单纯的静态RUP中的4+1视图或软件架构文档。RUP中的4+1视图或软件架构文档是以一种固定结构与格式来表现软件架构过程最终形成的成果，是软件架构过程水到渠成的必然产物，也是进行沟通与检验软件架构过程工作的最佳有效方式。不能将软件架构阶段工作当成为完成RUP中的4+1视图或软件架构文档并通过评审而工作，从而走上形式主义产生高来高去的所谓软件架构，不但浪费大量人力、物力、财力，而且给软件项目埋下巨大隐患。

在软件架构过程中，以下三点是进行成功架构的经验之谈：

1. 关注分割拆分与交互协作。 这是人类认知事物的规律。对于一个比较复杂的事物，人类在认知的过程中一般会将该复杂的事物按某种规律与方式分割成多个小的简单的部分并忽略一些简单次要的因素，然后对每一个部分依此类推直到所有的部分都简单明晰的认知，最后将这些部分组合成整体认识。在认识的过程中，对于直接接触的事物我们会首先认知该事物的静态属性，然后根据这些静态属性标识该事物在环境中的动态行为；同时，我们会从环境动态行为中发现许多没有直接交互的隐藏事物，然后分析其静态属性。
2. 有层次性的决策。首先，伴随着对软件系统的分割拆分依次分解，架构工程师将不断作出决策，如需要划分成哪些模块、各模块职责是什么、每个模块的接口如何定义、模块间采用什么交互机制、如何满足约束和非功能需求、如何适应可能发生的变化。然后，软件架构工程师必须规划整个系统的具体组成。注意，在决策的时候，决策制定的顺序是先制定技术无关的决策、再制定技术相关的决策、后者在前者的指导下进行。
3. 思维的发散与收敛。软件架构过程中的各阶段的每一步都是某种决策行为，而这种决策决不是简单的屁股指挥脑袋的一拍脑门。在决策前我们必须全面了解事物的所有内在、外在因素，如静态属性、动态行为、受环境的影响、对环境的影响、约束与限制等——这就是第一次思维的发散；然后找出事物的核心本质与规律，忽略次要因素——这就是第一次思维的收敛；根据事物的核心本质与规律，找到所有可能的解决方案与思路，对每一种可能的解决方案与思路分析其优缺点——这就是第二次思维的发散；最后针对各种解决方案与思路的优缺点，根据既定的标准与要求进行选择——这就是第二次思维的收敛。