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