架构设计中的方法学

约公元前25年，古罗马建筑师维特鲁威说：“理想的建筑师应该既是文学家又是数字家，他还应通晓历史，热衷于哲学研究，精通音乐，懂得医药知识，具有法学造诣，深谙天文学及天文计算。”（好难哪，软件构架设计师的要求呢？大家好好想想吧。）
  本文目录
  一、与构架有关的几个基本概念；
  二、构架设计应考虑的因素概揽；
  三、程序的运行时结构方面的考虑；
  四、源代码的组织结构方面的考虑；
  五、写系统构架设计文档应考虑的问题
  六、结语
  一、与构架有关的几个基本概念：
  1、模块（module）：一组完成指定功能的语句，包括：输入、输出、逻辑处理功能、内部信息、运行环境（与功能对应但不是一对一关系）。
  2、组件（component）：系统中相当重要的、几乎是独立的可替换部分，它在明确定义的构架环境中实现确切的功能。
  3、模式（pattern）：指经过验证，至少适用于一种实用环境（更多时候是好几种环境）的解决方案模板（用于结构和行为。在 UML中：模式由参数化的协作来表示，但 UML 不直接对模式的其他方面（如使用结果列表、使用示例等，它们可由文本来表示）进行建模。存在各种范围和抽象程度的模式，例如，构架模式、分析模式、设计模式和代码模式或实施模式。模式将可以帮助我们抓住重点。构架也是存在模式的。比如，对于系统结构设计，我们使用层模式；对于分布式系统，我们使用代理模式（通过使用代理来替代实际的对象，使程序能够控制对该对象的访问）；对于交互系统，我们使用MVC（M模型(对象)／V视图(输出管理)／C控制器(输入处理)）模式。模式是针对特定问题的解，因此，我们也可以针对需求的特点采用相应的模式来设计构架。
  4、构架模式（architectural pattern）：表示软件系统的基本结构组织方案。它提供了一组预定义的子系统、指定它们的职责，并且包括用于组织其间关系的规则和指导。
  5、层（layer）：对模型中同一抽象层次上的包进行分组的一种特定方式。通过分层，从逻辑上将子系统划分成许多集合，而层间关系的形成要遵循一定的规则。通过分层，可以限制子系统间的依赖关系，使系统以更松散的方式耦合，从而更易于维护。（层是对构架的横向划分，分区是对构架的纵向划分）。
  6、系统分层的几种常用方法：
  1） 常用三层服务：用户层、业务逻辑层、数据层；
  2） 多层结构的技术组成模型：表现层、中间层、数据层；
  3） 网络系统常用三层结构：核心层、汇聚层和接入层；
  4） RUP典型分层方法：应用层、专业业务层、中间件层、系统软件层；
  5） 基于Java的B/S模式系统结构：浏览器端、服务器端、请求接收层、请求处理层；
  6） 某六层结构：功能层（用户界面）、模块层、组装层（软件总线）、服务层（数据处理）、数据层、核心层；
  7、构架（Architecture，愿意为建筑学设计和建筑物建造的艺术与科学）: 在RUP中的定义：软件系统的构架（在某一给定点）是指系统重要构件的组织或结构，这些重要构件通过接口与不断减小的构件与接口所组成的构件进行交互；《软件构架实践》中的定义：某个软件或者计算系统的软件构架即组成该系统的一个或者多个结构，他们组成软件的各个部分，形成这些组件的外部可见属性及相互间的联系；IEEE 1471-2000中的定义：the fundamental organization of a system emboided in its components,their relationships to each other,and to the enviroment and the principles guiding its design and evolution，构架是系统在其所处环境中的最高层次的概念。软件系统的构架是通过接口交互的重要构件（在特定时间点）的组织或结构，这些构件又由一些更小的构件和接口组成。（“构架”可以作为名词，也可作为动词，作为动词的“构架”相当于“构架设计”）
  8、构架的描述方式：“4＋1”视图（用例视图、设计视图、实现视图、过程视图、配置视图）是一个被广为使用的构架描述的模型；RUP过程的构架描述模板在“4＋1”视图的基础上增加了可选的数据视图（从永久性数据存储方面来对系统进行说明）；HP公司的软件描述模板也是基于“4＋1”视图。
  9、结构：软件构架是多种结构的体现，结构是系统构架从不同角度观察所产生的视图。就像建筑物的结构会随着观察动机和出发点的不同而有多种含义一样，软件构架也表现为多种结构。常见的软件结构有：模块结构、逻辑或概念结构、进程或协调结构、物理结构、使用结构、调用结构、数据流、控制流、类结构等等。
  二、构架设计应考虑的因素概揽：
  模块构架设计可以从程序的运行时结构和源代码的组织结构方面考虑。
  1、程序的运行时结构方面的考虑：
  1） 需求的符合性：正确性、完整性；功能性需求、非功能性需求；
  2） 总体性能（内存管理、数据库组织和内容、非数据库信息、任务并行性、网络多人操作、关键算法、与网络、硬件和其他系统接口对性能的影响）；
  3） 运行可管理性：便于控制系统运行、监视系统状态、错误处理；模块间通信的简单性；与可维护性不同；
  4） 与其他系统接口兼容性；
  5） 与网络、硬件接口兼容性及性能；
  6） 系统安全性；
  7） 系统可靠性；
  8） 业务流程的可调整性；
  9） 业务信息的可调整性
  10） 使用方便性
  11） 构架样式的一致性
  注：运行时负载均衡可以从系统性能、系统可靠性方面考虑。
  2、源代码的组织结构方面的考虑：
  1） 开发可管理性：便于人员分工（模块独立性、开发工作的负载均衡、进度安排优化、预防人员流动对开发的影响）、利于配置管理、大小的合理性与适度复杂性；
  2） 可维护性：与运行可管理性不同；
  3） 可扩充性：系统方案的升级、扩容、扩充性能；
  4） 可移植性：不同客户端、应用服务器、数据库管理系统；
  5） 需求的符合性（源代码的组织结构方面的考虑）。

三、程序的运行时结构方面的考虑：
  1、 需求的符合性：正确性、完整性；功能性需求、非功能性需求
  软件项目最主要的目标是满足客户需求。在进行构架设计的时候，大家考虑更多的是使用哪个运行平台、编成语言、开发环境、数据库管理系统等问题，对于和客户需求相关的问题考虑不足、不够系统。如果无论怎么好的构架都无法满足客户明确的某个功能性需求或非功能性需求，就应该与客户协调在项目范围和需求规格说明书中删除这一需求。否则，架构设计应以满足客户所有明确需求为最基本目标，尽量满足其隐含的需求。（客户的非功能性需求可能包括接口、系统安全性、可靠性、移植性、扩展性等等，在其他小节中细述）
  一般来说，功能需求决定业务构架、非功能需求决定技术构架，变化案例决定构架的范围。需求方面的知识告诉我们，功能需求定义了软件能够做些什么。我们需要根据业务上的需求来设计业务构架，以使得未来的软件能够满足客户的需要。非功能需求定义了一些性能、效率上的一些约束、规则。而我们的技术构架要能够满足这些约束和规则。变化案例是对未来可能发生的变化的一个估计，结合功能需求和非功能需求，我们就可以确定一个需求的范围，进而确定一个构架的范围。（此段From林星）
  这里讲一个前几年因客户某些需求错误造成构架设计问题而引起系统性能和可靠性问题的小小的例子：此系统的需求本身是比较简单的，就是将某城市的某业务的全部历史档案卡片扫描存储起来，以便可以按照姓名进行查询。需求阶段客户说卡片大约有20万张，需求调研者出于对客户的信任没有对数据的总量进行查证。由于是中小型数据量，并且今后数据不会增加，经过计算20万张卡片总体容量之后，决定使用一种可以单机使用也可以联网的中小型数据库管理系统。等到系统完成开始录入数据时，才发现数据至少有60万，这样使用那种中小型数据库管理系统不但会造成系统性能的问题，而且其可靠性是非常脆弱的，不得不对系统进行重新设计。从这个小小的教训可以看出，需求阶段不仅对客户的功能需求要调查清楚，对于一些隐含非功能需求的一些数据也应当调查清楚，并作为构架设计的依据。
  对于功能需求的正确性，在构架设计文档中可能不好验证（需要人工、费力）。对于功能需求完整性，就应当使用需求功能与对应模块对照表来跟踪追溯。对于非功能需求正确性和完整性，可以使用需求非功能与对应设计策略对照表来跟踪追溯评估。
  “软件设计工作只有基于用户需求，立足于可行的技术才有可能成功。”
  2、 总体性能
  性能其实也是客户需求的一部分，当然可能是明确的，也有很多是隐含的，这里把它单独列出来在说明一次。性能是设计方案的重要标准，性能应考虑的不是单台客户端的性能，而是应该考虑系统总的综合性能；
  性能设计应从以下几个方面考虑：内存管理、数据库组织和内容、非数据库信息、任务并行性、网络多人操作、关键算法、与网络、硬件和其他系统接口对性能的影响；
几点提示：算法优化及负载均衡是性能优化的方向。经常要调用的模块要特别注意优化。占用内存较多的变量在不用时要及时清理掉。需要下载的网页主题文件过大时应当分解为若干部分，让用户先把主要部分显示出来。
  3、 运行可管理性
  系统的构架设计应当为了使系统可以预测系统故障，防患于未然。现在的系统正逐步向复杂化、大型化发展，单靠一个人或几个人来管理已显得力不从心，况且对于某些突发事件的响应，人的反应明显不够。因此通过合理的系统构架规划系统运行资源，便于控制系统运行、监视系统状态、进行有效的错误处理；为了实现上述目标，模块间通信应当尽可能简单，同时建立合理详尽的系统运行日志，系统通过自动审计运行日志，了解系统运行状态、进行有效的错误处理；（运行可管理性与可���护性不同）
  4、 与其他系统接口兼容性（解释略）
  5、 与网络、硬件接口兼容性及性能（解释略）
  6、 系统安全性
  随着计算机应用的不断深入和扩大，涉及的部门和信息也越来越多，其中有大量保密信息在网络上传输，所以对系统安全性的考虑已经成为系统设计的关键，需要从各个方面和角度加以考虑，来保证数据资料的绝对安全。
  7、 系统可靠性
  系统的可靠性是现代信息系统应具有的重要特征，由于人们日常的工作对系统依赖程度越来越多，因此系统的必须可靠。系统构架设计可考虑系统的冗余度，尽可能地避免单点故障。系统可靠性是系统在给定的时间间隔及给定的环境条件下，按设计要求，成功地运行程序的概率。成功地运行不仅要保证系统能正确地运行，满足功能需求，还要求当系统出现意外故障时能够尽快恢复正常运行，数据不受破坏。
  8、 业务流程的可调整性
  应当考虑客户业务流程可能出现的变化，所以在系统构架设计时要尽量排除业务流程的制约，即把流程中的各项业务结点工作作为独立的对象，设计成独立的模块或组件，充分考虑他们与其他各种业务对象模块或组件的接口，在流程之间通过业务对象模块的相互调用实现各种业务，这样，在业务流程发生有限的变化时（每个业务模块本身的业务逻辑没有变的情况下），就能够比较方便地修改系统程序模块或组件间的调用关系而实现新的需求。如果这种调用关系被设计成存储在配置库的数据字典里，则连程序代码都不用修改，只需修改数据字典里的模块或组件调用规则即可。
  9、 业务信息的可调整性
  应当考虑客户业务信息可能出现的变化，所以在系统构架设计时必须尽可能减少因为业务信息的调整对于代码模块的影响范围。
  10、 使用方便性
  使用方便性是不须提及的必然的需求，而使用方便性与系统构架是密切相关的。WinCE（1.0）的失败和后来改进版本的成功就说明了这个问题。WinCE（1.0）有太多层次的视窗和菜单，而用户则更喜欢简单的界面和快捷的操作。失败了应当及时纠正，但最好不要等到失败了再来纠正，这样会浪费巨大的财力物力，所以在系统构架阶段最好能将需要考虑的因素都考虑到。当然使用方便性必须与系统安全性协调平衡统一，使用方便性也必须与业务流程的可调整性和业务信息的可调整性协调平衡统一。“满足用户的需求，便于用户使用，同时又使得操作流程尽可能简单。这就是设计之本。”
  11、构架样式的一致性
  软件系统的构架样式有些类似于建筑样式（如中国式、哥特式、希腊复古式）。软件构架样式可分为数据流构架样式、调用返回构架样式、独立组件构架样式、以数据为中心的构架样式和虚拟机构架样式，每一种样式还可以分为若干子样式。构架样式的一致性并不是要求一个软件系统只能采用一种样式，就像建筑样式可以是中西结合的，软件系统也可以有异质构架样式（分为局部异质、层次异质、并行异质），即多种样式的综合，但这样的综合应该考虑其某些方面的一致性和协调性。每一种样式都有其使用的时机，应当根据系统最强调的质量属性来选择。 
  四、源代码的组织结构方面的考虑：
  1、 开发可管理性
  便于人员分工（模块独立性、开发工作的负载均衡、进度安排优化、预防人员流动对开发的影响：一个好的构架同时应有助于减少项目组的压力和紧张，提高软件开发效率）、利于配置管理、大小的合理性、适度复杂性；
  1）便于人员分工－模块独立性、层次性
  模块独立性、层次性是为了保证项目开发成员工作之间的相对独立性，模块联结方式应该是纵向而不是横向, 模块之间应该是树状结构而不是网状结构或交叉结构，这样就可以把开发人员之间的通信、模块开发制约关系减到最少。同时模块独立性也比较利于配置管理工作的进行。现在有越来越多的的软件开发是在异地进行，一个开发组的成员可能在不同城市甚至在不同国家，因此便于异地开发的人员分工与配置管理的源代码组织结构是非常必要的。
  2）便于人员分工－开发工作的负载均衡
  不仅仅是开发出来的软件系统需要负载均衡，在开发过程中开发小组各成员之间工作任务的负载均衡也是非重要的。所谓工作任务的负载均衡就是通过合理的任务划分按照开发人员特点进行分配任务，尽量让项目组中的每个人每段时间都有用武之地。这就需要在构架设计时应当充分考虑项目组手头的人力资源，在实现客户需求的基础上实现开发工作的负载均衡，以提高整体开发效率。
  3）便于人员分工－进度安排优化；
  进度安排优化的前提是模块独立性并搞清楚模块开发的先后制约关系。利用工作分解结构对所有程序编码工作进行分解，得到每一项工作的输入、输出、所需资源、持续时间、前期应完成的工作、完成后可以进行的工作。然后预估各模块需要时间，分析各模块的并行与串行（顺序制约），绘制出网络图，找出影响整体进度的关键模块，算出关键路径，最后对网络图进行调整，以使进度安排最优化。
  有个家喻户晓的智力题叫烤肉片策略：约翰逊家户外有一个可以同时烤两块肉片的烤肉架，烤每块肉片的每一面需要10分钟，现要烤三块肉片给饥肠辘辘急不可耐的一家三口。问题是怎样才能在最短的时间内烤完三片肉。一般的做法花20分钟先烤完前两片，再花20分钟烤完第三片。有一种更好的方法可以节省10分钟，大家想想。
  4）便于人员分工－预防员工人员流动对开发的影响
  人员流动在软件行业是司空见惯的事情，已经是一个常见的风险。作为对这一风险的有效的防范对策之一，可以在构架设计中考虑到并预防员工人员流动对开发的影响。主要的思路还是在模块的独立性上（追求高内聚低耦合），组件化是目前流行的趋势。
  5）利于配置管理（独立性、层次性）
  利于配置管理与利于人员分工有一定的联系。除了逻辑上的模块组件要利于人员分工外，物理上的源代码层次结构、目录结构、各模块所处源代码文件的部署也应当利于人员分工和配置管理。（尽管现在配置管理工具有较强大的功能，但一个清楚的源码分割和模块分割是非常有好处的）。
  6）大小的合理性与适度复杂性
  大小的合理性与适度复杂性可以使开发工作的负载均衡，便于进度的安排，也可以使系统在运行时减少不必要的内存资源浪费。对于代码的可阅读性和系统的可维护性也有一定的好处。另外，过大的模块常常是系统分解不充分，而过小的模块有可能降低模块的独立性，造成系统接口的复杂。
  2、 可维护性
  便于在系统出现故障时及时方便地找到产生故障的原因和源代码位置，并能方便地进行局部修改、切割；（可维护性与运行可管理性不同）
  3、 可扩充性：系统方案的升级、扩容、扩充性能
  系统在建成后会有一段很长的运行周期，在该周期内，应用在不断增加，应用的层次在不断升级，因此采用的构架设计等方案因充分考虑升级、扩容、扩充的可行性和便利
  4、 可移植性
  不同客户端、应用服务器、数据库管理系统：如果潜在的客户使用的客户端可能使用不同的操作系统或浏览器，其可移植性必须考虑客户端程序的可移植性，或尽量不使业务逻辑放在客户端；数据处理的业务逻辑放在数据库管理系统中会有较好的性能，但如果客户群中不能确定使用的是同一种数据库管理系统，则业务逻辑就不能数据库管理系统中；
