软件构建的前期准备

注：第三章 三思而行：前期准备

首先要明确： 项目质量的关键不在于后期的测试工作，测试只是占项目的完整质量，排查bug的一小部分，它不会纠正制造的“一个错误的产品”，所以关键在于软件构建活动之前的问题定义和需求分析。

1、辨明自己所开发的软件类型

1. 小系统，风险低，需求简单
2. 中型系统，存在风险
3. 大型系统，风险高，需求变化大

2、在做每一个项目之前，应该为自己细分一下工作量。具体而言，先做一个大概的工作表，然后再对概要的表逐项进行细分考究，评估工作量，汇总，如果还不够清晰，可以再次细分，直至逐项清晰明了。最终要求是外行人一眼就能看懂你的工作内容。

3、问题定义的重要性

在构建之前，首先要满足的一个先决条件就是 ：对开发的系统要解决的问题做一个清楚的陈述。问题没找对，可能致使后面的构建解决错误的问题。
要以客户角度，以非计算机语言来描述问题，对问题做一个简单的陈述。

4、需求要明确

1、需求明确，有助于用户(而不是程序员)掌握系统功能，而且用户可以自行评审，校准。
2、需求重在稳定，不稳定的需求在后续编码中会花费相当大的预测开支，而且 系统架构可能会混乱。
3、在构建中处理可能发生的需求变更。
4、需求checklist (p42)

5、架构设计的先决条件

架构师软件设计的高层部分，适用于支撑整个细节设计的框架。
架构的组成部分：
1、程序组织
系统架构首先以概括的形式对有关系统做一个综述。定义程序组成的构造快，以及每个构造快所支撑的功能。

2、主要的类
架构应该详细定义所用的主要的类，每个类的属性，类之间的 关系。

3、数据设计
描述主要的数据文件的访问、存储的设计。

4、业务规则

5、用户界面设计
架构应该定义WEB页面 、GUI、命令接口等主要元素形式。
架构模块化，以便于在替换新用户界面时不影响业务和程序输出，同时还应该轻易做到 交互式界面和命令行之间的切换。

6、错误处理
大部分程序的代码90%是用来处理异常，只有10%的代码是用来处理正常逻辑功能，所以在架构中要制定一种统一一致的错误处理策略。
错处理要考虑的问题，或者是错误处理的checklist

1. 错误处理是进行纠正还是只是做检测。纠正实际上是容错；检测可以继续运行或者退出。

2. 检测时主动检测还是被动检测。
   主动检测 如：在用户输入参数时预处理
   被动检测 如：输入参数处理之后产生溢出。

3. 如何处理错误。
   可以直接丢弃 错误数据
   可以把错误进入到错误处理状态
   可以等程序处理完成，再通知错误

4. 错误处理约定。应该建立一整套有关错误消息处理的框架

7、容错性
容错的目标是系统出现错误之后，能够通过容错机制从错误中恢复过来。

容错策略

1. 检测错误直接回退执行之前，再试有限次(具体在网络通信中，网络或者设备不稳定时)
2. 使用备用代码或者逻辑（实际就是if-else语句）
3. 使用一种表决算法(根据实际业务逻辑，该功能有多种方法实现，采用多种方法后，取结果的均值)
4. 可以使系统功能退化或者跳过该错误处的功能（尤其是主功能出错时，可以置一个全局开关，暂时让系统空转）

8、输入输出和安全性
住哟啊包括IO模型的选择、处理非信任数据(包括用户的输入输出、cookies、配置文件和外部接口输入的数据)的规则、加密、错误消息的细致程度、保护内存中的秘密数据。

9、架构性能
指出系统使用的资源：速度、内存、成本之间的优先顺序，以及存在的不可控风险。

10、国际化/本地化
主要考虑 字符集编码的问题，中英文资源文件之间的切换。

11、变更策略
架构最大的挑战是，随时面临需求的变更，所以让架构足够灵活，能够适应变化。所以架构要以系统的可变更性作为首要目标进行设计。
简单的比如：在数据文件中加入版本号、设置保留字段或者将文件设计成能够添加新的文段。
架构设计checklist 参考书本p54