标签：
本文目录
一、与构架有关的几个基本概念；
二、构架设计应考虑的因素概揽；
三、程序的运行时结构方面的考虑；
四、源代码的组织结构方面的考虑；
五、写系统构架设计文档应考虑的问题
六、结语
一、与构架有关的几个基本概念：
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卡片、基本用例模型、用户素材、界面原型、界面原型流程图
团队设计是敏捷方法论中很重要的一项实践。我们这里说的团队，指的并不是复数的人。一群人就是一群人，并没有办法构成团队。要想成为团队，有很多的工作要做。
我们之所以考虑以团队
架构设计中的方法学(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页呢？同样的道理，能够用一副简单的图形就能够表示的架构设计也没有必要使用文档。毕竟，面对面的沟通才是最有效率的沟通，文档不论如何的复杂，都不能被完全理解，而且，复杂的文档，维护起来也需要花费大量的时间。只有在两种情况下，我们提倡使用复杂的文档：一是开发团队没有办法做到面对面沟通；二是开发成果要作为团队的知识积累起来，为下一次开发所用。
考虑未来
我们之所以考虑未来，主要的原因就是需求的不稳定。因此，我们如果考虑未来可能发生的需求变化，就会不知觉的在架构设计中增加复杂的成分。这违背的简单的精神。但是，如果你
迭代是一种软件开发的生命周期模型，在设计中应用迭代设计，我们可以得到很多的好处。
在软件生命周期中，我们如何对待架构设计的发展？
架构设计往往发生在细节需求尚未完成的时候进行的。因此，随着项目的进行，需求还可能细化，可能变更。原先的架构肯定会有不足或错误的地方。那么，我们应该如何对待原先的设计呢？
我们在简单设计模式中简单提到了"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中有很多优秀的实践，如果组织得当的话，这些微小的实践将会组合成为一套了不起的开发方法。不过，目前的软件开发混乱的现状阻止了先进的软件方法的应用，对一个身体虚弱的病人施以补药只会适得其反。因此，在前面讨论的模式中，我们应用了一些容易应用、效果明显的实践方法。在实践中适当的应用这些方法，并不需要额外的投入，却能够有很好的效果，同时还会为你的团队打下一个良好的基础
我们从源自需求模式中，学习到架构的设计是来自于需求的，而应用于软件全局的架构则来自于最重要的需求。还记得我们在那个模式中提到的网上宠物店的例子吗？系统采用了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、 尊重开发人员采用的需求分析过程
软件开发中最具挑战性的莫过于收集需求并确定其正确性，分析人员采用的方法有其合理性。也许客户认为收集需求的过程不太划算，但请相信花在需求开发上的时间是非常有价值的；如果您理解并支持分析人员为收集、编写需求文档和确保其质量所采用的技术，那么整个过程将会更为顺利。
“需求确认”意味着什么
在“需求分析报告”上签字确认，通常被认为是客户同意需求分析的标志行为，然而实际操作中，客户往往把“签字”看作是毫无意义的事情。“他们要我在需求文档的最后一行下面签名，于是我就签了，否则这些开发人员不开始编码。”
这种态度将带来麻烦，譬如客户想更改需求或对产品不满时就会说：“不错，我是在需求分析报告上签了字，但我并没有时间去读完所有的内容，我是相信你们的，是你们非让我签字的。”
同样问题也会发生在仅把“签字确认”看作是完成任务的分析人员身上，一旦有需求变更出现，他便指着“需求分析报告”说：“您已经在需求上签字了，所以这些就是我们所开发的，如果您想要别的什么，您应早些告诉我们。”
这两种态度都是不对的。因为不可能在项目的早期就了解所有的需求，而且毫无疑问地需求将会出现变更，在“需求分析报告”上签字确认是终止需求分析过程的正确方法，所以我们必须明白签字意味着什么。
对“需求分析报告”的签名是建立在一个需求协议的基线上，因此我们对签名应该这样理解：“我同意这份需求文档表述了我们对项目软件需求的了解，进一步的变更可在此基线上通过项目定义的变更过程来进行。我知道变更可能会使我们重新协商成本、资源和项目阶段任务等事宜。”对需求分析达成一定的共识会使双方易于忍受将来的摩擦，这些摩擦来源于项目的改进和需求的误差或市场和业务的新要求等。
需求确认将迷雾拨散，显现需求的真面目，给初步的需求开发工作画上了双方都明确的句号，并有助于形成一个持续良好的客户与开发人员的关系，为项目的成功奠定了坚实的基础。
标签：
原文地址：http://my.oschina.net/lwaif/blog/502086
