代码大全（第二版）——全面的软件构建参考 第一部分：打好基础
第一部分：打好基础
1、软件开发中的不同活动
a) 定义问题（Problem definition）
b) 需求分析（Requirements development）
c) 规划构建（Construction planning）
d) 软件架构 / 高层设计（Software architecture, or high-level design）
e) 详细设计（Detailed design）
f) 编码与调试（Coding and debugging）
g) 单元测试（Unit testing）
h) 集成测试（Integration testing）
i) 集成（Integration）
j) 系统测试（System testing）
k) 保障维护（Corrective maintenance）
2、什么是软件构建？（构建也常被称作编码、编程）
软件构建的主要活动包括：详细设计、编码、调试、集成、单元测试、集成测试
3、构建活动的重要性
a) 时间比重：构建活动在整个软件开发活动总时间中所占的比例一般在30%——80%
b) 构建活动是软件开发中的核心活动。前有需求分析和架构设计，后有系统测试
c) 把主要精力集中于构建活动，可大大提高程序员的生产率（更早发现、规避问题）
d) 构建活动是唯一一项（必不可少）确保完成的工作。
e) 构建活动直接影响软件开发过程，构建活动的质量对软件质量有着实质性的影响
f) 在构建之前讲清楚你所遵循的编码约定，精确的约定
4、用隐喻来更充分的理解软件开发
a) 通过对比不太理解的东西和你比较熟悉并且十分类似的东西做比较，通过类比，深刻理解新的东西。也叫建模（modeling）
b) 隐喻是对概念进行内在化和抽象的一种途径，让人们在更高的层次上思考问题而避免底层次的错误。能被更多人理解
c) 算法直接给你解决问题的指导（具体路线），启发式方法告诉你如何找到这些指导信息或者告诉你到哪里去寻找指导信息。隐喻是一种启发式方法而不是算法，因此往往有些随意（因地制宜选择工具，没有哪个工具可以适应所有工作，发现更合适的隐喻），不同的隐喻并不会相互排斥，多角度思考，组合使用隐喻。
d) 《人月神话》（The Mythical Man-Month）中的文字写作（编码）的隐喻暗示着软件开发的过程是一种代价昂贵的试错（trial and error）过程，而非仔细的规划和设计。
e) 牡蛎孕育珍珠：增量开发（先做出软件系统的一个尽可能简单但能运行的版本，一次增加一小部分，直到得到一个完全可以工作的系统）开速迭代
f) 软件构建：建造软件。更复杂的结构需要需要更加自信的规划，适当的多层次的规划对于建造建筑物和构建软件都有好处，精心的计划并不意味着事无巨细的计划或者过度的计划
5、三思而后行：前期准备
a) 准备工作的中心目标是降低风险，软件开发中最常见的风险是糟糕的需求分析和项目计划，软件开发的过程必须由始至终关注质量。
b) 抵抗“尽快开始编码的欲望”
c) 尽早把关键的需求要素和架构要素确定下来，发错误越早，变更成本越低
d) 花费在前期准备上的时间长度：一般来说，一个运作良好的项目在需求、架构以及其他前期计划（不包括详细设计）方面方面投入10%——20%的工作量和20%——30%的时间，为需求验证新技术领域开发的不确定性预留时间
e) 前期准备核对表
6、不同活动的先决条件
a) 顺序：问题定义——>需求——>架构——>构建——>系统测试——>将来的改进
b) 问题定义】只定义问题（用户角度），不涉及任何可能的解决方案，不要花精力去解决错误的问题。如果你不能把一件事解释给一个六岁的儿童，那你就没有真正理解这件事。问题定义在需求分析之前
c) 需求分析】会随着对项目参与的深入而有所变化，平均25%，不奢望稳定的需求，需求分析是对问题定义的深入调查，在构建期间处理需求变更，确保每一个人都知道需求变更的代价，
d) 需求评审】需求核对表
e) 架构设计】是软件设计的高层部分，是用于支撑更细节的设计的框架。架构应该描述所有主要决策的动机；优秀的软件架构很大程度上是与机器和编程语言无关的，包含多个视角（图），容易理解；架构应明确的指出可能的风险，原因及方案。
f) 架构的典型组成部分：
| 程序组织：明确每个构造块的功能，各个构造块之间的通信模式和访问关系 |
| 主要的类: 描述20%的核心类功能即可；架构应包含被否决的方案及原因 |
| 数据设计：数据表、访问方式 |
| 业务规则：详细描述架构依赖的业务规则，并描述这些规则对系统设计的影响 |
| 用户界面设计： |
| 资源管理：数据库链接，线程，句柄 |
| 安全性：制定编码规范时要考虑威胁模型—处理缓冲区数据、非受信数据（用户输入，接口输入，cookie，配置文件）、内存数据 |
| 性能：性能目标应定义资源的使用和优先顺序（速度，内存，成本），能实现性能目标的依据和特定算法及合理的数据结构约束 |
| 可伸缩应：数据量的增长兼容 |
| 互用性：数据的共享 |
| 国际化/本地化：配置类还是文件 |
| 输入输出：机构行详细定义读取策略（先做，购做，即时做），定义再哪个层次上检查I/O错误（字段，记录，流，文件） |
| 异常处理：占程序的90% |
| 容错性：如果可能的话从错误中恢复，不能则包容其不利影响 |
| 架构的可行性：这些问题（系统的功能，性能，稳定性等）是如何经过研究的？ |
| 过（裕）度工程：健壮性是指软件在检测到错误时继续向下执行的能力，架构文档中应定义需要过度工程的部分，也要指出只需要最简单能工作的功能。在软件中，链条的强度不是取决于最弱的一环，而是所有薄弱环节的积。 |
| 买还是造：自造则要说明造的功能优势在哪里 |
| 变更策略：预见程序的扩展，兼容 |
| 架构的总体质量：核心——概念的完整性 |
g) 架构核对表
7、高质量的构建决策
a) 深入一种语言去编程 programming into a language——自己完善语言的不足，扩展类库、版本
b) 你所从事的软件项目的类型对构建活动的前期准备有重大影响——许多项目应该是高度迭代式的，某些应该是序列式的。
c) 要知道你使用的语言的明确优点与弱点
d) 主要的构建实践核对表
