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

前期准备的重要性

使用高质量的实践方法是那些能创造高质量软件的程序员的共性。这些高质量的实践方法在项目初期、中期、末期都强调质量。
如果你在项目末期强调质量，那么你会强调系统测试。如果你在项目中期强调质量，那么你会强调构建实践。如果你在项目开始阶段强调质量，那么你会计划、要求并且设计一个高质量的产品。
由于构建活动是软件项目的中间阶段，在你开始构建的时候，项目前期工作已经或多或少为这个项目的成功或者失败打下了基础。
程序员是软件食物链的最后一环，架构师吃掉需求，设计师吃掉架构，而程序员则消化设计。

软件类型

3种常见的软件项目种类：商业系统（internet、游戏）、使命攸关的系统（嵌入式、游戏）、性命攸关的系统（嵌入式，航空，医疗）。

问题定义

问题定义有时称为“产品设想”、“设想陈述”、“任务陈述”、“产品定义”。问题定义在具体的需求分析之前，而需求分析是对所定义的问题的深入调查。
问题定义应该用客户的语言来书写，而且应该从客户的角度来描述问题。通常不应该用计算机的专业术语叙述。

需求

“需求”详细描述系统软件应该做什么，这是达成解决方案的第一步。

为什么要有正式需求？

明确的需求有助于
* 确保是用户驾驭系统的功能。
* 避免争论。
* 减少开始编程之后系统变更情况。
* 是项目成功的关键。
稳定的需求是软件开发的圣杯。

核对表：需求

在开始构建之前，用这份列表做一次“心智健全”检查，看看你的地基到底有多坚固。
针对功能需求
- [ ] 是否详细定义了系统的全部输入，包括其来源、精度、取值范围、出现频率等？
- [ ] 是否详细定义了系统的全部输出，包括其来源、精度、取值范围、出现频率、格式等？
- [ ] 是否详细定义了所有输出格式（Web页面、报表、等等）？
- [ ] 是否详细定义了所有的硬件和软件外部接口？
- [ ] 是否详细定义了全部外部接口，包括握手协议、纠错协议、通信协议等？
- [ ] 是否列出了用户想要做的全部事情？
- [ ] 是否详细定义了每个任务所用的数据，以及每个任务得到的数据？
针对非功能需求（质量需求）
- [ ] 是否为全部必要的操作，从用户视角，详细描述了期望响应时间？
- [ ] 是否详细描述了其他与计时有关的考虑。例如处理时间、数据传输率、系统吞吐量？
- [ ] 是否详细定义了安全级别？
- [ ] 是否详细定义了可靠性，包括软件失灵的后果、发生故障时需要保护的至关重要的信息、错误检测与恢复的策略等？
- [ ] 是否详细定义了机器内存和剩余磁盘空间的最小值？
- [ ] 是否详细定义了系统的可维护性，包括适应特定功能的变更、操作环境的变更、与其他软件的借口变更能力？
- [ ] 是否包含对“成功”的定义？“失败”的定义？
需求的质量
- [ ] 需求是用户的语言书写的吗？用户也这么认为吗？
- [ ] 每条需求都不与其他需求冲突吗？
- [ ] 是否详细定义了相互竞争的特性之间的权衡——例如，健壮性与正确性之间的权衡？
- [ ] 是否避免在需求中规定设计（方案）？
- [ ] 需求是否在详细程度上保持相当一致的水平？有些需求应该更详细地描述吗？有些需求应该更粗略地描述吗？
- [ ] 需求是否足够清晰，及时转交给一个独立的小组去构建，他们也能理解吗？开发者也这么想吗？
- [ ] 每个条款都与待解决的问题及其解决方案相关吗？能从每个条款上溯到它在问题域中对应的根源吗？
- [ ] 是否每条需求都是可测试的？是否可能进行独立的测试，以检验满不满足各项需求？
- [ ] 是否详细描述了所有可能的对需求的改动，包括各项改动的可能性？
需求的完备性
- [ ] 对于在开发之前无法获取的信息，是否详细描述了开发不完全的区域？
- [ ] 需求的完备是否能达到这种程度：如果产品满足所有的需求，那么它就是可接受的？
- [ ] 你对全部需求都感到很舒服吗？你是否已经去掉了那些不可能实现的需求——那些只为了安抚客户和老板的东西？

架构

