下载第10章构架10软件构架可说是组成项目的技术结构。良好的构架可以简化项目，不良的构架让项目如同海市蜃楼。良好的软件构架文件，以现行的构架加以变化、重复利用来自其他系统或买来的组件，在符合标准功能领域的做法下，说明整体程序组织。将每一项系统需求条列详细列出，来降低潜在的下游成本。微软项目求生法则下载186架设计阶段好比兴建房子一般，软件构架阶段可构说是参考模型，提供构架团队探索构建软件的不同方法，而不必要花时间和经费去实地尝试不同做法，减少负担。构架时期也被称作“系统构架时期”、“设计时期”、“高阶设计时期”和“上层设计时期”。一般说来，构架描述会放在“软件构架”文件中。在构架阶段，构架团队将系统分割成主要的子系统，具体规划子系统彼此间的互动关系和上层技术规划的文件。它也针对系统执行中主要的设计问题，像错误处理、内存管理及字符串储存的做法。构架阶段通过定义细节设计时期所使用的结构，来替细节设计阶段铺路。在小型项目中，构架和设计也许在同一个进度进行，不过在大部分项目中，构架应该被独立看待。ehTMythicalMan-Month的作者FredBrooks报告指出，“拥有一名系统构架设计者，是朝向概念整合最重要的一步⋯⋯在一个软件工程实验室授课超过二十次后，我开始坚持只要有四个人的学生团队即应该选出一名主管和一名构架设计者。在这么小的团队中定义不同角色也许有点极端，不过我发觉这种方式可以最有效运作，而且对于小型团队的成功最有贡献”。微软项目：求生法则下载构架187本章的讨论，假设软件构架是由一小队设计者开发出来的，不管这些人如何进行，本章描述的问题应该被小心提防，并在进行细节设计和构建过程以前解决掉。缓缓进入构架阶段构架工作应该在需求开发完成约%08时开始进行，不可能等到需求开发工作全都完成。只要需求达到80%之后，项目已经强韧得足以支撑软件构架的建立。%08得自经验法则，而且项目主持人需要以具体的判断来评估此时是否足以开始发展软件构架。在构架团队开始进行以前，项目团队、上层主管与顾客应该举行第4章中描述的规划检查会议。同时等待经费的支持，万事齐备后才开始全心投入。良好的构架的特色当构架团队投入构架开发工作时，他们将面对一组核心设计问题，这当然是项目的构架中所不能欠缺的。系统概述一个系统构架需要先有概括描述。开发人员才能从上微软项目求生法则下载188千个细节甚至一打以上的模块或对象类别中建立出一致的轮廓。构架应该深入考虑主要的设计方式，列出这些方式被考虑的理由，以及不被采用的理由。概念整合构架的目标应该要能清楚说明系统概念。对以非妥协性为主要目标的系统与以调适性为主要目标的设计而言，虽然两者功能一致，其实是大不相同。一个良好的构架应该能适合问题的需要。在构架设计开始一段时间之后，设计者应该建立一套良好的构架来处理问题，好让其他人感觉到：“没错，就是这样；除了这么做，你还能怎么做”？HarlanMills将质量当成“深度简化”。要知道，愈复杂的构架其实就是愈糟糕的构架，别期待它对你有帮助。小心琐碎的构架—也就是试图能处理所有想像得到的问题的一种构架。现行的趋势是，构架团队会找机会尽量简化，最佳的构架文件应该简短，着重流程，一般少于100页。最受欢迎的软件工程书《TheMythicalMan-Month》的主要内容是大型系统的根本问题在于概念整合。当你检视构架时，你应该为解决方案的自然、简单感到骄傲。构微软项目：求生法则下载构架189架不应该看来杂乱不堪。子系统与组织构架应该先定义程序中的主要子系统。子系统是功能主要的划分方式，如输出格式化、资料储存、分析、使用者输入等等。大部分系统应该包含9~5个子系统。如果太复杂，系统就难以被了解。图1-01说明在应用程序中这类设计工作的适当繁杂程度。大部分构架拥有9~5个上层子系统。良好的构架在子系统间有着相对少量的互动关系。使用者界面图形格式化与输出资料储存单一程序辅助工具资料分析程序家族重复使用工具基础工具(文字字串储存、记忆体管理等等)图10-1子系统构架流程的例子除了如图1-01中的流程，构架应该描述各个子系统的任务，并提供每个子系统中各模块或对象类别的初步列表。微软项目求生法则下载190最后的模块或对象类别清单会在细节设计与构建过程中产生出来。构架应该描述不同子系统间相互的沟通方式。在图10-1-01中，只有少许子系统间沟通可以进行。图2-01说明毫无限制的子系统彼此沟通会造成构架变得难以控制。子系统间可能会以各种组合进行互动，这样一来将破