问题定义只定义了问题是什么，而不涉及任何可能的解决方案
如果没有好的需求，你可能对问题有总体的把握，但却没有集中问题的特定方面
需求像水。如果冻结了，就容易在上面开展建设 ——无名氏
软件架构是软件设计的高层部分，适用于支撑更细节的设计的框架。
离开了良好的软件架构，你可能瞄准了正确的问题，但却使用了错误的解决方案。也许完全不可能有成功的构建
架构的典型组成部分
- 程序组织
- 主要的类 2/8原则
- 数据设计
- 业务规则
- 用户界面设计
- 资源管理
- 安全性（数据库连接、线程、句柄等）
- 性能
- 可伸缩性
- 互用性
- 国际化、本地化
- 输入输出
- 错误处理
- 容错性
- 架构的可行性
- 过度工程
- 关于买和 造的决策
- 关于复用的决策
- 变更策略
- 架构的总体质量
要点
- 构建活动的准备工作的根本目标在于降低风险。要确认你的准备活动是在降低风险，而非增加风险
- 如果你想开发高质量的软件，软件开发过程必须由始至终关注质量。在线木初期关注质量，对产品质量的正面影响比在项目默契关注质量的一项要大
- 程序员的一部分工作是教育老板和合作者，告诉他们软件开发过程，包括在开始编程之前进行充分准备的重要性
- 你所从事的软件项目的类型对构建活动的前期准备有重大影响——许多项目应该是高度迭代的，某些应该是序列式的
- 如果没有明确的问题定义，那么你可能会在构建期间解决错误的问题
- 如果没有做完良好的需求分析工作，你可能没有察觉待解决的问题的重要细节。如果需求变更发生在构建之后的阶段，其代价是“在项目早期更改需求”的20-100倍。因此在开始变成之前，你要确认“需求“已经到位了
- 如果没有做完良好的架构设计，你可能会在构建期间用错误的方法解决正确的问题。架构变更的代价随着“为错误的架构编写的代码数量”增加而增加，因此，也要确认“”架构“”已经到位了。
- 理解项目的前期准备所采用的方法，并相应地选择构建方法。
核对表
架构核对表
针对各架构主题
- 程序的整体组织结构是否清晰？是否包含一个良好的架构全局观（及其理由）
- 是否确定了主要得到构造快（包括每个构造快的职责范围及与其他构造快的接口）
- 是否明确涵盖了“需求”中所列出的所有功能（每个功能对应的构造快不太多也不太少）
- 是否描述并论证了那些最关键的类
- 是否描述并论证了数据设计
- 是否详细定义了数据库的组织结构和内容
- 是否指出了所用关键的业务规则，并描述其对系统的影响？
- 是否描述了用户界面设计的策略‘
- 是否将用户界面模块化，使界面的免耕不会影响程序其余部分
- 是否描述并论证了处理I/O的策略
- 是否估算了稀缺资源（如县城、数据库连接、句柄、网络带框等）的使用量，是否描述并论证了资源管理的策略
- 是否描述了架构的安全需求
- 架构是否为每个类、每个子系统、每个模块功能域提出空间与时间预算
- 架构是否描述了如何达到可伸缩性
- 架构是否关注互操作性
- 是否描述了国际化本地化的策略
- 是否提供了一套内聚的错误处理策略
- 是否规定了容错的方法
- 是否证实了系统各个部分的技术可行性
- 是否详细描述了过度工程的方法
- 是否包含了必要的 买 vs. 造的决策
- 架构是否描述了如何加工复用的代码，使之符合其他架构目标？
- 是否将架构设计得能够适应和可能出现的变更
架构的总体质量
- 架构是否解决了全部的需求
- 有没有那个部分是过度架构或欠架构？是否明确宣布了在这方面的预期指标
- 整个架构是否在概念上协调一致
- 顶层设计是否独立于用作实现它的机器和语言
- 是否说明了所有主要的决策和动机
- 你，作为一名实现该系统的程序员，是否对这个架构感觉良好？