软件架构是软件设计的高层部分，用于支撑更加细节的设计框架。通常会用一份独立的文档描述架构，这份文档称为“架构规格书”或者“顶层设计”。
架构典型组成部分
程序组织、主要的类、数据设计、业务规则、用户界面设计、资源管理、安全性、性能、可伸缩性、互用性、国际化/本地化、输入/输出、错误处理、容错性、架构可行性、过度工程、复用的决策、变更策略、架构的总体质量。

核对表：架构

- [ ] 程序的整体组织结构是否清晰？是否包含一个良好的架构全局观（及其理由）？
- [ ] 是否明确定了主要构造块（包括每个构造块的指责范围及与其他构造块的接口）？
- [ ] 是否明显涵盖了“需求”中列出的所有功能（每个功能对应的构造块不太多也不太少）？
- [ ] 是否描述并论证了那些最关键的类？
- [ ] 是否描述并论证了数据设计？
- [ ] 是否详细定义了数据库的组织结构和内容？
- [ ] 是否指出了所用关键的业务规则，并描述其对系统的影响？
- [ ] 是否描述了用户界面的设计策略？
- [ ] 是否将用户界面模块化，是界面的变更不会影响程序的其余部分？
- [ ] 是否描述并论证了处理I/O的策略？
- [ ] 是否估算了稀缺资源（如线程、数据库连接、句柄、网络带宽等）的使用量、是否描述并论证了资源管理的策略？
- [ ] 是否描述了架构的安全需求？
- [ ] 架构是否为每个类、每个子系统、或每个功能域提出空间与时间预算？
- [ ] 架构是否了如何达到可伸缩性？
- [ ] 是否描述了国际化/本地化的策略？
- [ ] 是否提供了一套内聚的错误处理策略？
- [ ] 是否规定了容错的方法（如果需要）？
- [ ] 是否证实了系统各个部分的技术可行性？
- [ ] 是否详细描述了过度工程的方法？
- [ ] 是否包含了必要的“买vs.造”的决策？
- [ ] 架构是否描述了如何加工被复用的代码，使之符合其他架构目标？
- [ ] 是否将架构设计得能够适应很可能出现的变更？

架构的总体质量
- [ ] 架构是否解决了全部需求？
- [ ] 有没有那部分是“过渡架构”或“欠缺架构”？是否明确宣布了在这方面的预期目标？
- [ ] 整个架构是否在概念上协调一致？
- [ ] 顶层设计是否独立于用作实现它的机器语言？
- [ ] 是否说明了所有主要的决策动机？
- [ ] 你。作为一名实现该系统的程序员，是否对这个架构感觉良好？

花费在前期准备上的时间长度

花费在问题定义、需求分析、软件架构上的时间，依据项目的需要而变化。一般来说，一个运作良好的项目会在需求、架构以及其他前期计划方面投入10%～20%的工作量和20%～30%的时间。

核对表：前期准备

- [ ] 你是否辨明了自己所从事的软件类型，并对所用的开发方法做出对应的剪裁？
- [ ] 是否充分明确定义了需求？而且需求足够稳定，能开始构建了？（详见需求核对表）
- [ ] 是否充分明确定义了架构，一边开始构建？（详见架构核对表）
- [ ] 是否已经指出你的（当前）项目中独有的风险（以避免构建活动面临不必要的风险）？

要点

延伸阅读

Professional software development，专业软件开发
The psychology of computer programming，程序开发心理学

需求

Software requirements，软件需求，描述需求活动的具体细节。
Mastering the requirements process，掌握需求过程。面向更高阶“需求”从业人员。
Competitive engineering，涵盖做需求工程、设计和设计演化、渐进式项目管理的方法。
IEEE recommended practice for software requirements specifications，编写软件需求规格书的指南。
《Swebok：guide to the software engineering body of knowledge》，详细描述了软件需求的主要知识。

软件架构

《Software requirements：styles and techniques》
《Practical software requirements： a manual of content and style》
《Writing effective use cases》
《Software architecture in practice》
《Pattern-oriented software architecture， volume 1：a system of patterns》
《Documenting software architectures：views and beyond》
《Evaluating software architectures：methods and cases studies》
《Patterns of enterprise application architecture》
《The unified software development process》
《recommend practice for architectural description of software-intensive system》

常规软件开发方法

《Software project survival guide》
《The rational unified process：an introduction》
《The unified software development process》
《Extreme programming explained：embrace change》
《Principles of software engineering management》
《Rapid development》
《Balancing agility and discipline：a guide for the perplexed》
《agile and iterative development：a manager‘s guide》