达到可移植性一定要注重标准化和开放性：只有广泛采用遵循国际标准，开发出开放性强的产品，才可以保证各种类型的系统的充分互联，从而使产品更具有市场竞争力，也为未来的系统移植和升级扩展提供了基础。
  5、 需求的符合性
  从源代码的组织结构看需求的符合型主要考虑针对用户需求可能的变化的软件代码及构架的最小冗余（同时又要使得系统具有一定的可扩展性）。
  五、写系统构架设计文档应考虑的问题
  构架工作应该在需求开发完成约80％的时候开始进行，不必等到需求开发全部完成，需要项目经理以具体的判断来评估此时是否足以开始构建软件构架。
  给出一致的轮廓：系统概述。一个系统构架需要现有概括的描述，开发人员才能从上千个细节甚至数十个模块或对象类中建立一致的轮廓。
  构架的目标应该能够清楚说明系统概念，构架应尽可能简化，最好的构架文件应该简单、简短，清晰而不杂乱，解决方案自然。
  构架应单先定义上层的主要子系统，应该描述各子系统的任务，并提供每个子系统中各模块或对象类的的初步列表。
  构架应该描述不同子系统间相互通信的方式，而一个良好的构架应该将子系统间的通信关系降到最低。
  成功构架的一个重要特色，在于标明最可能变更的领域，应当列出程序中最可能变更的部分，说明构架的其他部分如何应变。
  复用分析、外购：缩短软件开发周期、降低成本的有效方案未必是自行开发软件，可以对现有软件进行复用或进行外购。应考虑其对构架的影响。
  除了系统组织的问题，构架应重点考虑对于细节全面影响的设计决策，深入这些决策领域：外部软件接口（兼容性、通信方式、传递数据结构）、用户接口（用户接口和系统层次划分）、数据库组织和内容、非数据库信息、关键算法、内存管理（配置策略）、并行性、安全性、可移植性、网络多人操作、错误处理。
  要保证需求的可追踪性，即保证每个需求功能都有相应模块去实现。
  构架不能只依据静态的系统目标来设计，也应当考虑动态的开发过程，如人力资源的情况，进度要求的情况，开发环境的满足情况。构架必须支持阶段性规划，应该能够提供阶段性规划中如何开发与完成的方式。不应该依赖无法独立运行的子系统构架。将系统各部分的、依赖关系找出来，形成一套开发计划。
  六、结语
  系统构架设计和千差万别的具体的开发平台密切相关，因此在此无法给出通用的解决方案，主要是为了说明哪些因素是需要考虑的。对于每个因素的设计策略和本文未提到的因素需要软件构架设计师在具体开发实践中灵活把握。不同因素之间有时是矛盾的，构架设计时需要根据具体情况进行平衡。
 

架构设计中的方法学

架构设计是一种权衡（trade-off）。一个问题总是有多种的解决方案。而我们要确定唯一的架构设计的解决方案，就意味着我们要在不同的矛盾体之间做出一个权衡。我们在设计的过程总是可以看到很多的矛盾体：开放和整合，一致性和特殊化，稳定性和延展性等等。任何一对矛盾体都源于我们对软件的不同期望。可是，要满足我们希望软件稳定运行的要求，就必然会影响我们对软件易于扩展的期望。我们希望软件简单明了，却增加了我们设计的复杂度。没有一个软件能够满足所有的要求，因为这些要求之间带有天生的互斥性。而我们评价架构设计的好坏的依据，就只能是根据不同要求的轻���缓急，在其间做出权衡的合理性。

1.        目标 
我们希望一个好的架构能够： 

重用：为了避免重复劳动，为了降低成本，我们希望能够重用之前的代码、之前的设计。重用是我们不断追求的目标之一，但事实上，做到这一点可没有那么容易。在现实中，人们已经在架构重用上做了很多的工作，工作的成果称为框架（Framework），比如说Windows的窗口机制、J2EE平台等。但是在企业商业建模方面，有效的框架还非常的少。 
    透明：有些时候，我们为了提高效率，把实现的细节隐藏起来，仅把客户需求的接口呈现给客户。这样，具体的实现对客户来说就是透明的。一个具体的例子是我们使用JSP的tag技术来代替JSP的嵌入代码，因为我们的HTML界面人员更熟悉tag的方式。 
延展：我们对延展的渴求源于需求的易变。因此我们需要架构具有一定的延展性，以适应未来可能的变化。可是，如上所说，延展性和稳定性，延展性和简单性都是矛盾的。因此我们需要权衡我们的投入/产出比。以设计出具有适当和延展性的架构。 
简明：一个复杂的架构不论是测试还是维护都是困难的。我们希望架构能够在满足目的的情况下尽可能的简单明了。但是简单明了的含义究竟是什么好像并没有一个明确的定义。使用模式能够使设计变得简单，但这是建立在我熟悉设计模式的基础上。对于一个并不懂设计模式的人，他会认为这个架构很复杂。对于这种情况，我只能对他说，去看看设计模式。 
     高效：不论是什么系统，我们都希望架构是高效的。这一点对于一些特定的系统来说尤其重要。例如实时系统、高访问量的网站。这些值的是技术上的高效，有时候我们指的高效是效益上的高效。例如，一个只有几十到一百访问量的信息系统，是不是有必要使用EJB技术，这就需要我们综合的评估效益了。 
安全：安全并不是我们文章讨论的重点，却是架构的一个很重要的方面。

规则 

为了达到上述的目的，我们通常需要对架构设计制定一些简单的规则： 

功能分解 

顾名思义，就是把功能分解开来。为什么呢？我们之所以很难达到重用目标就是因为我们编写的程序经常处于一种好像是重复的功能，但又有轻微差别的状态中。我们很多时候就会经不住诱惑，用拷贝粘贴再做少量修改的方式完成一个功能。这种行为在XP中是坚决不被允许的。XP提倡"Once and only once"，目的就是为了杜绝这种拷贝修改的现象。为了做到这一点，我们通常要把功能分解到细粒度。很多的设计思想都提倡小类，为的就是这个目的。

所以，我们的程序中的类和方法的数目就会大大增长，而每个类和方法的平均代码却会大大的下降。可是，我们怎么知道这个度应该要如何把握呢，关于这个疑问，并没有明确的答案，要看个人的功力和具体的要求，但是一般来说，我们可以用一个简单的动词短语来命名类或方法的，那就会是比较好的分类方法。 

我们使用功能分解的规则，有助于提高重用性，因为我们每个类和方法的精度都提高了。这是符合大自然的原则的，我们研究自然的主要的一个方向就是将物质分解。我们的思路同样可以应用在软件开发上。除了重用性，功能分解还能实现透明的目标，因为我们使用了功能分解的规则之后，每个类都有自己的单独功能，这样，我们对一个类的研究就可以集中在这个类本身，而不用牵涉到过多的类。 

根据实际情况决定不同类间的耦合度

虽然我们总是希望类间的耦合度比较低，但是我们必须客观的评价耦合度。系统之间不可能总是松耦合的，那样肯定什么也做不了。而我们决定耦合的程度的依据何在呢？简单的说，就是根据需求的稳定性，来决定耦合的程度。对于稳定性高的需求，不容易发生变化的需求，我们完全可以把各类设计成紧耦合的（我们虽然讨论类之间的耦合度，但其实功能块、模块、包之间的耦合度也是一样的），因为这样可以提高效率，而且我们还可以使用一些更好的技术来提高效率或简化代码，例如Java中的内部类技术。可是，如果需求极有可能变化，我们就需要充分的考虑类之间的耦合问题，我们可以想出各种各样的办法来降低耦合程度，但是归纳起来，不外乎增加抽象的层次来隔离不同的类，这个抽象层次可以是具体的类，也可以是接口，或是一组的类（例如Beans）。我们可以借用Java中的一句话来概括降低耦合度的思想："针对接口编程，而不是针对实现编程。

设计不同的耦合度有利于实现透明和延展。对于类的客户（调用者）来说，他不需要知道过多的细节（实现），他只关心他感兴趣的（接口）。这样，目标类对客户来说就是一个黑盒子。如果接口是稳定的，那么，实现再怎么扩展，对客户来说也不会有很大的影响。以前那种牵一发而动全身的问题完全可以缓解甚至避免。 

其实，我们仔细的观察GOF的23种设计模式，没有一种模式的思路不是从增加抽象层次入手来解决问题的。同样，我们去观察Java源码的时候，我们也可以发现，Java源码中存在着大量的抽象层次，初看之下，它们什么都不干，但是它们对系统的设计起着重大的作用。 

够用就好 ：
    我们在上一章中就谈过敏捷方法很看重刚好够用的问题，现在我们结合架构设计来看：在同样都能够满足需要的情况下，一项复杂的设计和一项简单的设计，哪一个更好。从敏捷的观点来看，一定是后者。因为目前的需求只有10项，而你的设计能够满足100项的需求，只能说这是种浪费。你在设计时完全没有考虑成本问题，不考虑成本问题，你就是对开发组织的不负责，对客户的不负责。 

应用模式 

这篇文章的写作思路很多来源于对模式的研究。因此，文章中到处都可以看到模式思想的影子。模式是一种整理、传播思想的非常优秀的途径，我们可以通过模式的方式学习他人的经验。一个好的模式代表了某个问题研究的成果，因此我们把模式应用在架构设计上，能够大大增强架构的稳定性。

抽象 

架构的本质在于其抽象性。它包括两个方面的抽象：业务抽象和技术抽象。架构是现实世界的一个模型，所以我们首先需要对现实世界有一个很深的了解，然后我们还要能够熟练的应用技术来实现现实世界到模型的映射。因此，我们在对业务或技术理解不够深入的情况下，就很难设计出好的架构。当然，这时候我们发现一个问题：怎样才能算是理解足够深入呢。我认为这没有一个绝对的准则。 

一次，一位朋友问我：他现在做的系统有很大的变化，原先设计的工作流架构不能满足现在的要求。他很希望能够设计出足够好的工作流架构，以适应不同的变化。但是他发现这样做无异于重新开发一个lotus notes。我听了他的疑问之后觉得有两点问题： 

首先，他的开发团队中并没有工作流领域的专家。他的客户虽然了解自己的工作流程，但是缺乏足够的理论知识把工作流提到抽象的地步。显然，他本身虽然有技术方面的才能，但就工作流业务本身，他也没有足够的经验。所以，设计出象notes那样的系统的前提条件并不存在。

其次，开发一个工作流系统的目的是什么。原先的工作流系统运作的不好，其原因是有变化发生。因此才有改进工作流系统的动机出现。可是，毕竟notes是为了满足世界上所有的工作流系统而开发的，他目前的应用肯定达不到这个层次。 

因此，虽然做不到最优的业务抽象，但是我们完全可以在特定目的下，特定范围内做到最优的业务抽象。比如说，我们工作流可能的变化是工组流路径的变化。我们就完全可以把工作流的路径做一个抽象，设计一个可以动态改变路径的工作流架构。 

有些时候，我们虽然在技术上和业务上都有所欠缺，没有办法设计出好的架构。但是我们完全可以借鉴他人的经验，看看类似的问题别人是如何解决的。这就是我们前面提到的模式。我们不要把模式看成是一个硬性的解决方法，它只是一种解决问题的思路。Martin Fowler曾说："模式和业务组件的区别就在于模式会引发你的思考。

在《分析模式》一书中，Martin Fowler提到了分析和设计的区别。分析并不仅仅只是用用例列出所有的需求，分析还应该深入到表面需求的的背后，以得到关于问题本质的Mental Model。然后，他引出了概念模型的概念。概念模型就类似于我们在讨论的抽象。Martin Fowler提到了一个有趣的例子，如果要开发一套软件来模拟桌球游戏，那么，用用例来描述各种的需求，可能会导致大量的运动轨迹的出现。如果你没有了解表面现象之后隐藏的运动定律的本质，你可能永远无法开发出这样一个系统。 

关于架构和抽象的问题，在后面的文章中有一个测量模式的案例可以很形象的说明这个问题。 

架构的一些误解 

我们花了一些篇幅来介绍架构的一些知识。现在回到我们的另一个主题上来。对于一个敏捷开发过程，架构意味着什么，我们该如何面对架构。这里我们首先要澄清一些误解： 

误解1：架构设计需要很强的技术能力。从某种程度来说，这句话并没有很大的错误。毕竟，你的能力越强，设计出优秀架构的几率也会上升。但是能力和架构设计之间并没有一个很强的联系。即使是普通的编程人员，他一样有能力设计出能实现目标的架构。 

误解2：架构由专门的设计师来设计，设计出的蓝图交由程序员来实现。我们之所以会认为架构是设计师的工作，是因为我们喜欢把软件开发和建筑工程做类比。但是，这两者实际上是有着很大的区别的。关键之处在于，建筑设计已经有很长的历史，已经发展出完善的理论，可以通过某些理论（如力学原理）来验证设计蓝图。可是，对软件开发而言，验证架构设计的正确性，只能够通过写代码来验证。因此，很多看似完美的架构，往往在实现时会出现问题。 

误解3：在一开始就要设计出完善的架构。这种方式是最传统的前期设计方式。这也是为XP所摒弃的一种设计方式。主要的原因是，在一开始设计出完美的架构根本就是在自欺欺人。因为这样做的基本假设就是需求的不变性。但需求是没有不变的（关于需求的细节讨论，请参看拙作『需求的实践』）。这样做的坏处是，我们一开始就限制了整个的软件的形状。而到实现时，我们虽然发现原来的设计有失误之处，但却不愿意面对现实。这使得软件畸形的生长。原本一些简单的问题，却因为别扭的架构，变得非常的复杂。这种例子我们经常可以看到，例如为兼容前个版本而导致的软件复杂性。而2000年问题，TCP/IP网络的安全性问题也从一个侧面反映了这个问题的严重性。

误解4：架构蓝图交给程序员之后，架构设计师的任务就完成了。和误解2一样，我们借鉴了建筑工程的经验。我们看到建筑设计师把设计好的蓝图交给施工人员，施工人员就会按照图纸建造出和图纸一模一样的大厦。于是，我们也企图在软件开发中使用这种模式。这是非常要命的。软件开发中缺乏一种通用的语言，能够充分的消除设计师和程序员的沟通隔阂。有人说，UML不可以吗？UML的设计理念是好的，可以减轻沟通障碍问题。可是要想完全解决这个问题，UML还做不到。首先，程序员都具有个性化的思维，他会以自己的思维方式去理解设计，因为从设计到实现并不是一项机械的劳动，还是属于一项知识性的劳动（这和施工人员的工作是不同的）。此外，对于程序员来说，他还极有可能按照自己的想法对设计图进行一定的修改，这是非常正常的一项举动。更糟的是，程序员往往都比较自负，他们会潜意识的排斥那些未经过自己认同的设计。

