代码大全2阅读笔记2

3.4 需求的先决条件 Requirements Prerequisite

需求详细描述软件系统应该做什么。

• 为什么要有正式的需求。明确的需求有助于：
• 确保是用户（而不是程序员）驾驭系统的功能
• 避免争论
• 减少开始编程开发后的系统变更情况
• 稳定需求的神话：稳定的需求是软件开发的圣杯（最高目标，渺茫希望），平均需求会有25%的变化
• 在构建期间处理需求变更：
• 使用需求核对表来评估需求的质量
• 确保每个人都知道需求变更的代价
• 建立一套变更控制程序
• 使用能适应变更的开发方法
• 放弃这个项目
• 注意项目的商业案例

核对表：

• 针对功能需求
• 针对非功能需求（质量需求）
• 需求的质量
• 需求的完备性

3.5 架构的先决条件 Architecture Prerequisite

软件架构是软件设计的高层部分，是用于支撑更细节的设计的框架。

架构的典型组成部分：

1. 程序组织 Program Organization
1. 系统架构首先要以概括的形式对有关系统做一个综述
2. 选择最终组织结构的理由
3. 主要构造块，各个块的功能和责任，之间的同行规则
2. 主要的类 Major Classes
1. 应指出每个主要的类的责任，如何与其他类交互
2. 包含对类的继承体系、状态转换、对象持久化等的描述
3. 数据设计 Data Design：描述所用到的主要文件和数据表的设计
4. 业务规则 Business Rules：如果架构依赖于特定的业务规则，就应详细描述这些规则，并描述对系统设计的影响
5. 用于界面设计 User Interface Design：详细定义Web页面格式、GUI、命令行接口等主要元素
6. 资源管理 Resource Management：描述一份管理稀缺资源的计划（数据库连接、线程、句柄...）
7. 安全性 Security：描述实现设计层面和代码层面的安全性的方法
8. 性能 Performance：性能目标（速度、内存、成本和之间的优先顺序）
9. 可伸缩性 Scalability：指系统增长以满足未来需求的能力（用户数、数据库记录数）
10. 互用性 Interoperability：预计这个系统会与其他软件或硬件共享数据或资源
11. 国际化/本地化 Internationlization/Localization
12. 输入输出 Input/Output
13. 错误处理 Error Processing：棘手，90%的代码处理异常，10%处理常规情况
1. 纠正还是仅检测？
2. 检测是主动的还是被动的？
3. 如何传播错误？
4. 处理有什么约定？
5. 如何处理异常exceptions？
6. 在什么层次上处理错误？
7. 每个类在验证输入数据的有效性方面需要负何种责任？
8. 用内置的还是自己建立一套？
14. 容错性 Fault Tolerance：详细定义所期望的容错种类，增强系统的可靠性
15. 架构的可行性 Architectural Feasibility：各种能力、性能目标、有限的资源...
16. 过度工程 Overengineering：通常架构详细描述的系统会比需求更健壮
17. 关于“买”还是“造”的决策 Buy-vs.-Build Decisions：说明自己定制的组件应该在哪些方面胜过现成的
18. 关于复用的决策 Reuse Decisions：二次开发
19. 变更策略 ChangeStrategy：让架构足够灵活，能够适应可能出现的变化
20. 架构的总体质量 General Architectural Quality：整体，看上去自然而非拼凑

3.6 花费在前期准备上的时间长度 Amount of Time to Spend on Upstream Prerequisites

在需求、架构及其他前期计划方面投入：

• 10%~20% 工作量
• 20%~30% 时间