## 第三章 三四而后行:前期准备
> // checklist For Architecture
> 核对表：架构
### 针对各架构主题
- 程序的整体组织结构是否清晰？是否包含一个良好的架构全局观（及其理由）？
- 是否明确定义了主要的构造块(包括每个构造块的职责范围及与其他构造块的接口)?
- 是否明显涵盖了“需求”中列出的所有功能（每个功能对应的构造块不太多也不太少）？
- 是否描述并论证了那些最关键的类？
- 是否描述并论证了数据设计？
- 是否详细定义了数据库的组织结构和内容？
- 是否指出了所用关键的业务规则，并描述其对系统的影响？
- 是否描述了用户界面设计的策略？
- 是否将用户界面模块化,使界面的变更不会影响程序其余部分？
- 否估算了稀缺资源（如线程、数据库连接、句柄、网络带宽等）的使用量，是否描述并论证了资源管理的策略？
- 是否描述了架构的安全需求？
- 架构是否为每一个类、每一个子系统、或每一个功能域（functionality area）提出空间和时间预算？
- 架构是否描述了如何达到可伸缩性？
- 架构是否关注互操作性？
- 是否描述了国际化/本地化的策略？
- 是否提供了一套内聚的错误处理策略？
- 是否规定了容错的办法（如果有需要）？
- 是否证实了系统各个部分的技术可行性？
- 是否详细描述了过度工程(overengineering)的方法？
- 是否包含了必要的“买 vs. 造”的策略？
- 架构是否描述了如何加工被复用的代码，使之符合其他架构目标？
- 是否将架构设计得能够适应很可能出现的变更？
### 架构的总体质量
- 架构是否解决了全部需求？
- 有没有那个部分是“过度架构”或“欠架构（underarchitected）”？是否明确宣布了在这方面的预期指标？
- 整个架构是否在概念上协调一致？
- 顶层设计是否独立于实现它的机器和语言？
- 是否说明了所有主要的决策的动机？
- 你，作为一名实现该系统的程序员，是否对这个系统的架构感觉良好？
### 中文要点：
- 构建活动的准备工作的根本目标在于降低风险。要确认你的准备活动是在降低风险，而非增加风险.
- 如果你想开发高质量的软件，软件开发过程必须由始至终关注质量。在项目初期关注质量，对产品质量的正面影响比在项目末期关注质量的影响要大。
- 程序员的一部分工作是教育老板和合作者，告诉他们软件开发过程，包括在开始编程之前进行充分准备的重要性。
- 你所从事的软件项目的类型对构建活动的前期准备有重大影响——许多项目应该是高度迭代式的，某些应该是序列式的。
- 如果没有明确的问题定义，那么你可能会在构建期间解决错误的问题。
- 如果没有做完良好的需求分析工作，你可能没能察觉待解决的问题的重要细节。如果需求变更发生在构建之后的阶段，其代价是“在项目早期更改需求”的 20至 100 倍。因此在开始编程之前，你要确认“需求”已经到位了。
- 如果没有做完良好的架构设计，你可能会在构建期间用错误的方法解决正确的问题。架构变更的代价随着“为错误的架构编写的代码数量”增加而增加，因此，也要确认“架构”已经到位了。
- 理解项目的前期准备所采用的方法，并相应地选择构建方法。
### English Key Points：
- The overarching goal of preparing for construction is risk reduction. Be sure your preparation activities are reducing risks, not increasing them.
- If you want to develop high-quality software, attention to quality must be part of the software-development process from the beginning to the end. At tention to quality at the beginning has a greater influence on product quality than attention at the end.
- Part of a programmer’s job is to educate bosses and coworkers about the software-development process,including the importance of adequate preparation before programming begins.
- The kind of project you’re working significantly affects construction prerequisites—many projects should be highly iterative, and some should be more sequential.
- If a good problem definition hasn’t been specified, you might be solving the wrong problem during construction.
- If a good requirements work hasn’t been done, you might have missed important details of the problem.Requirements changes cost 20 to 100 times as much in the stages following construction as they do earlier, so be sure the requirements are right before you start programming.
- If a good architectural design hasn’t been done, you might be solving the right problem the wrong way during construction. The cost of architectural changes increases as more code is written for the wrong architecture, so be sure the architecture is right too.
- Understand what approach has been taken to the construction prerequisites on your project and choose your construction approach accordingly.