架构设计的过程模式 

通常我们认为模式都是用在软件开发、架构设计上的。其实，这只是模式的一个方面。模式的定义告诉我们，模式描述了一个特定环境的解决方法，这个特定环境往往重复出现，制定出一个较好的解决方法有利于我们在未来能有效的解决类似的问题。其实，在管理学上，也存在这种类似的这种思维。称为结构性问题的程序化解决方法。所以呢，我们完全可以把模式的思想用在其它的方面，而目前最佳的运用就是过程模式和组织模式。在我们的文章中，我们仅限于讨论过程模式。 方法论对软件开发而言意味着什么？我们如何看待软件开发中的方法论？方法论能够成为软件开发的救命稻草吗？在读过此文后，这些疑惑就会得到解答。 
  架构设计中的方法学(1)——方法源于恐惧

方法论

  方法论的英文为Methodology，词典中的解释为：“A series of related methods or techniques”，我们可以把它定义为软件开发（针对软件开发）的一整套方法、过程、规则、实践、技术。关于方法论出现的问题，我很赞同Alistair Cockburn的一句话，“方法论源于恐惧。”出于对项目的超期、成本失控等等因素的恐惧，项目经理们从以前的经验出发，制定出了一些控制、监测项目的方法、技巧。这就是方法论产生的原因。

  在Agile Software Development一书中，作者提到了方法论的十三个要素，基本能够函盖方法论的各个方面：

  角色（Roles）、个性（Personality）、技能（Skills）、团队（Teams）、技术（Techniques）、活动（Activities）、过程（Process）、工件（Work products）、里程碑（Milestones）、标准（Standards）、质量（Quality）、工具（Tools）、团队价值（Team Values）。

  它们之间的关系可以用一幅图来表示：

   
  图 1. 方法论的十三个要素

  很多的方法论，都涉及了上面列举的十三要素中的部分要素，因此，我们可以把方法论看作是一个抽象的、无穷的超集，而现实中的方法论都是指超集的一个有限的子集而已。它们之间的关系就好像有理数和1到100之间的整数的关系一样。不论是XP，还是UI设计经验之类，都属于方法论的一个子集，只是这两个子集之间有大小的差别而已。我们还应该看到，讨论一个完备的方法论是没有意义的，因此这种方法论铁定不存在，就好像你视图穷举出所有的有理数一样荒唐。因此，我们关于一个通用的方法论的说法也是无意义的。好的方法论，比如说XP、水晶系列，它们都有一个适合的范围，因为它们了解一点，自己并不是一个无所不能的方法论。

在现实中，我们其实不断的在接触方法论。比如说，为了控制项目的进度，项目经理要求所有的开发人员每周递交一份详细的进度报告，这就是一种方法、一种技巧。如果把开发过程中的这些技巧系统的组织起来，就能够成为一种方法论。你可能会说，那一种方法论的产生也太容易了吧。不，这样产生的方法论并没有太大的实用价值，没有实用价值的方法论根本就没有存在的必要。因此，一个成功的方法论是要能够为多个的项目所接受，并且能够成功实现软件的交付的方法论。

我和我的同事在实践中做了一些试验，希望能够把一些好的方法论应用于开发团队。试验的结果很无奈，方法论实施的效果并不理想，一开始我们认为是方法本身的原因，到后来，我们发现事情并不是这么简单。在试验的过程中，开发人员一致认同方法论的优势所在，但是在实施过程中，鲜有坚持的下来的。在Agile Software Development中，我发现作者遇到了和我们一样的问题。

Alistair Cockburn在和大量的项目团队的访谈之后，写成了Agile Software Development一书。在访谈之前，他笃定自己将会发现高度精确的过程控制是成功的关键所在，结果他发现事实并非如此，他把他的发现归结为7条定律。而我在实际中的发现也包含在这七条定律中，总结起来就只有两点：沟通和反馈。

只要能够保证良好的沟通和即时的反馈，那么开发团队即使并没有采用先进的方法论，一样可以成功。相反，那些“高质量”的团队却往往由于缺乏这两个因素而导致失败（我们这里指的失败是用户拒绝使用最终的软件）。最有效，而成本也最低的沟通方法就是面对面（face to face）的沟通，而随着项目团队的变大，或是另外一些影响因素的加入（比如地理位置的隔绝），面对面的沟通越来越难实现，这导致沟通的成本逐渐加大，质量也慢慢下降。但这并不是说非面对面的沟通不可，重要的是我们需要知道不同的沟通方式的成本和质量并不相同。XP方法尤为强调面对面的沟通，通过现场客户、站立会议、结对编程等方式来保证沟通的有效。在我的经验中，一个开发团队其实是需要多种沟通方式的结合的。完全的面对面的沟通对某些团队来说是很难实现的，那么问题的关键就在于你如何应用沟通的方式来达到你希望的效果。在前不久结束的欧莱雅创业计划大赛上，有一支团队特别引人注目，他们彼此间素未谋面，仅仅凭借Internet和电话完成了高效的合作。他们虽然没有使用面对面的沟通方式，但是仍然达成了既定的目标。软件开发也是一样的，面对面的沟通是非常有必要的，但其它的沟通方式也是需要的。

再看反馈，不论是控制进度，还是保证客户的满意度，这些活动都需要管理成本。软件开发中的管理成本的一个通性就是伴随有中间产出物（intermediate delivery）。比如说我们的需求规约、分析文档、设计文档、测试计划，这些都属于中间产出物。中间产出物的增加将会带来效率下降的问题，因为开发人员的时间都花在了完成中间产出物的工作上，花在给软件新功能上的时间就减少了。而中间产出物的主要目的是两个，一个是为了保证软件如客户所愿，例如需求规约；另一个是为了作为团队中的其他成员工作的输入，例如开发计划、测试计划等。因此，我们也可以针对这两点来商讨对策，一种是采用迭代的思想，提高软件发布的频率，以保证客户的需求被确实的满足，另一种就是缩小团队的沟通范围，保证成员能够从其他人那里得到新的思路，而不是撰写规范的内部文档（内部文档指那些仅为内部开发人员之间的沟通所需要的文档）。

因此，一个软件项目的成功和你采用的开发方法论并没有直接的关系。

重量

我们根据把拥有大量artifact（RUP官方翻译为工件，意思是软件开发过程中的中间产物，如需求规约、设计模型等）和复杂控制的软件开发方法称为重型（Heavy Weight）方法，相对的，我们称artifact较少的方法为轻型（Light Weight）方法。在传统的观念中，我们认为重型方法要比轻型安全许多。因为我们之所以想出重型方法，就是由于在中大型的项目中，项目经理往往远离代码，他无法有效的了解目前的工程的进度、质量、成本等因素。为了克服未知的恐惧感，项目经理制定了大量的中间管理方法，希望能够控制整个项目，最典型的莫过于要求开发人员频繁的递交各种表示项目目前状态的报告。

在Planning XP一书中有一段讨论轻重型方法论的精辟论述，它把重型方法论归结为一种防御性的姿态（defensive posture），而把轻型方法论归结为一种渴望成功（Plan to win）的心态。如果你是采用了防御性姿态，那么你的工作就集中在防止和跟踪错误上，大量的工作流程的制定，是为了保证项目不犯错误，而不是项目成功。而这种方法也不可谓不好，但前提是如果整个团队能够满足前面所提到的两个条件的话，项目也肯定会成功，但是重型方法论的一个弊端就在于，大家都在防止错误，都在惧怕错误，因此人和人之间的关系是很微妙的，要达到充分的沟通也是很难的。最终，连对人的评价也变成是以避免错误的多寡作为考评的依据，而不是成就。我们在做试验的时候，一位项目经理开玩笑说，“方法论源自项目经理的恐惧，这没错。但最糟糕的是整个团队只有项目经理一个人恐惧，如果能够做到人人的恐惧，那大家也就没有什么好恐惧的了。”这句话提醒了我们，如果一个团队的精神就是力求成功，那么这支团队的心态就和其它的团队不同了，尤其是对待错误的心态上。根本就没有必要花费大量的精力来预防错误，错误犯了就犯了，即时改正就可以了。这其实就是渴望成功的心态。

方法论的艺术

 管理，被称为科学和艺术的融合体，而管理的艺术性部分很大程度的体现在人的管理上。我说，方法学，一样是科学和艺术的融合体。这是有依据的，其实方法论和管理学是近亲关系，管理学中有一门分支是项目管理，而在软件组织中，项目管理是非常重要的，方法学就是一种针对软件开发的一种特定的项目管理（或是项目管理的一个子集）。 

重型方法最大的一个问题就在于他不清楚或忽略了艺术这个层次，忽视了人的因素，把人做为一个计量单位，一种资源，一种线性元素。而人的要素在软件开发中是非常重要的，软件开发实际上是一种知识、智力的转移过程，最终形成的产品是一种知识产品，它的成本取决于开发者的知识价值，因此，人是最重要的因素。而人这个要素是很难衡量的，每个人都有不同的个性、想法、经验、经历，这么多复杂的因素加在一起，就导致了人的不可预见性。因此，我们强调管人的艺术。

  最简单的例子是，在重型方法中，我们的基本假设是对人的不信任。项目经理要控制项目。但不信任就会产生很多的问题，比如士气不高，计划赶不上变化，创新能力低下，跳槽率升高等等。人都是希望被尊重的，技术人员更看重这一点，而很多公司也口口声声说自己多么多么以人为本，可是采用的却是以不信任人为前提的开发方法，言行不一。我们说敏捷方法的出发点是相互信任，做到这一点是很难的，但是一旦做到了，那这个团队就是非常具有竞争力的。因此，这就产生了一个问题，在没有做到完全的相互信任之前，我们到底相不相信他人呢，这就是我提到的艺术性的问题，什么时候你要相信人？什么时候你不相信人，这些都是需要权衡的问题，也都是表现你艺术性的问题。

  敏捷方法

敏捷代表着有效和灵活。我们称那些轻型的、有效的方法为敏捷方法。在重型方法中，我们在一些不必要、重复的中间环节上浪费了太多的精力，而敏捷则避免了这种浪费。我们的文章将会重点的讨论敏捷（Agile）方法论的思想，敏捷这个名字的前身就是轻型。目前已经有了一个敏捷联盟，他们制定了敏捷宣言：

 Individuals and interactions over processes and tools.

 Working software over comprehensive documentation.

 Customer collaboration over contract negotiation.

Responding to change over following a plan.

而我对敏捷的理解包括了几个方面：

较低的管理成本和高质量的产出。软件开发存在两个极端：一个是没有任何的管理成本，所有的工作都是为了软件的产出，但是这种方式却往往导致软件开发过程的混沌，产品的低质量，团队士气的低落。另一个是大量管理活动的加入，评审、变更管理，缺陷跟踪，虽然管理活动的加入能够在一定程度上提高开发过程的有序性，但是成本却因此提高，更糟糕的是，很容易导致团队的低效率，降低创新能力。因此，敏捷方法试图寻找一个平衡点，用低成本的管理活动带来最大的产出，即软件的高质量。

 尊重人性。敏捷方法尊重人性，强调效率。软件开发可以说是一种脑力的投入，如果不能保证开发人员的自愿投入，产品就肯定要打折扣。事实多次的证明，一个愿意投入的开发人员和一个不愿意投入的开发人员效率相差在三倍以上，对组织的贡献更是在十倍以上。

 沟通和反馈是一切的基础。我们已经讨论过沟通的重要程度，而即时的反馈是拥抱变化的前提条件。

 客户是上帝。没有客户就没有一切，客户的重要性可以用一句话来形容，就是以合理的成本建造合适的软件（build the right system at the right cost）。

敏捷其实也有轻重之分，关键在于是否能够做到有效和灵活。因此，敏捷方法论提倡的一个思想是“刚好够（barely sufficient）”。不过这个“刚好够”可不是那么容易判断的。一支8个人的团队采用XP方法，随着方法的熟练使用，团队的能力在不断的增强，能够处理的问题越越来越复杂，也许他们能够处理采用重型方法的20个人团队能够处理的问题。可是如果团队的人数突然增加到12人，这支团队肯定就会出问题，他的表现可能还不如那支20个人的团队了。人数增加的时候，原先的方法肯定还做适当的调整，比如说，在原先的敏捷方法上增加一些重型方法的技巧。我们不能够要求一支6个人的团队和一支20个人的团队用同样的方法，前者可能采用轻一些的敏捷方法，后者可能采用重一些的敏捷方法，关键的问题在于，两支团队都把重点放在沟通、反馈、频繁交付软件这些关键的因素上，也就是做到有效和灵活。

  架构设计

  架构（Architecture）（也有被称为体系结构的）是软件设计中非常重要的一个环节。软件开发的过程中只要需求和架构确定之后，这个软件就基本上可以定型了。这就好比骨骼确定了，这个人的体形就不会有很大的变化。因此我选择了架构设计来讨论敏捷软件开发（需求我已经写过了）。我们在前面讨论过超集和子集的概念，因此我们接下去要讨论的架构设计也是一个很小的子集。方法论如果没有经历过多个项目的检验是不能称为成功的方法论的，我也并不认为我的架构设计就是一个好的方法论，但引玉还需抛砖，他的主要目的是为了传播一种思想。因此，我采用了模式语言（PLOP）做为写作架构设计的形式，主要的原因就是模式是一种很好的组织思想的方法。

因此，在我们接下去的历程中，我们集中讨论的东西就围绕着架构、方法学、敏捷这三个要素展开。这篇文章并不是讨论如何编码实现软件架构的，也不要单纯的把它看作架构设计的指南，其实文中的很多思想来自于方法论，因此提到的很多架构设计的思想也适用于其它工作，如果能够了解这一点，看这篇文章的收获可能会更多一些。 
架构设计中的方法学(3)——架构源自需求

从需求到架构

  在需求阶段，我们可以得到一些代表需求调研成果的中间产物。比如说，CRC卡片、基本用例模型、用户素材、界面原型、界面原型流程图

、非功能需求、变化案例等。我们在架构设计阶段的主要工作就是要把这些需求阶段的中间产物转换为架构设计阶段的中间产物。

  其实，架构设计就是要完成两项工作，一是分析，二是设计。分析是分析需求，设计则是设计软件的大致结构。很多的方法论把分析和设计两种活动分开来，但其实这两者是很难区分的，做分析的时候会想到如何设计，而思考如何设计反过来又会影响分析的效果。可以说，他们两者之间是相互联系和不断迭代的。这种形态我们将会在后面的迭代设计模式中详细的讨论。

在敏捷方法论中，需求最好是迭代进行的，也就是说一点一点的作需求。这种做法在那些需求变化快的项目中尤其适用。由于我们采用的流程是一种迭代式的流程，这里我们将会面临着如何对待上一次迭代的中间产物的问题。如果我们每一次迭代都需要修改已存在的中间产物，那么这种维护的成本未免过大。因此，敏捷方法论的基本做法是，扔掉那些已经没有用处的中间产物。还记得在第一章的时候，我们强调说软件要比文档重要。我们生成中间产物的目的都是为了生成最终的程序，对于这些已经完成作用的模型，没有必要付出额外的维护成本。

不要断章取义的采用抛弃模型的做法。因为，抛弃模型的做法需要一个适合环境的支持。后面会针对这个话题开展大范围的讨论。这里我们简单的做一个了解：

 简单化：简单的模型和简单的程序。模型和程序越复杂，就需要更多的精力来处理它们。因此，我们尽可能的简化它们，为的是更容易的处理它们。

 高效的沟通渠道：通过增强沟通的效果来减少对中间产物的需要。试想一下，如果我随时能够从客户那里得到需求的细节资料，那前期的需求调研就没有必要做的太细致。

