前期准备
前期准备的重要性
不要立即开始写代码，要做好必要的需求分析和架构设计，写好需求文档和技术文档，防止浪费时间和精力制造错误的东西
需求核对表
针对功能需求：
1．是否详细定义了系统的全部输入，包括其来源、精度、取值范围、出现频率等？
2．是否详细定义了系统的全部输出，包括其目的地、精度、取值范围、出现频率格式等？
3．是否详细定义了所有的输出格式(如：web页面、报表等)？
4．是否详细定义了所有硬件及软件的外部接口？
5．是否详细定义了全部外部通信接口，包括握手协议、纠错协议、通信协议等？
6．是否列出了用户所要做的全部事情？
7．是否详细定义了每个任务所用数据，以及每个任务得到的数据
针对非功能需求（质量需求）
1.是否为全部必要的操作，从用户的角度，详细描述的期望的响应时间 ？
2.是否详细描述了其他与计时有关的考虑，如处理时间、数据传输率、系统吞吐量等？
3.是否详细定义了安全级别
4.是否详细定义了可靠性，包括软件失灵的后果、发生故障时需要保护的至关重要的信息、错误检查与回复的策略等？
5.是否详细定义了机器内存和剩余硬盘空间最小值？
6.是否详细定义了系统的可维护性，包括适应特定功能的变更、操作环境的变更、与其他软件接口变更的能力？
7.是否包含对“成功”的定义，“失败”的定义？
需求的质量
-
需求是用户书写的吗？
-
每条需求都不与其他需求冲突吗？
-
是否详细定义了相互竞争的特性之间的权衡
-
是否避免在需求中规定设计(方案)
-
需求是否在详细程度上保持相当一致的水平？有些需求应当更详细的描述吗？有些需求应该更粗略的描述吗？
-
需求是否足够清晰，即使转交给一个独立的小组去构建，他们也能理解吗？开发者也这么想吗？
-
每个条款都与待解决的问题及解决方案相关吗？能从每个条款上溯到它的问题中的对应跟源吗？
-
是否每条需求都是可测试的？是否可应进行独立的测试，以检验满不满足各项需求
-
是否描述了所有可能对需求的改动，包括各项改动的可能性
需求的完备性
1.对于在开始开发之前无法获得信息，是否详细描述了信息不完全的区域？
2.需求的完备度是否达到这种程度：如果产品满足所有需求，那么它就是可接受的？
3.你对全部需求都感觉舒服吗？你是否已经去掉了那些不可能完成的需求—那些只是为了安抚客户和老板的东西？
花费在前期准备上的时间长度
花费在问题定义，需求分析，软件架构上的时间依据项目的需要而变化，一般占据10%-20%的工作量和20%-30%的时间
良好的类接口
类的基础是抽象数据类型（我之前大部分时候没有使用抽象，只是把相关的方法和变量定义放在了一起，实际上是不符合面向对象变成原则的），抽象数据类型是指一些数据和 对这些数据所进行操作的集合。定义抽象类有助于代码规范，提高
创建类的原因
（1）为显示世界中的对象建模
（2）为抽象的对象建模
（3）降低复杂度
（4）隔离复杂度
（5）隐藏实现细节
（6）让代码更易重用
（7）把相关的操作包装到一起
应当避免的类
（1）避免创建万能类
（2）消除无关紧要的类
（3）避免用动词命名的类
防御式编程
三种处理进入垃圾的情况
（1）检查所有来源于外部的数据的值
（2）检查所有子程序输入参数的值
（3）决定如何处理错误的输入数据
断言
断言是指在开发期间使用的、让程序在运行时进行自检的代码
异常
用异常通知程序的其他部分发生了不可忽略的错误
只有真正例外的情况下才抛出异常
不能用异常来推卸责任
避免在构造函数和析构函数中抛出异常，除非在同一地方把他们捕获
在恰当的抽象层次抛出异常
变量
与《代码整洁之道》对变量的要求几乎一致
代码改善
软件质量的特性
外在特性：
（1）正确性：指系统规范、设计和实现方面的错误的稀少程度
（2）可用性：指用户学习和使用一个系统的容易程度
（3）效率：指软件是否尽可能少地占用系统资源，包括内存和执行时间
（4）可靠性：指在制定的必须条件下，一个系统完成所需要功能的能力-应该有很长的平均无故障时间
（5）完整性：限制、验证
（6）适应性：适应不同执行环境
（7）精确性：输出结果的精确程度
（8）健壮性：系统在接受无效输入或处于压力环境下持续正常运行的能力
内在特性：
（1）可维护性：指很容易能够对系统进行修改或新增功能，提高性能及修正缺陷
（2）灵活性：系统适用其他系统或者修改难易程度
（3）可移植性：运行环境的可移植性
（4）可重用性：指系统的某些部分可被应用到其他系统的难易程度
（5）可读性：指阅读或理解系统代码的难易程度，尤其是在细节语句的层次上
（6）可测试性：指的是可以进行何种程度的单元测试或者系统测试，以及在何种程度上验证系统是否符合需求
（7）可理解性：指在系统组织和细节语句的层次上理解整个系统的难易程度