预构 笔记
简介
项目结束时，要进行回顾：
1. 评估开发过程： 学到的经验和教训； 问题的解决方案
2. 评估设计： 设计适合什么样的问题域； 开始应关注什么问题；什么样的需求变化导致系统大幅修改； 是否有更好的方案；
The System in so many words
1. 将 list of requirements 变成 user case。 需求也包括 reliability testability deployability and performance
2. user case 包括： 功能描述；错误描述；测试方案
3. 为概念创建清晰的名词
4. 建立原型
5. 查找能用上的已有功能模块
General Development Issues
1. start from big picture( overal archetecture 和 business purpose ) 决定要采用的技术
2. 使用接口交互：函数定义包括执行条件和返回结果
3. consistency is simplicity: code style convention; 采用通用设计
4. 对 assumptions and decisions 提供注释：问题，假设，策略
Getting the big picture
1. iteractive development
analysis:
重点明白 basic user case ，基本概念，概念间的关系(1:n 等)。界面显示和如何实现不重要
使用CRC ( class - responsibility - collaboration) 设计类的作用和类间的交互。选取一个用例，从确定的对象开始，通过交谈完成用例的活动，只能要求该类提供某种活动，而不能提供某种信息，当有工作没做时，在类中添加函数或创建新类。
在使用词汇时尽量固守在 问题领域，假设计算机不存在，人怎么解决问题。
一但解决一个会话，开始录音，则这种录音是动态模型，CRC卡片是静态模型
基本步骤：
了解问题域——要解决什么问题
识别用例——由终端用户完成，具有有用结果的任务
创建CRC和动态模型
design：
细节划分：设计属性和函数； 画出class diagram。global planning local designing 在增量开发中这样做
2. 功能性测试
在开始设计时，根据user case 设计草案，包括 basic use cases和misuse cases
测试策略可产生更好的设计
向用户进行测试反馈
3. 设计初期就要考虑系统的安全性
A few words on change
1. highly cohesion and loosely coupling 高内聚和低耦合
高内聚：是否可用一句话描述类的作用
低耦合：尽量使用 interface 和 delegate
2. 尽量不使用函数重载
3. 修改容易混淆的函数：修改名称，使用工厂方法替代构造函数
The First Release
1. 第一次版本发布后，要写总结日志：
- 人与人的交互方式及效果
- 总结改变了的设计方案和原因
- 理解错误
- 运行速度
- 缺少的信息
在小版本发布时有份简单的日志，主要版本发布时有份长的日志
2. 错误处理
具体的错误处理要和用户协商，最终显示给用户的信息应该不包括程序细节
3. 简单重构
需要读入信息的类，有一函数 Load
去处 fat class 和 big method
创建合适的包
类、文件、函数、属性有合适的名称
类，函数，属性的位置基本正确
4. 第一次迭代
只包括两个user case
Association and State
对象状态： 状态改变只影响一个函数时使用 switch，影响多个函数时使用state pattern
Interface and Adaptation
1. 得出 User case 后要及时和用户交互
2. 查询优化： 构造 ItemConfig 对应列表显示信息，使用Item显示该对象详细信息
3. 测试针对接口中的方法，而不是具体实现
4. 拆分接口：如果不同用户访问一个接口的不同函数，则需要拆分接口
5. 使用模板保证类和对象的一致性
Zip code and Interface
1. unwritten code
1. 定义需求
2. 编写测试脚本
3. 查找已有的组件
Sam is expanding
多系统间交互： 1. 建立中心数据库存放共享信息，但要考虑同步； 2. 两系统分开存放各自信息，并对外提供可交互接口
与外部系统交互： 1. 定义协议和接口 2. log每次访问和输入验证
当想要泛化但现在还没必要时，写在日志中。