角色的交叉轮换：开发人员之间建立起交换角色的机制，这样，能够尽量的避免各子系统诸侯割据的局面。

清晰的流程：或者我们可以称之为明确的过程。过程在方法论中向来都是一个重点，敏捷方法论也不例外。开发人员能够清楚的知道，今天做什么，明天做什么。过程不是给别人看的，而是给自己用的。

工具：好用的工具能够节省大量的时间，这里的工具并不仅仅指CASE工具，还包括了版本控制工具、自动化测试工具、画图工具、文档制作和管理工具。使用工具要注意成本和效益的问题。

标准和风格：语言不通是沟通的一个很大的障碍。语言从某个角度来看属于一种标准、一种风格。因此，一个团队如果采用同样的编码标准、文档标准、注释风格、制图风格，那么这个团队的沟通效率一定非常的高。

如果上述的环境你都不具备，或是欠缺好几项，那你的文档的模型还是留着的好。

 仅针对需求设计架构

仅针对需求设计架构的含义就是说不要做未来才有用的事情。有时候，我们会把架构考虑的非常复杂，主要的原因就是我们把很多未来的因素放入到现在来考虑。或者，我们在开发第一个产品的时候就视图把它做成一个完美的框架。以上的这两种思路有没有错呢？没有错，这只是如何看待投入的问题，有人希望开始的时候多投入一些，这样后续的投入就会节省下来。但在现实中，由于需求的不确定性，希望通过增加开始阶段的投入来将降低未来的投入往往是难以做到的，框架的设计也绝对不是能够一蹴而就的，此这种做法并不是一个好的做法。所以我们在后头会着重论述架构设计的简单性和迭代过程，也就是因为这个理由。

  模式  

模式将可以帮助我们抓住重点。为了解决设计文档编辑器引出的七个问题，一共使用了8种不同的模式。这8种模式的组合其实就是架构，因为它们解决的，都是系统中最高层的问题。 
   
  在实践中，人们发现架构也是存在模式的。比如，对于系统结构设计，我们使用层模式；对于分布式系统，我们使用代理模式；对于交互系统，我们使用MVC（模型-视图-控制器）模式。模式本来就是针对特定问题的解，因此，针对需求的特点，我们也可以采用相应的模式来设计架构。 
   
  在sun网站上提供的宠物商店的范例中，就把MVC模式的思想扩展成为架构的思想，用于提供不同的界面视图： 
   
 
   
  我们可以了解到在图的背后隐藏着的需求：系统需要支持多种用户界面，包括为普通用户提供的HTML界面，为无线用户提供的WML界面，为管理员提供的Swing界面，以及为B2B业务设计的WebService界面。这是系统最重要的需求，因此，系统的设计者就需要确定一个稳定的架构，以解决多界面的问题。相对于多界面的问题，后端的业务处理逻辑都是一致的。比如HTML界面和WML界面的功能并没有太大的差别。把处理逻辑和界面分离开来还有额外的好处，可以在添加功能的同时，不涉及界面的改动，反之亦然。这就是我们在第二篇中提到的耦合度的问题。    
  MVC模式正可以适用于解决该问题。系统使用控制器来为业务逻辑选择不同的界面，这就完成了MVC架构的设计思路。在架构设计的工作中，我们手头上有模式这样一张好牌，有什么理由不去使用它呢？ 
   抓住重点   
  在架构设计一开始，我们就说架构是一种抽象，那就是说，架构设计摒弃了具体的细节，仅仅抓住软件最高层的概念，也就是最上层、优先级最高、风险最大的那部分需求。    
  我们考虑、分析、解决一个问题，一定有一个渐进的过程。架构设计就是解决问题其中比较早期的一个阶段，我们不会在架构设计这个阶段投入过多的时间（具体的原因在下文会有讨论），因此关键点在于我们要能够在架构设计中把握住需求的重点。比如，我们在模式一节中提到了分布式系统和交互系统，分布和交互就是这两个系统的重点。那么，如果说我们面对的是一个分布式的交互系统，那么，我们就需要把这两种特性做为重点来考虑，并以此为基础，设计架构。而我们提到的宠物商店的范例也是类似的，除了MVC的架构，还有很多的设计问题需要解决，例如用于数据库访问的数据对象，用于视图管理的前端控制器，等等（具体使用到的架构模式可以访问sun的网站）。但是这些相对于MVC模式来说，属于局部的，优先级较低的部分，可以在架构确定后再来设计。    
  架构设计和领域专家    
  一个架构要设计的好，和对需求的理解是分不开的。因此在现实中，我们发现业务领域专家凭借着他对业务领域的了解，能够帮助开发人员设计出优秀的架构来。架构是需要抽象的，它是现实社会活动的一个基本模型，而业务领域的模型仅仅凭开发人员是很难设计出来的。在ERP的发展史上，我们看到MRP发展为MRPII，在发展到闭环MRP，直到发展成为现在的ERP，主要的因素是管理思想的演化，也就是说，对业务领域的理解进步了，架构才有可能进步。    
  因此，敏捷型架构设计的过程中，我们也非常强调领域专家的作用

架构设计中的方法学(4)——团队设计

团队设计是敏捷方法论中很重要的一项实践。我们这里说的团队，指的并不是复数的人。一群人就是一群人，并没有办法构成团队。要想成为团队，有很多的工作要做。
  我们之所以考虑以团队

为单位来考虑架构设计，是因为软件开发本身就不是一件个人的事情，架构设计更是如此。单个人的思维不免有考虑欠妥之处，单个人的学识也不可能覆盖所有的学科。而组织有效的团队却能够弥补这些缺憾。    
  谁来负责架构的设计？    
  在我们的印象中，总认为架构设计是那些所谓架构设计师的专属工作，他们往往拥有丰富的设计经验和相关的技能，他们不用编写代码，就能够设计出理论上尽善尽美的架构，配有精美的图例。 
   问题1：理论上设计近乎完美的架构缺乏程序的证明，在实际应用中往往会出这样那样的问题。 
   问题2：设计师设计架构带有很大的主观性，往往会忽视客户的需求，导致架构无法满足需求。 
   问题3：实现的程序员对这种架构有抵触的情绪，或是因为不理解架构而导致架构实现的失败。 
   问题4：架构师设计架构主要是依据自己的大量经验，设计出的架构不能真实的反映目前的软件需要。 
   解决办法 
    团队设计的理论依据是群体决策。和个人决策相比，群体决策的最大好处就是其结论要更加的完整。而群体决策虽然有其优点，但其缺点也是很明显的：需要额外付出沟通成本、决策效率低、责任不明确、等等。但是群体决策如果能够组织得当的话，是能够在架构设计中发挥很大的优势的

  避免象牙塔式的架构设计

  对软件来说，架构设计是一项至关重要的工作。这样的工作交给某个人是非常危险的。即便这个人再怎么聪明，他也可能会遗漏部分的细节。组织有效的团队的力量是大大超过个人的力量的，因此团队的成果较之个人的成果，在稳定性和思考的周密程度上，都要更胜一筹。

  Scott W. Ambler在其著作中给出了象牙塔式架构（ivory tower architecture）的概念：   
  An ivory tower architecture is one that is often developed by an architect or architectural team in relative isolation to the day-to-day development activities of your project team(s).    
  中国现在的软件开发行业中也逐渐出现了象牙塔式的架构设计师。这些架构师并不参与实际的程序编写，他的工作就是为项目制作出精美的架构模型，这种架构模型在理论上是相当完美的。    
  例1：在XP中，我们基本上看不到架构设计的影子。并不是说采用XP技术的团队就不需要架构设计。XP不存在专门的设计时期，它提倡使用一些简单的图例、比喻的方式来表达软件的架构，而这种的架构设计是无时无刻不在进行的。其实，XP中的设计采用的就是团队设计的方式，结队编程（Pair Programming）和代码的集体所有制（Collective Ownership）是团队设计的基础，也就是基于口述的沟通方式。通过采用这样的方式，XP几乎不需要文档来表达架构的设计。

  优秀的架构师能够充分的利用现有框架，减少软件的投入，增强软件的稳定性。这些都没有错，但是问题在于“过犹不及”。象牙塔式架构师往往会出现文章开始指出的那些问题。架构设计其实并不是非常复杂的工作，但它要求开发人员具备相关的技能、经验以及对问题域有一定的了解。开发人员往往都具有相关的技术技能（编程、数据库设计、建模），而对问题域的理解可以从用户和行业专家那里获得帮助。因此，在理论上，我们要实现架构设计的团队化是完全可能的。   
  在上面的象牙塔式架构定义中，我们看到架构师和日常的开发工作是隔绝的。这样设计出的架构有很大的局限性。在现实中，我们还会发现另外一种角色，他来自于开发团队外部，为开发人员提供相关的技术或业务的培训。这种角色称为教练，在软件开发中是非常重要的角色，不能够和象牙塔式架构设计师之间画等号。

  选择你的设计团队

  软件的架构在软件的生命周期的全过程中都很重要，也就是说，软件开发团队中的所有人员都需要和架构打交道。因此，最好的团队组织方式是所有开发人员都参与架构的设计，我们称这种方式为全员参与。全员参与的方式保证了所有开发人员都能够对架构设计提出自己的见解，综合多方面的意见，在全体开发人员中达成一致。这种方式尤其适合于一些小的团队。

  还是会有很多的团队由于种种的原因不适合采用全员参与的方式。那么，组织优秀的开发人员组成设计组也是比较好的方式。一般，我们选择那些在项目中比较重要的，有较多开发经验，或是理论扎实的那些人来组成设计组。当然，如果你考虑到为组织培养后续力量，你也可以让一些新手加入设计组，或是你觉得自己的开发力量不足，邀请外部的咨询力量介入，这完全取决于具体的情况。

  设计组不同于我们之前提到的象牙塔式架构设计师。设计组设计出来的架构只能称为原始架构，它是需要不断的反馈和改进的。因此，在架构实现中，设计组的成员将会分布到开发团队的各个领域，把架构的思想带给所有开发人员，编写代码来检验架构，并获得具体的反馈，然后所有的成员再集中到设计组中讨论架构的演进。

  团队设计中存在的问题

在团队设计的过程，我们会遇到各种各样的问题，首当其冲的就是沟通成本的问题。架构设计时，需求尚未被充分理解，软件的设计思路还处于萌发的状态。这样的情况下，团队的每位成员对软件都有独特的见解，这些可能有些是相同的，有些是互斥的。就好比盲人摸象一样，他们的观点都代表了软件的一部分或是一方面，但是没有办法代表软件的全部。

  在敏捷方法论中，我们的每一个流程都是迅速进行、不断改进的。架构设计也是一样，我们不可能在一次架构设计上花费更多的时间。而团队决策总是倾向于较长的讨论和权衡。

例2中的问题在架构设计中时有发生，纯技术的讨论很容易上升称为争吵。这种情况几乎没有办法完全避免。团队型的决策必然会发生观念的冲突。控制一定程度内的观念的冲突对团队的决策是有益，但是如果超出了这个程度就意味着失控了，需要团队领导者的调节。而更重要的，我们需要注意沟通的技巧

团队沟通

 团队进行架构设计的时候沟通是一个非常需要注意的问题，上述的情境在软件组织中是经常发生的，因为技术人员很自然认为自己的技术比别人的好，如果自己的技术受到质疑，那怕对方是抱着讨论的态度，也无异于自身的权威受到了挑战，面子是无论如何都需要捍卫的。而沟通如果带上了这样一层主观色彩，那么沟通信息的受众就会潜意识的拒绝接受信息。相反，他会找出对方话语中的漏洞，准备进行反击。因此，我们要注意培养一种良好的沟通氛围。

在实际的观察中，我发现团队沟通中存在两种角色，一种是建议者，他们经常能够提���建议。一种是质疑者，他们对建议提出否定性的看法。这两种角色是可能互换的，现在的建议者可能就是刚才的质疑者。质疑者的发言是很能打击建议者的积极性的，而在一个脑力激荡的会议中，最好是大家都能够扮演建议者的角色，这就要求沟通会议的主持者能够掌握好这一点，对建议给予肯定的评价，并鼓励大家提出新的建议。

  例2：敏捷方法非常注重的就是团队的沟通。沟通是一个很有意思的话题，讲起来会花费大量的时间，我们这里只是针对架构设计中可能存在的沟通问题做一个简单的讨论。我们这里假设一个讨论情境，这个情境来源于真实的生活：项目主管徐辉、设计师李浩、设计师罗亦明正在讨论一个新的软件架构。 "李浩你认为这个软件数据库连接部分应该如何考虑？"徐辉问。李浩想了想，"我觉得方案A不错…" "方案A肯定有问题！这个软件和上一次的又不同。"罗亦明打断了李浩的发言。 "你懂什么！你到公司才多久，方案A是经过很长时间的证明的！"发言被打断，李浩有点恼火，罗亦明进入公司没有多久，但在一些事情上老是和他唱反调。 "我进公司多久和方案A的错误有什么关系！" 在这样一种氛围中，会议的结果可想而知。良好的沟通有助于架构设计工作的开展。一个成员的能力平平的团队，可以藉由良好的沟通，设计出优秀的架构，而一个拥有一个优秀成员的团队，如果缺乏沟通，最后可能连设计都出不来。这种例子现实中可以找到很多。

 标准和风格

我们总是在不知不觉之中使用各种各样的标准和风格。在团队设计中，我们为了提高决策的效率，可以考虑使用统一的标准和风格。统一的标准和风格并不是一朝一夕形成的。因为每个人都有自己不同的习惯和经历，强制性的要求开发人员使用统一的标准（风格）容易引起开发人员的不满。因此在操作上需要注意技巧。对架构设计而言，比较重要的标准（风格）包括界面设计、流程设计、建模规范、编码规范、持久层设计、测试数据。

在我的经验中，有一些组织平时并不注意标准（风格）的积累，认为这种积累属于雕虫小技，但正是这些小技，能够非常有效的提高沟通的效率和降低开发人员的学习曲线。试想一下，如果一个团队中所有人写出的代码都是不同标准和风格的，那么理解起来肯定会困难许多。当然，我们没有必要自己开发一套标准（风格）出来，现实中有很多可以直接借用的资料。最好的标准是UML语言，我们可以从UML的官方网站下载到最新的规范，常用的编码标准更是随处可见。不过虽然有了统一的标准，如果风格不统一，同样会造成沟通的障碍。例如下图显示的类图，虽然它们表示的是同一个类，但是由于版型、可视性、详细程度的差别，看起来又很大的差别。而在其它的标准中，这种差别也是普遍存在的。因此，我们在使用了统一的标准之后，还应该使用同样的风格。Scott W. Ambler专门成立了一个网站讨论UML的建模风格的相关问题，有兴趣的读者可以做额外的阅读。    
     
  图 4. 两种风格的类图

  在统一的风格的基础上更进一步的是使用术语。使用沟通双方都了解专门的术语，可以代表大量的信息。最好的术语的范例就是设计模式的模式名。如果沟通的双方都了解设计模式，那么一方只需要说这部分的设计可以使用工厂模式，另一方就能够理解，而不用再详细的解释设计的思路。这种的沟通方式是最高效的，但它所需要的学习曲线也会比较陡。

团队设计的四明确

为了最大程度的提高团队设计的高效性，可以从4个方面来考虑：   
  1、明确目标

 泛泛的召开架构讨论会议是没有什么意义的，一个没有鲜明主题的会议也不会有什么结果。在源自需求的模式中，我们谈到说可以有非功能需求的架构，可以有功能需求的架构。因此，在进行团队设计之前，我们首先也需要确定，此次要解决什么问题，是讨论业务逻辑的架构，还是技术架构；是全局性的架构，还是各模块的架构。

  2、明确分工

