《代码大全》笔记一

《代码大全》笔记一

第一章 欢迎进入软件构建的世界

软件构建的过程

定义问题、需求分析、规划构建、软件架构、详细设计、编码与调试、单元测试、集成测试、集成、系统测试、保障维护。

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

一般而言，发现错误的时间要尽可能接近引入该错误的时间。

开发商业系统的项目往往受益于高度迭代的开发法；性命攸关的系统往往要求采用更加序列式的方法，“需求稳定”是确保“超高等级的可靠性”的必备条件之一。

计划好预先对大约80%的需求做出详细说明，并给“稍后再进行详细说明的额外需求”分配一定的时间。然后在项目进行过程中，实施系统化的变更控制措施——只接受那些最有价值的新需求。

选择序列化方法的原因

1.需求相当稳定

2.设计直截了当，而且理解透彻

3.开发团队对这一应用领域十分熟悉

4.项目风险很小

5.“长期可预测性”很重要

6.后期改变需求，设计和编码的代价可能较昂贵

与此相对的就是采用迭代化方法的原因

关于问题定义

1.“问题定义”只定义了“问题是什么”，而不涉及任何可能的解决方案。它是一个很简单的陈述，可能只有一到两页，并且听起来应该像一个问题。

2.问题定义应该用客户的语言来书写，而且应该从客户的角度来描述问题。通常不应该用计算机的专业术语来叙述。

架构的典型组成部分

####程序组织

架构应该定义程序的主要构造块。根据程序规模的不同，各个构造块可能是单个类，也可能是由许多类组成的一个子系统。每个构造块无论是一个类还是一组协同工作的类和子程序，它们共同实现一种高层功能。如果两个或多个构造块声称实现同一项功能，那么它们就应该相互配合而不会冲突。

主要的类

架构应该详细定义那些主要的类。它应该指出主要类的职责，以及该类如何与其它类交互。应该包括对该类的继承体系、状态转换、对象持久化等的描述。如果系统足够大，它应该描述如何将这些类组织乘一个个子系统。

数据设计

架构应该描述所用到的主要文件和数据表的设计。它应该描述曾经考虑过的其它方案，并说明做出选择的原因。

业务规则

用户界面设计

资源管理

安全性

性能

可伸缩性

可伸缩性是指系统增长以满足未来需求的能力

互用性

描述系统如何与其他软件或硬件共享数据或资源

国际化/本地化

输入/输出

错误处理

错误处理在架构层次上需要考虑的问题

1.错误处理是进行纠正还是仅仅进行检测

2.错误处理是主动的还是被动的

3.程序如何传播错误

4.错误消息的处理有什么约定

5.如何处理异常

6.在程序中，在什么层次上处理错误

7.每个类在验证其输入数据的有效性方面需要负何种责任

8.你是希望用运行环境中内建的错误处理机制，还是想建立自己的一套机制

容错性

架构的可行性

过度工程