如何开发一个软件的架构
发布时间：1714451493
由于本书是关于软件构建的，因此本节不会告诉你如何开发一个软件的架构；它关注是如何确定一个业已存在的架构的质量。因为架构比需求离构建活动又近了一步，所以对架构的讨论也会比对需求的讨论更详细一些。
为什么要把架构作为前期准备呢？因为架构的质量决定了系统的“概念完整性”。后者继而决定了系统的最终质量。一个经过慎重考虑的架构为“从顶层到底层维护系统的概念完整性”提供了必备的结构和体系，它为程序员提供了指引——其细节程度与程序员的技能和手边的工作相配。它将工作分为几个部分，使多个开发者或者多个开发团队可以独立工作。
好的架构使得构建活动变得更容易。糟糕的架构则使构建活动几乎寸步难行。图3-7显示了糟糕的架构的另一个问题。
图3-7离开了良好的软件架构，你可能瞄准了正确的问题，但却使用了错误的解决方案。也许完全不可能有成功的构建
在构建期间或者更晚的时候进行架构变更，代价也是高昂的。修复软件架构中的错误所需的时间与修复需求错误所需的时间处于同一数量级——即，多于修复编码错误所需的时间（BasiliandPerricone1984,Willis1998）。架构变更如同需求变更一样，看起来一个很小的改动，影响也许是非常深远的。无论为了修正错误还是改进设计而引发架构变更，越早识别出变更越好。
TypicalArchitecturalComponents
架构的典型组成部分
很多组成部分是优秀的系统架构所共有的。如果你自己构建整个系统，那么在架构工作会与更详细的设计工作有重叠部分。在这种情况下，你至少应该思考架构的每个组成部分。如果你目前从事的系统的架构是别人做的，你应该能够不费力地找出其中重要的组成部分（无须戴上猎鹿帽、牵着猎犬、手拿放大镜）。在这两种情况中，你都需要考虑以下的架构组成部分。
ProgramOrganization
程序组织
系统架构首先要以概括的形式对有关系统做一个综述。如果没有这种综述，要想将成千的局部图片（或十多个单独的类）拼成一幅完整的图画是相当伤脑筋的。如果系统是小小的只有12块的智力拼图玩具，你那一岁的小孩也能在眨眼功夫解决它。不过把12个子系统拼到一起要困难一些，而且如果你不能将它们拼起来，那么就无法理解你正在开发的那个类对系统有何贡献。
在架构中，你应该能发现对那些曾经考虑过的最终组织结构的替代方案的记叙，找到之所以选用最终的组织结构，而不用其他替代方案的理由。如果对某个类在系统中的角色没有一个清晰的构思，那么编写这个类就是一件令人灰心丧气的工作。描述其他组织结构，才能说明架构最后选定的这种系统组织结构的缘由，并且表明各个类都是慎重考虑过的。有一份对设计实践的综述发现，“维护‘设计的缘由’”至少与“维护设计本身”一样重要(Rombach1990。
架构应该定义程序的主要构造块（buildingblocks）。根据程序规模不同，各个构造块可能是单个类，也可能是由许多类组成的一个子系统。每个构造块无论是一个类还是一
如何开发一个软件的架构