我们之所以重视团队，很重要的额一个原因就是不同的成员有不同的擅长的区域。有些成员可能擅长于业务逻辑的建模，有的擅长于原型设计，有的擅长于数据库设计，有的则擅长于Web编程。你能够想象一个软件没有界面吗？（有些软件可能是这种情况）你能够想象一个软件只有数据库，而没有处理逻辑吗？因此，架构设计就需要综合的考虑各个方面，充分利用成员的优势。这就要求团队的各个成员都能够明确自己的分工。

  3、明确责权

  除了明确自己的分工，每位成员都需要清楚自己的责任。没有责任，分工就不会有任何的效力。每位成员都需要明确自己要做些什么。当然，和责任相对的，没有成员还需要知道自己的权力是什么。这些清楚了，进行高效的沟通的前提就具备了。每次架构的讨论下来，每个人都清楚，自己要做些什么，自己需要要求其他人做些什么，自己该对谁负责。如果这些问题回答不了，那这次的讨论就白费了。

  4、明确沟通方式

  这里使用沟通方式可能有一点点不恰当，为了明确的表达意思，大家可以考虑信息流这个词。一个完整架构包括几个方面，分别都由那些人负责，如何产生，产生的整个过程应该是什么样的？这样的一个信息流程，囊括了上面提到的三个明确。如果团队的每一个人都能够为架构的产生而努力，并顺利的设计出架构，那么这样的流程是完美的。如果你发现其中的一些人不知道做些什么，那么，这就是流程出问题的现象了。完美的流程还会有一个额外的副产品，架构产生之后，团队对于软件的设计已经是非常的清晰了。因为我们提倡的是尽可能多的开发人员参与架构的设计。

不仅仅是架构 讨论到这里，其实有很多的内容已经脱离了架构设计了。也就是说，很多的原则和技巧都是可以用于软件开发的其它活动的。至于哪一些活动能够利用这些方法呢？大家可以结合自己的实际情况，来思考这个问题。提示一点，关键的入手处在于目前效率较低之处。

架构设计中的方法学(5)——简单设计

XP非常强调简单的设计原则：能够用数组实现的功能决不用链表。在其它Agile方法中，简单的原则也被反复的强调。在这篇文章，我们就对简单性做一个全面的了解。   
  架构应该设计到 什么程度？

    软件的架构都是非常的复杂的，带有大量的文档和图表。开发人员花在理解架构本身上的时间甚至超出了实现架构的时间。在前面的文章中，我们提到了一些反对象牙塔式架构的一个原因，而其中的一个原因就是象牙塔式架构的设计者往往在设计时参杂进过多的自身经验，而不是严格的按照需求来进行设计。

在软件开发领域，最为常见的设计就是"Code and Fix"方式的设计，设计随着软件开���过程而增长。或者，我们可以认为这种方式根本就不能算是设计，它抱着一种船到桥头自然直的态度，可是在设计不断改动之后，代码变得臃肿且难以理解，到处充满着重复的代码。这样的情形下，架构的设计也就无从谈起，软件就像是在风雨中的破屋，濒临倒塌。

针对于这种情形，新的设计方式又出现了，Martin Fowler称这种方式为"Planned Design"。和建筑的设计类似，它强调在编码之前进行严格的设计。这也就是我们在团队设计中谈到的架构设计师的典型做法。设计师们通常不会去编程，理由是在土木工程中，你不可能看到一位设计师还要砌砖头。

 "Planned Design"较之"Code and Fix"进步了许多，但是还是会存在很多问题。除了在团队设计中我们谈的问题之外，需求变更将会导致更大的麻烦。因此，我们理所当然的想到进行"弹性设计"：弹性的设计能够满足需求的变更。而弹性的设计所付出的代价就是复杂的设计。

题外话：

这里我们谈论"Planned Design"引出的一些问题，并没有任何排斥这种方式的意思。"Planned Design"还是有很多可取之处的，但也有很多需要改进的地方。事实上，本文中我们讨论的架构设计方式，本质上也是属于"Planned Design"方式。和"Planned Design"相对应的方式是XP所主张的"Evolutionary Design"方式，但是这种方式还有待于实践的检验，并不能简单的说他就一定要比"Planned Design"先进或落后。但可以肯定的一点是："Evolutionary Design"方式中有很多的思想和技巧是值得"Planned Design"借鉴的。

解决方法：

XP中有两个非常响亮的口号："Do The Simplest Thing that Could Possibly Work"和"You Aren't Going to Need It"（通常称之为YAGNI）。他们的核心思想就是不要为了考虑将来，把目前并不需要的功能加到软件中来。

粗看之下，会有很多开发人员认为这是不切实际的口号。我能理解这种想法，其实，在我热衷于模式、可重用组件技术的时候，我对XP提倡的简单的口号嗤之以鼻。但在实际中，我的一些软件因为复杂设计导致开发成本上升的时候，我重新思考这个问题，发现简单的设计是有道理的。

 降低开发的成本

不论是模式，可重用组件，或是框架技术，目的都是为了降低开发的成本。但是他们的方式是先进行大量的投入，然后再节省后续的开发成本。因此，架构设计方面的很多思路都是围绕着这种想法展开的，这可能也是导致开发人员普遍认为架构设计高不可攀的原因。XP的方式恰恰相反，在处理第一个问题的时候，不必要也不可能就设计出具有弹性、近乎完美的架构来。这项工作应该是随着开发的演进，慢慢成熟起来的。我不敢说这种方式肯定正确，但是如果我们把生物的结构视同为架构，这种方式不是很类似于自然界中生物的进化方式吗？

在一开始就制作出完美的架构的设想并没有错，关键是很难做到这一点。总是会有很多的问题是你在做设计时没有考虑到的。这样，当一开始花费大量精力设计出的"完美无缺"的架构必然会遇到意想不到的问题，这时候，复杂的架构反而会影响到设计的改进，导致开发成本的上升。这就好比如果方向错了，交通工具再快，反而导致错误的快速扩大。Martin Fowler在他的论文中说，"Working on the wrong solution early is even more wasteful than working on the right solution early"（提前做一件错事要比提前做一件对的事更浪费时间），相信也是这个道理。

更有意思的是，通常我们更有可能做错。在我们进行架构设计的时候，我们不可能完全取得详细的需求。事实上，就算你已经取得了完整的需求，也有可能发生变化。这种情况下做出的架构设计是不可能不出错的。这样，浪费大量的时间在初始阶段设计不可能达到的"完美架构"，倒不如把时间花在后续的改进上。

提升沟通的效率 

我们在团队设计中已经谈过了团队设计的目标之一就是为了降低沟通的成本，以期让所有人都能够理解架构。但是如果架构如果过于复杂，将会重新导致沟通成本的上升，而且，这个成本并不会随着项目进行而降低，反而会因为上面我们提到的遇到新的问题导致沟通成本的持续上升。

简单的架构设计可以加快开发团队理解架构的速度。我们可以通过两种方式来理解简单的含义。首先，简单意味着问题的解不会非常的复杂，架构是解决需求的关键，无论需求再怎么复杂多变，总是可以找出简单稳定的部分，我们可以把这个简单稳定的部分做为基础，再根据需要进行改进扩展，以解决复杂的问题。在示例中，我们提到了measurement pattern，它就是按照这种想法来进行设计的。

其次，简单性还体现在表示的简单上。一份5页的文档就能够表达清楚的架构设计为什么要花费50页呢？同样的道理，能够用一副简单的图形就能够表示的架构设计也没有必要使用文档。毕竟，面对面的沟通才是最有效率的沟通，文档不论如何的复杂，都不能被完全理解，而且，复杂的文档，维护起来也需要花费大量的时间。只有在两种情况下，我们提倡使用复杂的文档：一是开发团队没有办法做到面对面沟通；二是开发成果要作为团队的知识积累起来，为下一次开发所用。

考虑未来

  我们之所以考虑未来，主要的原因就是需求的不稳定。因此，我们如果考虑未来可能发生的需求变化，就会不知觉的在架构设计中增加复杂的成分。这违背的简单的精神。但是，如果你

不考虑可能出现的情况，那些和目前设计格格不入的改变，将会导致大量的返工。

还记得YAGNI吗？原则上，我们仍然坚持不要在现有的系统中为将来可能的情况进行设计。但是，我们必须思考，必须要为将来可能出现的情况做一些准备。其实，软件中了不起的接口的思想，不就是源于此吗？因此，思考未来，但等到需要时再实现。

变更案例有助于我们思考未来，变更案例就是你在将来可能要（或可能不要）满足的，但现在不需要满足的需求。当我们在做架构设计的时候，变更案例也将会成为设计的考虑因素之一，但它不可能成为进行决策的唯一考虑因素。很多的时候，我们沉迷于设计通用系统给我们带来的挑战之中，其实，我们所做的工作对用户而言是毫无意义的。

架构的稳定 
   架构简单化和架构的稳定性有什么关系吗？我们说，架构越简单，其稳定性就越好。理由很简单，1个拥有4个方法和3个属性的类，和1个拥有20个方法和30属性的类相比，哪一个更稳定？当然是前者。而架构最终都是要映射到代码级别上的，因此架构的简单将会带来架构的稳定。尽可能的让你的类小一些，尽可能的让你的方法短一些，尽可能的让类之间的关系少一些。这并不是我的忠告，很多的设计类的文章都是这么说的。在这个话题上，我们可以进一步的阅读同类的文章（关于 refactoring 的思考）。

辨正的简单

因此，对我们来说，简单的意义就是不要把未来的、或不需要实现的功能加入到目前的软件中，相应的架构设计也不需要考虑这些额外的需求，只要刚好能够满足当前的需求就好了。这就是简单的定义。可是在现实之中，总是有这样或者那样的原因，使得设计趋向复杂。一般来说，如果一个设计对团队而言是有价值的，那么，付出一定的成本来研究、验证、发展、文档化这个设计是有意义的。反之，如果一个设计没有很大的价值或是发展它的成本超过了其能够提供的价值，那就不需要去考虑这个设计。

价值对不同的团队来说具有不同的含义。有时候可能是时间，有时候可能是用户价值，有时候可能是为了团队的设计积累和代码重用，有时候是为了获得经验，有时候是为了研究出可重用的框架（FrameWork）。这些也可以称为目的，因此，你在设计架构时，请注意先确定好你的目的，对实现目的有帮助的事情才考虑。

Scott W.Ambler在他的文章中提到一个他亲身经历的故事，在软件开发的架构设计过程中，花了很多的时间来设计数据库到业务逻辑的映射架构，虽然这是一件任何开发人员都乐意专研的事情（因为它很酷）。但他不得不承认，对用户来说，这种设计先进的架构是没有太大的意义的，因为用户并不关心具体的技术。当看到这个故事的时候，我的触动很大。一个开发人员总是热衷于新奇的技术，但是如果这个新奇技术的成本由用户来承担，是不是合理呢？虽然新技术的采用能够为用户带来效益，但是没有人计算过效益背后的成本。就我开发过的项目而言，这个成本往往是大于效益的。这个问题可能并没有确定的答案，只能是见仁见智了。

简单并不等于实现简单

说到这里，如果大家有一个误解，认为一个简单的架构也一定是容易设计的，那就错了。简单的架构并不等于实现起来也简单。简单的架构需要设计者花费大量的心血，也要求设计者对技术有很深的造诣。在我们正在进行的一个项目中，一开始设计的基础架构在实现中被修改了几次，但每修改一次，代码量都减少一分，代码的可读性也就增强一分。从心理的角度上来说，对自己的架构进行不断的修改，确实是需要一定的勇气的。因为不论是设计还是代码，都是开发人员的心血。但跨出这一步是值得的。

下面的例子讨论了Java的IO设计，Java类库的设计应该来说是非常优秀的，但是仍然避免不了重新的修改。实际上，在软件开发领域，由于原先的设计失误而导致后来设计过于复杂的情况比比皆是（例如微软的OLE）。同样的，我们在设计软件的时候，也需要对设计进行不断的修改。能够实现复杂功能，同时自身又简单的设计并不是一件容易的事情。

例1.           Java的IO系统 
  从Java的IO系统设计中，我们可以感受到简单设计的困难。

