为什么要把架构作为前期准备呢?因为架构的质量决定了系统的“概念完整性”。后者继而决定了系统的最终质量。一个经过慎重考虑的架构为“从顶层到底层维护系统的概念完整性”提供了必备的结构和体系，它为程序员提供了指引——其细节程度与程序员的技能和手边的工作相配。它将工作分为几个部分，使多个开发者或者多个开发团队可以独立工作。

　　在构建期间或者更晚的时候进行架构变更，代价也是高昂的。修复软件架构中的错误所需的时间与修复需求错误所需的时间处于同一数量级——即，多于修复编码错误所需的时间(Basili
and Perricone 1984, Willis
1998)。架构变更如同需求变更一样，看起来一个很小的改动，影响也许是非常深远的。无论为了修正错误还是改进设计而引发架构变更，越早识别出变更越好。

　　架构的典型组成部分

　　很多组成部分是优秀的系统架构所共有的。如果你自己构建整个系统，那么在架构工作会与更详细的设计工作有重叠部分。在这种情况下，你至少应该思考架构的每个组成部分。如果你目前从事的系统的架构是别人做的，你应该能够不费力地找出其中重要的组成部分(无须戴上猎鹿帽、牵着猎犬、手拿放大镜)。在这两种情况中，你都需要考虑以下的架构组成部分。

　　程序组织

　　系统架构首先要以概括的形式对有关系统做一个综述。如果没有这种综述，要想将成千的局部图片(或十多个单独的类)拼成一幅完整的图画是相当伤脑筋的。如果系统是小小的只有12块的智力拼图玩具，你那一岁的小孩也能在眨眼功夫解决它。不过把12个子系统拼到一起要困难一些，而且如果你不能将它们拼起来，那么就无法理解你正在开发的那个类对系统有何贡献。

　　架构应该定义程序的主要构造块(building
blocks)。根据程序规模不同，各个构造块可能是单个类，也可能是由许多类组成的一个子系统。每个构造块无论是一个类还是一组协同工作的类和子程序，它们共同实现一种高层功能，诸如与用户交互、显示Web页面、解释命令、封装业务规则、访问数据，等等。每条列在需求中的功能特性(feature)都至少应该有一个构造块覆盖它。如果两个或多个构造块声称实现同一项功能，那么它们就应该相互配合而不会冲突。shop.epweike.com/4146763/