<<代码大全》 笔记
一．担任项目主管时，要充分认识到项目前期准备的重要性，否则项目可能会失败。这是必须的。
1. 定义各类人员配置、定义硬件配置，定义问题、定义需求、定义架构，定义公用模块，划分任务
2. 不同的类型的项目遵循不同的项目管理。
3. 根据不同的情况选择序列开发和迭代开发。
a. 需求是否稳定
b. 设计是否直接，是否复杂，是否有挑战性
c. 开发团队是否对该领域是否熟悉
d. 项目风险是否大
e. “长期可预测性”是否重要。
4． 问题定义：
a. 问题定义应该用客户的语言进行描述
5. 需求的先决条件， 要充分的描述需求，时项目成功的关键。
a. 使用需求核对表来评估需求
b. 确保每个人知道变更需求的代价
c. 建立一套变更控制程序。
6. 架构的先决条件
a. 程序组织，以概括的形式对有关系统做一个综述，明确定义各个构造块的责任，每个构造块对其他的构造块了解到最小
b. 主要的类。定义各个类的责任，以及如何进行交互，描述如何将这些类组织成一个子系统。80/20原则
c. 数据设计，定义数据表
d. 业务规则对架构的影响
e. 用户界面，架构应该模块化，方便进行界面的替换。
f. 描述资源管理。如内存，数据库连接，线程。
g. 描述实现设计层面和代码层面的安全性的方法。
H. 定义性能目标
I. 可伸缩性，应对用户数量和服务器数量，数据库记录，交易量的增长。
j. 如何实现国际化
M.错误处理,纠正还是检测，主动还是被动，如何传播错误，错误消息的处理约定，如何处理异常，每个类验证数据负何种责任？是否统一验证还是各负其责。
N. 容错性
O. 架构的可行性。技术的可行性。
p.避免过度工程。
Q.买还是造？
R．关于对已存在的模块的复用
S.对变更的支持策略
Z. 不要过度架构，在概念上协调一致，独立机器和语言，说明决策动机
二. 深入一种语言编程而不是在一种语言上编程。
1. 确定编码约定
2. 规定由软件架构确定的编码实践，处理错误、安全，接口，重用代码，性能等
3. 规定checkin是否经过某些步骤
4. 是否要编写测试用例
5. 是否要rview，集成测试，在checkin之前
6. 选择版本工具，测试工具。
三. 架构设计
1) 设计目标
1. 最小的复杂度，做出简单且易于理解的设计
2. 易于维护
3. 松散耦合
4. 可扩展性
5. 可重用性
6. 高扇入
7. 低扇出
8. 可移植性
9. 精简型
10. 层次性（对旧代码进行隔离）
11. 标准性
设计的曾侧
2) 设计层次
1. 软件系统->分解子系统->分解包中的类->数据子程序
2. 分解子系统
A. 限制不同子系统的通信，不要出现环形
3. 分解为类，确保类的接口，和用单个类来实现
4. 子程序的内部设计，编写伪代码，选择算法等
3) 启发式构造块
1． 找出现实中的对象
a. 辨识对象的方法和数据
b. 可以对对象的操作
c. 与其他对象的操作（继承，包含）
d. 那些是可见的哪些是不可见的
e. 定义公开的接口
2． 进行抽象
3． 进行封装
4． 继承能简化设计时就继承
5． 信息隐藏，在所有层次上都具有很大作用（类型，常量，方法等），隐藏复杂度，隐藏变化，
6． 找出容易改变的区域
a. 找出来容易发生变化的项目（需求清单上应列出
b. 把容易变化的项目分离（单独划类，或封装到一个类里面）
c. 把容易变化的项目进行隔离（保持接口不发生变化）
1. 业务规则，硬件变化，输入输出，状态变量（枚举和子程序判断）
7. 预料不同程度的变化，应用不同的策略应对。首先定义对客户有用的最小子集，然后微小的步伐扩展系统，应用隐藏的原则设计区域。
8. 保持松散耦合。创建小的，直接的，清晰的的类和子程序时它们与其他的类或子程的关系尽可能的灵活。
a. 减小模块间的连接数和公用方法
b. 可见性，
c. 灵活性，指模块间的连接是否容易改动
d. 一个模块越容易被其他模块调用，则耦合关系就越松散。
e. 一个模块不应该了解被调用模块的处理细节
9. 查阅相关的设计模式
10. 高内聚性
11. 构造分层
12. 严格描述类契约
13. 分配职责（分配对象职责）
14. 为测试而设计
15. 避免失误
16. 有意识的选择绑定时间。晚绑定和早绑定，变量的赋值时间
17. 创建中央控制点
18. 考虑使用蛮力突破
19. 画一个图
20. 保持设计模块化
四．可以工作的类
i. ADTS
1. ADTS ，指一些数据和对这些数据的操作
A. 隐藏细节
B. 让接口提供更多的信息
C. 更容易提高性能
D. 让正确性显而易见
E. 自我说明
F. 无需到处传递数据
2. 把常见的数据类型创建为ADT并使用这些ADT，不再使用底层数据，尽可能的使用高层抽象。
3. 把像文件的常见对象当成ADT
4. 简单的事物也可以当做ADT
5. 不要让ADT依赖于存储介质
ii. 良好的接口
1. 类的接口应该展现一致的抽象层次。可以进行分拆出多个明确的ADT，或进行改造
2. 一定要理解类所实现的抽象是什么，尽可能的少暴露信息。
3. 提供成对的服务。
4. 把不相关的信息转移到其他类中
5. 尽可能的让接口可编程，而不是表达语义（断言），使用编译器即可以进行检查
6. 谨防在修改时破坏接口的抽象。
7. 不要添加与接口抽象不一致的公用成员。
8. 同时考虑抽象性和内聚性。
iii. 良好的封装
1. 尽可能的限制类和成员的可访问性。采用哪种方式能最好的保护接口抽象完整性。
2. 不要公开暴露成员数据。
3. 避免把私用的的实现细节放入类的接口中。
4. 不要对类的使用者做出任何假设。
5. 避免使用友元类
6. 不要因为一个子程序仅使用公用子程序，就把它归于公开接口。
7. 让阅读代码比编写代码更方便。
8. 警惕从语义上破坏封装性。调用方不是依赖于公开接口而是依赖于类的私有实现。
9. 留意过于紧密的耦合关系。
iv. 有关设计和实现的问题
1. 警惕超过7格数据成员的类
2. 要么使用继承并进行详细说明，要么就不用它。
3. 遵循LIskov替换原则，才能使用继承。
4. 确保只继承需要继承的部分
5. 不要覆盖一个不可覆盖的成员函数
6. 把公用接口数据和操作放到继承树种尽可能高的位置上
7. 只有一个实例的类是值得怀疑的。
8. 只有一个派生类的基类也是值得怀疑的。
9. 派生类覆盖了某个子程序，但其中没做任何操作，值得怀疑的，可以通过重新进行对象切割，分离变化。
10. 避免让继承体系过深。
11. 尽量使用多态，避免大量类型检查。（case语句）
12. 让所有数据都是private
13. 如果多个类共享数据而非行为，则用包含
14. 如果多个类共享行为而非数据，使用继承
15. 如果既共享行为和数据，使用继承
16. 由基类控制接口时，使用继承，如果自己控制接口，使用包含。
v. 成员函数变量构造函数
1. 子程序数量尽可能的少
2. 减少类所调用的不同子程序的数量
3. 对其他类的子程序调用尽可能的少
4. 减少所实例化的对象的种类
5. 减少被调用的对象的不同子程序的数量
6. 减少由其他对象韩对的对象的子程序的数量
7. 如果可能在构造函数中初始化所有的数据成员
8. 优先使用深层副本。
vi. 创建类的理由
1． 对现实世界进行建模
2． 抽象对象尽享建模
3． 降低复杂度
4． 隔离复杂度
5． 隐藏细节
6． 限制变化影响的范围
7． 隐藏全局数据
8． 让参数传递更顺畅
9． 创建中央控制
10． 更好的复用
11． 为程序族做计划
12． 实现特定的重构
13． 把相关操作放在一起