例2.        IO系统设计的困难性向来是公认的。Java的IO设计的一个目的就是使IO的使用简单化。在Java的1.0中，Java的IO系统主要是把IO系统分为输入输出两个大部分，并分别定义了抽象类InputStream和OutputStream。从这两个的抽象类出发，实现了一系列不同功能的输入输出类，同时，Java的IO系统还在输入输出中实现了FilterInputStream和FilterOutputStream的抽象类以及相关的一系列实现，从而把不同的功能的输入输出函数连接在一起，实现复杂的功能。这个实现其实是Decorator模式（由于没有看过源码和相关的资料，这里仅仅是根据功能和使用技巧推测，如果大家有不同的意见，欢迎来信讨论）。 
  因此，我们可以把多个对象叠加在一起，提供复杂的功能： 
  DataInpuStream in = 
  new DataInputStream( 
  new BufferedInputStream( 
  new FileInputStream("test.txt"); 
   
  上面的代码使用了两个FilterInputStream：DataInpuStream和BufferedInputStream，以实现读数据和缓冲的功能，同时使用了一个InputStream：FileInputStream，从文件中读取流数据。虽然使用起来不是很方便，但是应该还是非常清晰的设计。 
  令设计混乱的是既不属于InputStream，也不属于OutputStream的类，例如RandomAccessFile，这正表明，由于功能的复杂化，使得原先基于输入输出分类的设计变得混乱，根据我们的经验，我们说设计需要Refactoring了。因此，在Java1.1中，IO系统被重新设计，采用了Reader和Writer位基础的设计，并增加了新的特性。但是目前的设计似乎更加混乱了，因为我们需要同时使用1.0和1.1两种不同的IO设计

 架构设计中的方法学(6)——迭代设计

　　迭代是一种软件开发的生命周期模型，在设计中应用迭代设计，我们可以得到很多的好处。

　　在软件生命周期中，我们如何对待架构设计的发展？

　　架构设计往往发生在细节需求尚未完成的时候进行的。因此，随着项目的进行，需求还可能细化，可能变更。原先的架构肯定会有不足或错误的地方。那么，我们应该如何对待原先的设计呢？

　　我们在简单设计模式中简单提到了"Planned Design"和"Evolutionary Design"的区别。XP社团的人们推崇使用"Evolutionary Design"的方式，在外人看来，似乎拥护者们从来不需要架构的设计，他们采用的方式是一开始就进入代码的编写，然后用Refactoring来改进代码的质量，解决未经设计导致的代码质量低下的功能。

　　从一定程度上来说，这个观点并没有错，它强调了代码对软件的重要性，并通过一些技巧（如Refactoring）来解决缺乏设计的问题。但我并不认同"Evolutionary Design"的方式，在我看来，一定程度上的"Planned Design"是必须的，至少在中国的软件行业中，"Planned Design"还没有成为主要的设计方向。借用一句明言，"凡事预则立，不预则废"，在软件设计初期，投入精力进行架构的设计是很有必要的，这个架构是你在后续的设计、编码过程中依赖的基础。但是，一开始我们提到的设计改进的问题依然存在，我们如何解决它呢？

　　在简单设计模式中，我们提到了设计改进的必要性，但是，如果没有一种方法去控制设计的改进的话，那么设计改进本身就是一场噩梦。因此，何时改进，怎么改进，如何控制，这都是我们需要面对的问题。

　　解决方法

　　为了实现不断的改进，我们将在开发流程中引入迭代的概念。迭代的概念在《需求的实践》中已经提到，这里我们假设读者已经有了基本的迭代的概念。

　　软件编码之前的工作大致可以分为这样一个工作流程：

　　上图中的流程隐含着一个信息的损失的过程。来自于用户的需求经过整理之后，开发人员就会从中去掉一些信息，同样的事情发生在后面的过程中，信息丢失或变形的情况不断的发生。这里发生了什么问题？应该说，需求信息的失真是非常普遍的，我们缺少的是一种有效的办法来抑止失真，换句话说，就是缺少反馈。

　　如果把眼睛蒙上，那我们肯定没有办法走出一条很长的直线。我们走路的时候都是针对目标不断的调整自己的方向的。同样的，漫长的软件开发过程如果没有一种反馈机制来调整方向，那最后的软件真是难以想象。

　　所以我们引入了迭代周期。
　　初始设计和迭代设计 
　　在团队设计中，我们一直在强调，设计组最开始得到的设计一定只是一个原始架构，然后把这个原始架构传播到每一位开发者的手中，从而在开发团队中形成共同的愿景。（愿景（Vision）：源自于管理学，表示未来的愿望和景象。这里借用来表示软件在开发人员心中的样子。在后面的文章中我们会有一个章节专门的讨论架构愿景。）

　　迭代（Iterate）设计，或者我们称之为增量（Incremental）设计的思想和XP提倡的Evolutionary Design有异曲同工之妙。我们可以从XP、Crystal、RUP、ClearRoom等方法学中对比、体会迭代设计的精妙之处：每一次的迭代都是在上一次迭代的基础上进行的，迭代将致力于重用、修改、增强目前的架构，以使架构越来越强壮。在软件生命周期的最后，我们除了得到软件，还得到了一个非常稳定的架构。对于一个软件组织来说，这个架构很有可能就是下一个软件的投入或参考。

　　我们可以把早期的原始架构当作第一次迭代前的早期投入，也可以把它做为第一次迭代的重点，这些都是无所谓的。关键在于，原始架构对于后续的架构设计而言是非常重要的，我们讨论过架构是来源于需求的，但是原始架构应该来源于那些比较稳定的需求。

　　TIP：现实中迭代设计退化为"Code and Fix"的设计的情况屡见不鲜（"Code and Fix"参见简单设计）。从表面上看，两者的做法并没有太大的差别，都是针对原有的设计进行改进。但是，二者效果的差别是明显的："Code and Fix"是混沌的，毫无方向感可言，每一次的改进只是给原先就已摇摇欲坠的积木上再加一块积木而已。而迭代设计的每一次改进都朝着一个稳定的目标在前进，他给开发人员带来信心，而不是打击。在过程上，我们说迭代设计是在控制之下的。从实践的经验中，我们发现，把原该在目前就该解决的问题退后是造成这一问题的主要原因之一。因此，请严格的对待每一次的迭代，确保计划已经完成、确保软件的质量、确保用户的需求得到满足，这样才是正统的迭代之路。

　　单次的迭代 
　　我们说，每一次的迭代其实是一个完整的小过程。也就是说，它同样要经历文章中讨论的这些过程模式。只不过，这些模式的工作量都不大，你甚至可以在很短的时间内做完所有的事情。因此，我们好像又回到了文章的开头，重新讨论架构设计的过程。

　　单次迭代最令我们兴奋的就是我们总是可以得到一个在当前迭代中相当稳定的结果，而不像普通的架构设计那样，我们深怕架构会出现问题，但又不得不依赖这个架构。从心理上来分析，我们是在持续的建设架构中，不需要回避需求的变更，因为我们相信，在需求相对应的迭代中，会继续对架构进行改进。大家不要认为这种心理的改变是无关紧要的，我起初并没有意识到这个问题，但是我很快发现新的架构设计过程仍然笼罩在原先的惧怕改变的阴影之下的时候，迭代设计很容易就退化为"Code and Fix"的情形。开发人员难以接受新方法的主要原因还是在心理上。因此，我不得不花了很多的时间来和开发人员进行沟通，这就是我现实的经验。

　　迭代的交错 
　　基于我们对运筹学的一点经验，迭代设计之间肯定不是线性的关系。这样说的一个原因架构设计和后续的工作间还是时间差的。因此，我们不会傻到把时间浪费在等待其它工作上。一般而言，当下一次迭代的需求开始之后，详细需求开始之前，我们就已经可以开始下一次迭代的架构设计了。

　　各次迭代之间的时间距离要视项目的具体情况而定。比如，人员比较紧张的项目中，主要的架构设计人员可能也要担任编码人员的角色，下一次迭代的架构设计就可能要等到编码工作的高峰期过了之后。可是，多次的交错迭代就可能产生版本的问题。比如，本次的迭代的编码中发现了架构的一个问题，反馈给架构设计组，但是架构设计组已经根据伪修改的本次迭代的架构开始了下一次迭代的架构设计，这时候就会出现不同的设计之间的冲突问题。这种情况当然可以通过加强对设计模型的管理和引入版本控制机制来解决，但肯定会随之带来管理成本上升的问题，而这是不符合敏捷的思想的。这时候，团队设计就体现了他的威力了，这也是我们在团队设计中没有提到的一个原因。团队设计通过完全的沟通，可以解决架构设计中存在冲突的问题。 
　　迭代频率 
　　XP提倡迭代周期越短越好（XP建议为一到两周），这是个不错的提议。在这么短的一个迭代周期内，我们花在架构设计上的时间可能就只有一两个小时到半天的时间。这时候，会有一个很有意思的现象，你很难去区分架构设计和设计的概念了。因为在这么短的一个周期之内，完成的需求数量是很少的，可能就只有一两个用例或用户素材。因此，这几项需求的设计是不是属于架构设计呢？如果是的话，由于开发过程是由多次的迭代组成的，那么开发过程中的设计不都属于架构设计了吗？我们说，架构是一个相对的概念，是针对范围而言的，在传统的瀑布模型中，我们可以很容易的区分出架构设计和普通设计，如果我们把一次迭代看作是一个单独的生命周期，那么，普通的设计在这样一个范围之内也就是架构设计，他们并没有什么两样。但是，迭代周期中的架构设计是要遵循一定的原则的，这我们在下面还会提到。

　　我们希望迭代频率越快越好，但是这还要根据现实的情况而定。比如数据仓库项目，在项目的初期阶段，我们不得不花费大量的时间来进行数据建模的工作，这其实也是一项专门针对数据的架构设计，建立元数据，制定维，整理数据，这样子的过程很难分为多次的迭代周期来实现。 
　　如何确定软件的迭代周期 
　　可以说，如果一支开发团队没有相关迭代的概念，那么这支团队要立刻实现时隔两周迭代周期是非常困难的，，同时也是毫无意义的。就像我们在上面讨论的，影响迭代周期的因素很多，以至于我们那无法对迭代周期进行量化的定义。因此我们只能从定性的角度分析迭代周期的发展。

　　另一个了解迭代的方法是阅读XP的相关资料，我认为XP中关于迭代周期的使用是很不错的一种方法，只是他强调的如此短的迭代周期对于很多的软件团队而言都是难以实现的。

　　迭代周期的引入一定是一个从粗糙到精确的过程。迭代的本质其实是短周期的计划，因此这也是迭代周期越短对我们越有好处的一大原因，因为时间缩短了，计划的可预测性就增强了。我们知道，计划的制定是依赖于已往的经验，如果原先我们没有制定计划或细节计划的经验，那么我们的计划就一定是非常粗糙，最后的误差也一定很大。但是这没有关系，每一次的计划都会对下一次的计划产生正面的影响，等到经验足够的时候，计划将会非常的精确，最后的误差也会很小。

　　迭代周期的确定需要依赖于单位工作量。单位工作量指的是一定时间内你可以量化的最小的绩效。最简单的单位工作量是每位程序员一天的编码行数。可惜显示往往比较残酷，团队中不但有程序员的角色，还有设计师、测试人员、文档制作人员等角色的存在，单纯的编码行数是不能够作为唯一的统计依据的。同样，只强调编码行数，也会导致其它的问题，例如代码质量。为了保证统计的合理性，比较好的做法是一个团队实现某个功能所花费的天数作为单位工作量。这里讨论的内容实际是软件测量技术，如果有机会的话，再和大家探讨这个问题。 
　　迭代周期和软件架构的改进

　　我们应用迭代方法的最大的目的就是为了稳步的改进软件架构。因此，我们需要了解架构是如何在软件开发的过程中不断演进的。在后面的文章中，我们会谈到用Refactoring的方法来改进软件架构，但是Refactoring的定义中强调，Refactoring必须在不修改代码的外部功能的情况下进行。对于架构来说，我们可以近乎等价的认为就是在外部接口不变的情况下对架构进行改进。而在实际的开发中，除非非常有经验，否则在软件开发全过程中保持所有的软件接口不变是一件非常困难的事情。因此，我们这里谈的架构的改进虽然和Refactoring有类似之处，但还是有区别的。

　　软件架构的改进在软件开发过程会经历一个振荡期，这个振荡期可能横跨了数个迭代周期，其间架构的设计将会经历剧烈的变化，但最后一定会取向于平稳。（如果项目后期没有出现设计平稳化的情况，那么很不幸，你的项目注定要失败了，要么是时间的问题，要么就是需求的问题）。关键的问题在于，我们有没有勇气，在架构需要改变的时候就毅然做出变化，而不是眼睁睁的看着问题变得越来越严重。最后的例子中，我们讨论三个迭代周期，假设我们在第二个周期的时候拒绝对架构进行改变，那么第三个周期一定是有如噩梦一般。变化，才有可能成功。

　　我们知道变化的重要性，但没有办法知道变化的确切时间。不过我们可以从开发过程中嗅到架构需要变化的气味：当程序中重复的代码逐渐变多的时候，当某些类变得格外的臃肿的时候，当编码人员的编码速度开始下降的时候，当需求出现大量的变动的时候。
　　实例 
　　从这一周开始，我和我的小组将要负责对软件项目中的表示层的设计。在这个迭代周期中，我们的任务是要为客户端提供6到10个的视图。由于视图并不很多，表示层的架构设计非常的简单：

　　准确的说，这里谈不上设计，只是简单让客户端访问不同的视图而已。当然，在设计的示意图中，我们并没有必要画出所有的视图来，只要能够表达客户端和视图的关联性就可以了。

　　（架构设计需要和具体的实现绑定，但是在这个例子中，为了着重体现设计的演进，因此把不必要的信息都删掉。在实际的设计中，视图可能是JSP页面，也可能是一个窗口。）

　　第一个迭代周的任务很快的完成了，小组负责的表示层模块也很顺利的和其它小组完成了对接，一个简陋但能够运转的小系统顺利的发布。客户观看了这个系统的演示，对系统提出了修改和补充。

　　第二���迭代周中，模块要处理的视图增加到了30个，视图之间存在相同的部分，并且，负责数据层的小组对我们说，由于客户需求的改进，同一个视图中将会出现不同的数据源。由于我们的视图中直接使用了数据层小组提供给我们的数据源的函数，这意味着我们的设计需要进行较大的调整。

　　考虑到系统的视图的量大大的增加，我们有必要对视图进行集中的管理。前端控制器（Front Control）模式将会是一个不错的技巧。对于视图之间的普遍的重复部分，可以将视图划分为不同的子视图，再把子视图组合为各种各样的视图。这样我们就可以使用组合（Composite）模式：

客户的请求集中提交给控制器，控制器接受到客户的请求之后，根据一定的规则，来提供不同的视图来反馈给客户。控制器是一个具有扩展能力的设计，目前的视图数量并不多，因此仍然可以使用控制器来直接分配视图。如果视图的处理规则比较复杂，我们还可以使用创建工厂（Create Factory）模式来专门处理生成视图的问题。对于视图来说，使用组合模式，把多个不同数据源的视图组合为复杂的视图。例如，一个JSP的页面中，可能需要分为头页面和尾页面。

项目进入第三个迭代周期之后，表示层的需求进一步复杂化。我们需要处理权限信息、需要处理数据的合法性判断、还需要面对更多的视图带来的复杂程度上升的问题。

　　表示层的权限处理比较简单，我们可以从前端控制器中增加权限控制的模块。同时，为了解决合法性判断问题，我们又增加了一个数据过滤链模块，来完成数据的合法性判断和转换的工作。为了不使得控制器部分的功能过于复杂，我们把原先属于控制器的视图分发功能转移到新的分发器模块，而控制器专门负责用户请求、视图的控制。

我们来回顾这个例子，从迭代周期1中的需求最为简单，其实，现实中的项目刚开始的需求虽然未必会像例子中的那么简单，但一定不会过于复杂，因此迭代周期1的设计也非常的简单。到了迭代周期2的时候，需求开始变得复杂，按照原先的架构继续设计的话，必然会导致很多的问题，因此对架构进行改进是必要的。我们看到，新的设计能够满足新的需求。同样的，迭代周期3的需求更加的复杂，因此设计也随之演进。这就是我们在文章的开始提到的"Evolutionary Design"的演进的思想。

架构设计中的方法学(7)——组合使用模式

我们已经讨论了敏捷架构设计的4种过程模式，在本文中，我们对这四种过程模式做一个小结，并讨论4者间的关系以及体现在模式中的敏捷方法论特色。通过这一章的描述，大家能够对前面的内容有更进一步的了解。    
   四种模式的着重点  我把源自需求、团队设计、简单设计、迭代设计这4种过程模式归类为架构设计的第一层次，这4种模式能够确定架构设计过程的框架。这里需要对框架的含义进行澄清：架构设计的框架并不是说你要严格的按照文中介绍的内容来进行架构设计，在文章的一开始我们就指出，模式能够激发思考。因此，这一框架是需要结合实际，进行改造的。实际，我们在这一个部分中介绍的，比较偏向于原则，我们花了很大的时间来讨论原则的来龙去脉，而原则的度，则要大家自己去把握。为什么我们不讨论原则的度呢？这里有两个原因，一个是软件开发团队各有特色，很难定义出一个通用的度。第二个原因是我的水平不够，实践经验也不够丰富。  前面提到的四种模式其实是从四个侧面讨论了架构设计中的方法问题。源自需求提供了架构设计的基础。在软件过程中，架构设计是承接于需求分析的，如果没有良好的需求分析活动的支持，再好的架构设计也没有用。因此我们把这一模式放在首位，做为架构设计的目标。  有了确定的目标，还需有组织的保证，这也就是第二种模式――团队设计的由来。敏捷方法提倡优秀的沟通，因此团队设计是必要且有效的。而团队设计的另一个意图，是保证架构设计的下游活动得以顺利的进行，例如详细设计、编码、测试等。由于开发团队中的人大都加入了架构设计，因此最大程度的减小了不同的活动间的信息损耗和沟通效率低下的问题。如果说源自需求模式是起承上的作用，那么团队设计模式则是扮演了启下的角色。  在软件设计的过程中，沟通往往扮演着非常重要的角色。从团队设计开始的几种模式所要解决的都是沟通的问题。团队设计对沟通的贡献在于它能够把设计意图以最小的代价传播到开发团队的每个角落。这样，设计和下游的活动间由于沟通不畅产生的问题就能够得到缓解。一般而言，设计到编码会经历一个信息损失的过程，编码人员无法正确理解设计人员的意图，设计人员却往往无法考虑到一些编码的细节。虽然我们可以通过共通的设计符号来提高沟通的质量，例如UML。但是实践证明，只要能够保证畅通的沟通，即便没有优秀的开发方法，项目成功的概率依然很高。因此对于单个的项目来说，最关键的问题还是在于沟通。只要组织得当，团队设计是一个值得应用的模式。当然，配合以UML为代表的建模语言，更能够提高沟通的效果。 
   
  在设计中，我们发现，当设计信息转换为编码信息需要一定的时间，这个时间包括设计的组织时间，设计被理解的时间。如果设计比较复杂，或者说设计的文档比较复杂，编码人员花在理解上的时间就会大大增加。因此，权衡后的结果是，相对于详细的设计说明书而言，简单的设计说明书再配合一定程度的面对面沟通能够起到更好的效果。"简单要比复杂有效"，这就是简单设计模式的基本思路。    
  同样，简单的思路还会用在软件开发的各个方面，例如文档、设计、流程。坚持简单的原则，并不断的加以改进，是降低软件开发成本的一种很有效的做法。   
  在有了以上的思路之后，我们还需要面对两个现实的问题。需求的变化将会导致设计的不稳定，而需求的复杂性又会导致简单架构设计的困难。为了解决这个问题，我们引入了迭代的方法，将问题分割为多个子问题（把一个复杂的问题分解为多个较简单的子问题是计算机领域最常见的处理方法）。这样，问题的范围和难度都大大降低了。而更关键的是，由于对用户需求理解不充分或用户表达需求有错导致的设计风险被降到最低点。迭代和前面几个模式都有关系。    
  需求和迭代    
  源自需求模式是架构设计中的起手式，没有这一模式的支持，架构设计只能是空中楼阁。其实，源自需求模式严格意义上并不能算是敏捷方法论的特色，而应该算是软件开发的天然特性。不幸的是，就是这么一个基本的原则，却没能够引起开发者足够的重视。    
  敏捷方法论中把需求摆在一个非常重要的位置，我们把源自需求模式作为架构设计的第一个模式，主要的目的是承接架构设计的上游工作――需求。需求决定架构，因此，我们在经典的瀑布模型中可以看到需求到设计的严格的分界线，但是在实际的开发中，按照瀑布模型的理论往往会遇到很多的问题，所以，我们尝试着把需求和（架构）设计之间的界限打破，形成一个重叠的地带，从而提高软件开发的速度。因此，我们在源自需求模型中指出，架构设计是紧随着需求开始的。    
  需求对软件开发最具影响就是需求的不稳定性。我们都非常的清楚软件开发的曲线，越到软件开发的后期，修改软件的成本越高。因此，在软件开发上游的需求的变动将会对软件开发的下游产生天翻地覆的影响。为了协调这一矛盾，软工理论提出了螺旋开发模型，这就是我们在迭代开发模式中的讨论的理论基础。把软件开发过程分为多个的迭代周期，每一次的迭代周期最后都将生成一个可交付的软件，用户在每一次的迭代结束后，可以试用软件，提出下一步的需求或是改变原先的需求。通过这样的方式，把客户、开发商的风险降到一个可以接受的水平上。

请注意迭代的前提：需求的易变性。因此，对于那些需求容易发生变化的项目，我们就可以使用迭代式的开发过程，虽然我们会付出一些额外的成本（刚开始这个成本会比较大，但可以用较长的迭代周期来降低这种成本），但是风险减小了。而对于需求比较固定的项目，

是不是有必要使用迭代的方法，就要看具体的环境了。因此，我们是根据实际的情况选用开发方法，而不是因为先进或是流行的原因。

  实际上，由于现代社会的特性，大部分的项目都是可以采用迭代方法。因此，我们的选择就变成了了迭代周期应该要多长。迭代周期在理论上应该是越短越好，但是并没有一个绝对的数值，时间的跨度一般从几周到几个月。一般来说，迭代周期会受到几个因素的影响：

  各模块的关联程度。在软件开发中，我们有时候很难把一些模块分离开来，要开发模块A，就需要模块B，而模块B又需要模块C。各模块的关联程度越高，迭代周期越长。当然，也相应的解决方法，我们可以在各模块的功能中选取出一些关键点，作为里程碑，以里程碑作为迭代完成点。

  人员技能、经验的平均程度。团队中成员的开发能力、开发经验良莠不齐，这也是造成迭代周期延长的一个原因。能力低、经验少的开发人员会拖后每一次迭代的时间。针对这种情况，做好统筹规划就显得非常的重要，可以通过一两次的迭代，找出队伍中的瓶颈人员，安排相应的对策。

  工具的缺乏。迭代周期越短，就意味着build、发布的次数越多，客户也就有更多的机会来修改需求。这要求有相关的工具来帮助开发人员控制软件。最重要的工具是回归测试工具。每一次迭代都需要增加新的功能，或是对原先的功能进行改动，这就有可能引入新的bug，如果没有回归测试，开发人员就需要花费时间重新测试原先的功能。

计划、控制的能力。迭代周期越短，所需要的计划、控制的能力就越强。因为短时间内的计划制定和实施需要高度的细分，这就要求开发团队的管理者对开发能力、工作量、任务分配有很强的认识，才能做好这项工作。不过，迭代周期越短，同样开发时间的迭代次数就越多，而团队调整、改进计划控制的机会就越多。因此，后期的迭代一般都能够做到比较精确的控制。而这样的做法，要比问题堆积到软件交付日才爆发出来要好的多。没有突然落后的软件，只有每天都在落后的软件。

  简单和迭代

  简单和迭代关系是双向的。

  在现实设计我们很难界定出简单设计的程度。怎样的架构设计才算是简单？按照我们在简单设计模式中的讨论，刚好满足目前的需求的架构设计就算是简单的设计。但是，从另外一个方面考虑，需求的易变性限制我们做出简单的设计，因为我们不能够肯定目前的需求将来会发生什么样的变化。因此，为了克服对未知的恐惧，我们花了很大的力气设计一些灵活的、能够适应变化的架构。这是源自需求模式对简单设计模式的影响。

  源自需求和迭代设计的关系的讨论建议我们把需求分为多个迭代周期来实现。那么，相应的架构设计也被分在多个迭代周期中。这样的方法可以降低架构设计的复杂程度。因为设计人员不需要考虑软件的全部需求，而只需要考虑当前迭代周期的需求。复杂性的降低将会有助于架构设计的简单化，从而达到简单设计的一系列的好处（参见简单设计）。

  我们从迭代设计中的最后一个例子可以清楚的看到迭代设计是如何把复杂的需求给简单化的。把握迭代设计有助于我们避免过分设计的毛病。这是个技术人员经常犯的毛病。我所在的团队很多时候也无法避免。例如，在很多的项目中，我们都会花费大量的时间来设计数据库到业务实体的映射。诸如此类的技术问题对开发人员的吸引程度是不言而喻的，但是必须看到，这种的设计会导致开发成本的大幅度上升。更为糟糕的是，除非有丰富的经验，这种类型的设计给开发工作带来的价值往往无法超过其成本。

  因此，我们需要学会权衡利弊，是否有必要投入大量的资源来开发其实并没有那么有用的功能。因此，迭代设计和简单设计的结合有助于我们摆脱过度设计的困扰，把精力集中在真正重要的功能之上。

  此外，简单的设计并不等同于较少的付出。简单的设计往往需要对现实世界的抽象，回忆我们在简单设计中讨论的测量模式的例子，它看似简单，但实现起来却需要大量的业务知识、很强的设计能力。因此，做到简单是程序员不断追寻的目标之一。

  在很多的方法论中，一般并不过分注意代码重复的问题，要么是不关注，要么认为适当的代码重复是允许的。而XP却把代码重复视为良好代码的大敌。"只要存在重复代码，就说明代码仍有Refactoring的可能。"这种观点看起来非常的绝对，这可能也正是其名字中Extreme的来历（英文中的Extreme属于语气非常重的一个单词）。从实践的角度上来看，追求不重复的代码虽然很难做到，但是其过程却可以有效的提高开发团队代码的写作质量，因为它逼迫着你在每次迭代重对代码进行改进，不能有丝毫的怠惰。而这种迭代的特性，促进了简单的实现。

  团队和简单

  我们在简单设计中提过简单设计需要全面的设计师。除此之外，它还需要团队的配合。简单意味着不同活动间交付工件的简单化。也就是说，类似于需求说明书、设计文档之类的东西都将会比较简单。正因为如此，我们很难想象一个地理上分布在不同地点的开发团队或一个超过50人的大团队能够利用这种简单的文档完成开发任务。

  因此，简单的设计是需要团队的组织结构来保证的。简单的设计要求团队的相互沟通能够快速的进行。架构设计完成后，架构的设计思路传达给所有的编码人员的速度要块，同样，编码中发现问题，回馈给设计者，设计者经过改进之后再传达给收到影响的编码人员的速度也要快。象这样高效率的传播我们可以称之为"Hot Channel"。

  为了保证"Hot Channel"的高沟通效率，最好的组织单位是开发人员在3到6人之间，并处于同间工作室中。这样的结构可以保证讯息的交互速度达到最高，不需要付出额外的沟通成本，也不需要过于复杂的版本控制工具或权限分配。根据我的经验，一个共享式的小型版本控制工具、网络共享、再加上一个简单的网络数据库就能够解决大部分的问题了。

  在理论上，我们说只要分配得当，大型的团队同样可以组织为金字塔式的子团队，以提高大型团队的工作效率。但是实际中，随着团队的人数的增加，任务的正确分配的���度也随之加大，沟通信息上传下达的效率开始下降，子团队间的隔阂开始出现，各种因素的累加导致敏捷方法并不一定适合于大型的团队，因此我们讨论的敏捷方法都将受到团队的特性的限制。

模式的源头

  如果你对XP有一定的了解的话，那么你可能会感觉到我们讨论的模式中应用了XP的实践。确实如此，XP中有很多优秀的实践，如果组织得当的话，这些微小的实践将会组合成为一套了不起的开发方法。不过，目前的软件开发混乱的现状阻止了先进的软件方法的应用，对一个身体虚弱的病人施以补药只会适得其反。因此，在前面讨论的模式中，我们应用了一些容易应用、效果明显的实践方法。在实践中适当的应用这些方法，并不需要额外的投入，却能够有很好的效果，同时还会为你的团队打下一个良好的基础

架构设计中的方法学(8)——架构愿景（2）

我们从源自需求模式中，学习到架构的设计是来自于需求的，而应用于软件全局的架构则来自于最重要的需求。还记得我们在那个模式中提到的网上宠物店的例子吗？系统采用了MVC模式，sun的官方文档一开始说明了为什么采用MVC模式，MVC模式解决了什么

问题，然后开始分析MVC模式的几个组成部分：Model、View、和Controll。其实，MVC中的每一个部分，在真正的代码中，大都代表了一个子系统，但是在目前，我们就非常的清楚系统大致上会是一个什么样子，虽然这时候它还十分的朦胧。

不要视图在全局的架构愿景中就制定出非常细致的规划，更不要视图生成大量的实际代码。因为，你的架构愿景还没有稳定（我们在其后的稳定化的模式中将会讨论稳定的问题），还没有获得大家的同意，也没有经过证明。因此，从整个的开发周期来看，全局架构愿景是随着迭代周期的进行不断发展、修改、完善的。

我们如何确定全局架构愿景工作的完成？一般来说，你的架构设计团队取得了一致的意见就可以结束了，如果问题域是团队所熟悉的，一两个小时就能够解决问题。接下来设计团队把架构愿景传播到整个的开发团队，大家形成一致的认识，不同的意见将会被反馈会来，并在本次的迭代周期（如果时间比较紧迫）或下一次的迭代周期中（如果时间比较宽松）考虑。

子模块级、或是子问题级的架构愿景

这时候的架构愿景已经是比较明确的了，因为已经存在明确的问题域。例如界面的设计、领域模型的设计、持久层的设计等。这里的愿景制定本质上和全局的愿景制定差不多，具体的例子我们也不再举了。但是要注意一点，你不能够和全局愿景所违背。在操作上，全局愿景是设计团队共同制定出来的，而子模块级的架构愿景就可以分给设计子团队来负责，而其审核则还是要设计团队的共同参与。这有两个好处，一是确保各个子模块（子问题）间不至于相互冲突或出现空白地带，二是每个子设计团队可以从别人那里吸取设计经验。

在设计时，同样我们可以参考其它的资料，例如相关的模式、或规范（界面设计指南）。在一个有开发经验的团队，一般都会有开发技术的积累，这些也是可供参考的重要资料。

我们在这个层次的愿景中主要谈一谈子模块（子问题）间的耦合问题。一般来说，各个子模块间的耦合程度相对较小，例如一个MIS系统中，采购和销售模块的耦合度就比较小，而子问题间的耦合程度就比较大，例如权限设计、财务，这些功能将会被每个模块使用。那么，我们就需要为子模块（子问题）制定出合同接口（Contact Interface）。合同的意思就是说这个接口是正式的，不能够随意的修改，因为这个结构将会被其它的设计团队使用，如果修改，将会对其它的团队产生无法预计的影响。合同接口的制定、修改都需要设计团队的通过。此外，系统中的一些全局性的子问题最好是提到全局愿景中考虑，例如在源自需求模式中提到的信贷帐务的例子中，我们就把一个利息计算方式的子问题提到了全局愿景中。

代码级的愿景

 严格的说这一层次的愿景已经不是真正的愿景，而是具体设计了。但是我们为了保证对架构设计理解的完整性，还是简单的讨论一下。这一个层次的愿景一般可以使用类图、接口来表示。但在类图中，你不需要标记出具体的属性、操作，你只需要规定出类的职责以及类之间的相互关系就可以了。该层次愿景的审核需要设计子团队的通过。

 而设计细分到这个粒度上，执行愿景设计的开发人员可能就只有一两个左右。但是比较重要的工作在于问题如何分解和如何归并。分解主要是从两个维度来考虑，一个是问题大小维，一个是时间长短维。也就是说，你（设计子团队负责人）需要把问题按大小和解决时间的长短分解为更细的子问题，交给不同的开发人员。然后再把开发人员提出的解决方法组合起来。

  架构愿景的形成过程

架构愿景的形成的源头是需求，需要特别指出的是，这里的需求主要是那些针对系统基本面的需求。比如说，系统的特点是一个交互式系统，还是一个分布式系统。这些需求将会影响到架构愿景的设计。在收集影响架构愿景的各项需求之后，按照需求的重要性来设计架构愿景。

 架构愿景的设计并不需要很复杂的过程，也不需要花费很多的时间。我们已经提过，架构远景的主要目的就是为了能够在开发团队中传播设计思路，因此，架构愿景包括基本的设计思路和基本的设计原则。

 值得注意的是，架构远景可能会有多种的视角，下文讨论了一种设计模式的视角。但是实际设计中还可能会基于数据库来设计架构愿景。但在企业信息系统的设计中，我推荐使用领域类的设计，也就是下文中讨论的例子。

架构愿景设计好之后，问题的焦点就转到如何传播架构愿景上来，为了达到在开发团队中取得统一设计意图的效果，可以考虑援引团队设计模式。除此之外，针对性的项目前期培训也会是一种有效的做法。

使用架构模式

架构模式也是一种很好的架构愿景设计思路的来源。随着对设计模式的研究的深入，人们发现其中的一些设计模式可以扩展、或变化为软件设计的基础。在这个基础上再实现更多的设计，这些模式就形成了架构模式。当然，不同的软件，它们的架构模式也是不一样的。在《Applying Pattern》一文中，有一个很典型的架构愿景的例子：

假设我们需要设计分布式的交互式系统。分布式系统和交互式系统都有特定的架构模式，前者为Broker模式，后者为MVC模式。首先我们先要根据系统的特点的重要程度来排列模式的顺序。这里假设需求中分布式特性更重要一些。那么我们首先选择Broker模式作为架构的基本模式： 
   
   
  再考虑交互式的特点，根据MVC模式的特点，我们需要从目前的基本架构中识别出Model、Controller、以及View。Model和View都很简单，分别分布在上图中的Server和Client中。而Controller则有两种的选择，假设这里的Controller部署在客户端，上图则演化为下图： 
   
   
  这样，基础的架构愿景就已经出现了。如果我们还有更多的需求，还可以继续改进。但是，记住一点，架构愿景不要过于复杂。正如我们在上一节中所讨论的，这里我们虽然是基于设计模式来讨论架构愿景，但是实际中还有很多从其它的视角来看待架构愿景的。至于要如何选择架构愿景的视角，关键的还是在于需求的理解。

需求分析的20条法��
我们讨论的过程仅限于面向对象的软件开发过程。我们称之为OOSP（object-oriented software process ）。因为我们的过程需要面向对象特性的支持。当然，我们的很多做法一样可以用在非OO的开发过程中，但是为了达到最佳的效果，我建议您使用OO技术。对商业用户来说，他们后面是成百上千个供应商，前面是成千上万个消费顾客。怎样利用软件管理错综复杂的供应商和消费顾客，如何做好精细到一个小小调料包的进、销、调、存的商品流通工作，这些都是商业企业需要信息管理系统的理由。软件开发的意义也就在于此。而弄清商业用户如此复杂需求的真面目，正是软件开发成功的关键所在。 
　　经理：“我们要建立一套完整的商业管理软件系统，包括商品的进、销、调、存管理，是总部-门店的连锁经营模式。通过通信手段门店自动订货，供应商自动结算，卖场通过扫条码实现销售，管理人员能够随时查询门店商品销售和库存情况。另外，我们也得为政府部门提供关于商品营运的报告。”
　　分析员：“我已经明白这个项目的大体结构框架，这非常重要，但在制定计划之前，我们必须收集一些需求。” 
　　经理觉得奇怪：“我不是刚告诉你我的需求了吗？” 
　　分析员：“实际上，您只说明了整个项目的概念和目标。这些高层次的业务需求不足以提供开发的内容和时间。我需要与实际将要使用系统的业务人员进行讨论，然后才能真正明白达到业务目标所需功能和用户要求，了解清楚后，才可以发现哪些是现有组件即可实现的，哪些是需要开发的，这样可节省很多时间。” 
　　经理：“业务人员都在招商。他们非常忙，没有时间与你们详细讨论各种细节。你能不能说明一下你们现有的系统？” 
　　分析员尽量解释从用户处收集需求的合理性：“如果我们只是凭空猜想用户的要求，结果不会令人满意。我们只是软件开发人员，而不是采购专家、营运专家或是财务专家，我们并不真正明白您这个企业内部运营需要做些什么。我曾经尝试过，未真正明白这些问题就开始编码，结果没有人对产品满意。” 
　　经理坚持道：“行了，行了，我们没有那么多的时间。让我来告诉您我们的需求。实际上我也很忙。请马上开始开发，并随时将你们的进展情况告诉我。” 
风险躲在需求的迷雾之后 
　　以上我们看到的是某客户项目经理与系统开发小组的分析人员讨论业务需求。在项目开发中，所有的项目风险承担者都对需求分析阶段备感兴趣。这里所指的风险承担者包括客户方面的项目负责人和用户，开发方面的需求分析人员和项目管理者。这部分工作做得到位，能开发出很优秀的软件产品，同时也会令客户满意。若处理不好，则会导致误解、挫折、障碍以及潜在的质量和业务价值上的威胁。因此可见——需求分析奠定了软件工程和项目管理的基础。 
拨开需求分析的迷雾 
　　像这样的对话经常出现在软件开发的过程中。客户项目经理的需求对分析人员来讲，像“雾里看花”般模糊并令开发者感到困惑。那么，我们就拨开雾影，分析一下需求的具体内容：
　　·业务需求——反映了组织机构或客户对系统、产品高层次的目标要求，通常在项目定义与范围文档中予以说明。 
　　·用户需求——描述了用户使用产品必须要完成的任务，这在使用实例或方案脚本中予以说明。 
　　·功能需求——定义了开发人员必须实现的软件功能，使用户利用系统能够完成他们的任务，从而满足了业务需求。 
　　·非功能性的需求——描述了系统展现给用户的行为和执行的操作等，它包括产品必须遵从的标准、规范和约束，操作界面的具体细节和构造上的限制。 
　　·需求分析报告——报告所说明的功能需求充分描述了软件系统所应具有的外部行为。“需求分析报告”在开发、测试、质量保证、项目管理以及相关项目功能中起着重要作用。 
　　前面提到的客户项目经理通常阐明产品的高层次概念和主要业务内容，为后继工作建立了一个指导性的框架。其他任何说明都应遵循“业务需求”的规定，然而“业务需求”并不能为开发人员提供开发所需的许多细节说明。 
　　下一层次需求——用户需求，必须从使用产品的用户处收集。因此，这些用户构成了另一种软件客户，他们清楚要使用该产品完成什么任务和一些非功能性的特性需求。例如：程序的易用性、健壮性和可靠性，而这些特性将会使用户很好地接受具有该特点的软件产品。 
　　经理层有时试图代替实际用户说话，但通常他们无法准确说明“用户需求”。用户需求来自产品的真正使用者，必须让实际用户参与到收集需求的过程中。如果不这样做，产品很可能会因缺乏足够的信息而遗留不少隐患。 
　　在实际需求分析过程中，以上两种客户可能都觉得没有时间与需求分析人员讨论，有时客户还希望分析人员无须讨论和编写需求说明就能说出用户的需求。除非遇到的需求极为简单；否则不能这样做。如果您的组织希望软件成功，那么必须要花上数天时间来消除需求中模糊不清的地方和一些使开发者感到困惑的方面。 
　　优秀的软件产品建立在优秀的需求基础之上，而优秀的需求源于客户与开发人员之间有效的交流和合作。只有双方参与者都明白自己需要什么、成功的合作需要什么时，才能建立起一种良好的合作关系。 
　　由于项目的压力与日俱增，所有项目风险承担者有着一个共同目标，那就是大家都想开发出一个既能实现商业价值又能满足用户要求，还能使开发者感到满足的优秀软件产品。 
客户的需求观 
　　客户与开发人员交流需要好的方法。下面建议20条法则，客户和开发人员可以通过评审以下内容并达成共识。如果遇到分歧，将通过协商达成对各自义务的相互理解，以便减少以后的磨擦（如一方要求而另一方不愿意或不能够满足要求）。 
1、 分析人员要使用符合客户语言习惯的表达 
　　需求讨论集中于业务需求和任务，因此要使用术语。客户应将有关术语（例如：采价、印花商品等采购术语）教给分析人员，而客户不一定要懂得计算机行业的术语。 
2、分析人员要了解客户的业务及目标 
　　只有分析人员更好地了解客户的业务，才能使产品更好地满足需要。这将有助于开发人员设计出真正满足客户需要并达到期望的优秀软件。为帮助开发和分析人员，客户可以考虑邀请他们观察自己的工作流程。如果是切换新系统，那么开发和分析人员应使用一下目前的旧系统，有利于他们明白目前系统是怎样工作的，其流程情况以及可供改进之处。s 3、分析人员必须编写软件需求报告 
　　分析人员应将从客户那里获得的所有信息进行整理，以区分业务需求及规范、功能需求、质量目标、解决方法和其他信息。通过这些分析，客户就能得到一份“需求分析报告”，此份报告使开发人员和客户之间针对要开发的产品内容达成协议。报告应以一种客户认为易于翻阅和理解的方式组织编写。客户要评审此报告，以确保报告内容准确完整地表达其需求。一份高质量的“需求分析报告”有助于开发人员开发出真正需要的产品。 
4、 要求得到需求工作结果的解释说明 
　　分析人员可能采用了多种图表作为文字性“需求分析报告”的补充说明，因为工作图表能很清晰地描述出系统行为的某些方面，所以报告中各种图表有着极高的价值；虽然它们不太难于理解，但是客户可能对此并不熟悉，因此客户可以要求分析人员解释说明每个图表的作用、符号的意义和需求开发工作的结果，以及怎样检查图表有无错误及不一致等。 
5、 开发人员要尊重客户的意见 
　　如果用户与开发人员之间不能相互理解，那关于需求的讨论将会有障碍。共同合作能使大家“兼听则明”。参与需求开发过程的客户有权要求开发人员尊重他们并珍惜他们为项目成功所付出的时间，同样，客户也应对开发人员为项目成功这一共同目标所做出的努力表示尊重。 
6、 开发人员要对需求及产品实施提出建议和解决方案 
　　通常客户所说的“需求”已经是一种实际可行的实施方案，分析人员应尽力从这些解决方法中了解真正的业务需求，同时还应找出已有系统与当前业务不符之处，以确保产品不会无效或低效；在彻底弄清业务领域内的事情后，分析人员就能提出相当好的改进方法，有经验且有创造力的分析人员还能提出增加一些用户没有发现的很有价值的系统特性。 
7、 描述产品使用特性 
　　客户可以要求分析人员在实现功能需求的同时还注意软件的易用性，因为这些易用特性或质量属性能使客户更准确、高效地完成任务。例如：客户有时要求产品要“界面友好”或“健壮”或“高效率”，但对于开发人员来讲，太主观了并无实用价值。正确的做法是，分析人员通过询问和调查了解客户所要的“友好、健壮、高效所包含的具体特性，具体分析哪些特性对哪些特性有负面影响，在性能代价和所提出解决方案的预期利益之间做出权衡，以确保做出合理的取舍。 
8、 允许重用已有的软件组件 
　　需求通常有一定灵活性，分析人员可能发现已有的某个软件组件与客户描述的需求很相符，在这种情况下，分析人员应提供一些修改需求的选择以便开发人员能够降低新系统的开发成本和节省时间，而不必严格按原有的需求说明开发。所以说，如果想在产品中使用一些已有的商业常用组件，而它们并不完全适合您所需的特性，这时一定程度上的需求灵活性就显得极为重要了。 
9、 要求对变更的代价提供真实可靠的评估 
　　有时，人们面临更好、也更昂贵的方案时，会做出不同的选择。而这时，对需求变更的影响进行评估从而对业务决策提供帮助，是十分必要的。所以，客户有权利要求开发人员通过分析给出一个真实可信的评估，包括影响、成本和得失等。开发人员不能由于不想实施变更而随意夸大评估成本。 
10、 获得满足客户功能和质量要求的系统 
　　每个人都希望项目成功，但这不仅要求客户要清晰地告知开发人员关于系统“做什么”所需的所有信息，而且还要求开发人员能通过交流了解清楚取舍与限制，一定要明确说明您的假设和潜在的期望，否则，开发人员开发出的产品很可能无法让您满意。 
11、 给分析人员讲解您的业务 
　　分析人员要依靠客户讲解业务概念及术语，但客户不能指望分析人员会成为该领域的专家，而只能让他们明白您的问题和目标；不要期望分析人员能把握客户业务的细微潜在之处，他们可能不知道那些对于客户来说理所当然的“常识”。 
12、 抽出时间清楚地说明并完善需求 
　　客户很忙，但无论如何客户有必要抽出时间参与“头脑高峰会议”的讨论，接受采访或其他获取需求的活动。有些分析人员可能先明白了您的观点，而过后发现还需要您的讲解，这时请耐心对待一些需求和需求的精化工作过程中的反复，因为它是人们交流中很自然的现象，何况这对软件产品的成功极为重要。 
13、 准确而详细地说明需求 
　　编写一份清晰、准确的需求文档是很困难的。由于处理细节问题不但烦人而且耗时，因此很容易留下模糊不清的需求。但是在开发过程中，必须解决这种模糊性和不准确性，而客户恰恰是为解决这些问题作出决定的最佳人选，否则，就只好靠开发人员去正确猜测了。 
　　在需求分析中暂时加上“待定”标志是个方法。用该标志可指明哪些是需要进一步讨论、分析或增加信息的地方，有时也可能因为某个特殊需求难以解决或没有人愿意处理它而标注上“待定”。客户要尽量将每项需求的内容都阐述清楚，以便分析人员能准确地将它们写进“软件需求报告”中去。如果客户一时不能准确表达，通常就要求用原型技术，通过原型开发，客户可以同开发人员一起反复修改，不断完善需求定义。 
14、 及时作出决定 
　　分析人员会要求客户作出一些选择和决定，这些决定包括来自多个用户提出的处理方法或在质量特性冲突和信息准确度中选择折衷方案等。有权作出决定的客户必须积极地对待这一切，尽快做处理，做决定，因为开发人员通常只有等客户做出决定才能行动，而这种等待会延误项目的进展。 
15、 尊重开发人员的需求可行性及成本评估 
　　所有的软件功能都有其成本。客户所希望的某些产品特性可能在技术上行不通，或者实现它要付出极高的代价，而某些需求试图达到在操作环境中不可能达到的性能，或试图得到一些根本得不到的数据。开发人员会对此作出负面的评价，客户应该尊重他们的意见。
16、 划分需求的优先级 
　　绝大多数项目没有足够的时间或资源实现功能性的每个细节。决定哪些特性是必要的，哪些是重要的，是需求开发的主要部分，这只能由客户负责设定需求优先级，因为开发者不可能按照客户的观点决定需求优先级；开发人员将为您确定优先级提供有关每个需求的花费和风险的信息。 
　　在时间和资源限制下，关于所需特性能否完成或完成多少应尊重开发人员的意见。尽管没有人愿意看到自己所希望的需求在项目中未被实现，但毕竟是要面对现实，业务决策有时不得不依据优先级来缩小项目范围或延长工期，或增加资源，或在质量上寻找折衷。 
17、 评审需求文档和原型 
　　客户评审需求文档，是给分析人员带来反馈信息的一个机会。如果客户认为编写的“需求分析报告”不够准确，就有必要尽早告知分析人员并为改进提供建议。 
　　更好的办法是先为产品开发一个原型。这样客户就能提供更有价值的反馈信息给开发人员，使他们更好地理解您的需求；原型并非是一个实际应用产品，但开发人员能将其转化、扩充成功能齐全的系统。 
18、 需求变更要立即联系 
　　不断的需求变更，会给在预定计划内完成的质量产品带来严重的不利影响。变更是不可避免的，但在开发周期中，变更越在晚期出现，其影响越大；变更不仅会导致代价极高的返工，而且工期将被延误，特别是在大体结构已完成后又需要增加新特性时。所以，一旦客户发现需要变更需求时，请立即通知分析人员。 
19、 遵照开发小组处理需求变更的过程 
　　为将变更带来的负面影响减少到最低限度，所有参与者必须遵照项目变更控制过程。这要求不放弃所有提出的变更，对每项要求的变更进行分析、综合考虑，最后做出合适的决策，以确定应将哪些变更引入项目中。 
20、 尊重开发人员采用的需求分析过程 
　　软件开发中最具挑战性的莫过于收集需求并确定其正确性，分析人员采用的方法有其合理性。也许客户认为收集需求的过程不太划算，但请相信花在需求开发上的时间是非常有价值的；如果您理解并支持分析人员为收集、编写需求文档和确保其质量所采用的技术，那么整个过程将会更为顺利。 
“需求确认”意味着什么 
　　在“需求分析报告”上签字确认，通常被认为是客户同意需求分析的标志行为，然而实际操作中，客户往往把“签字”看作是毫无意义的事情。“他们要我在需求文档的最后一行下面签名，于是我就签了，否则这些开发人员不开始编码。” 
　　这种态度将带来麻烦，譬如客户想更改需求或对产品不满时就会说：“不错，我是在需求分析报告上签了字，但我并没有时间去读完所有的内容，我是相信你们的，是你们非让我签字的。” 
　　同样问题也会发生在仅把“签字确认”看作是完成任务的分析人员身上，一旦有需求变更出现，他便指着“需求分析报告”说：“您已经在需求上签字了，所以这些就是我们所开发的，如果您想要别的什么，您应早些告诉我们。” 
　　这两种态度都是不对的。因为不可能在项目的早期就了解所有的需求，而且毫无疑问地需求将会出现变更，在“需求分析报告”上签字确认是终止需求分析过程的正确方法，所以我们必须明白签字意味着什么。 
　　对“需求分析报告”的签名是建立在一个需求协议的基线上，因此我们对签名应该这样理解：“我同意这份需求文档表述了我们对项目软件需求的了解，进一步的变更可在此基线上通过项目定义的变更过程来进行。我知道变更可能会使我们重新协商成本、资源和项目阶段任务等事宜。”对需求分析达成一定的共识会使双方易于忍受将来的摩擦，这些摩擦来源于项目的改进和需求的误差或市场和业务的新要求等。 
　　需求确认将迷雾拨散，显现需求的真面目，给初步的需求开发工作画上了双方都明确的句号，并有助于形成一个持续良好的客户与开发人员的关系，为项目的成功奠定了坚实的基础。