3.1 先决条件重要性
优秀程序员的一个突出特点是他们采用高质量的过程来创建软件。这种过程在计划的开始、中间和末尾都强调高质量。
如果你只在一个计划即将结束时强调质量，那你注重的只是测试。
如果在一个计划的开始强调质量，这意味着你计划并要求设计一种高质量的产品。
3.1.l 造成准备不足的原因
一些程序员并不做准备工作，有两条忠告：第一，阅读一下下一部分工作的内容提示，或许你会从中发现一些你没想到的问题；第二，要注意自己的问题。
3.1.2 在进行创建工作之前必须做准备工作的论据
在你进行编码、测试和调试之前，学会这些论据，并且和你的老板推心置腹地谈谈技术项目的开发过程。
求助于逻辑推理：进行有效程序设计的关键之一就是认识到准备工作是非常重要的。
求助于类比：创建一个软件系统与其它需要耗费人力与财力的工程是一样的。
求助于数据：过去十五年的研究证明，一次完成是最好的选择，不必要的修改是非常昂贵的；通常的准则是，一旦引入错误，就尽早发现和消除它；错误在软件食物链中存留的时间越长，它的危害也就传播得越远。
3.2 问题定义先决条件
在进行创建工作之前你要满足的第一个先决条件，便是必须弄清楚你想要解决的问题是什么。
问题定义只描述要解决的问题是什么，根本不涉及解决方法；问题定义的工作是在需求分析之前进行，后者是对问题的更为详尽的分析；问题定义应该从用户的观点出发，使用用户的语言进行定义。
3.3 需求分析先决条件
需求详细描述了一个软件系统需要解决的问题，这是找到问题答案的第一步；这项活动也被称作“需求分析”、“需求定义”等。
3.3.1 为什么要有正式的需求
明确的需求是很重要的，因为：1)明确的需求可以保证是由用户而不是程序员决定系统的功能；2)明确的需求也可以避免引起争议；3)注意需求定义，也可以使得在开发工作开始之后，对系统作的改动最小。
充分进行需求分析是一个项目成功的关键，很可能比使用有效的创建技术还重要。
3.3.2 稳定需求的神话
有了稳定的需求，软件开发工作可能从结构设计到详细设计到编码，都平稳、顺利地进行。
3.3.3 在创建阶段如何对付需求变化
在创建阶段，为应付需求变化而应该采取的措施：1)用检查表来评估你的需求分析质量；2)让每个人都知道由于变化需求所付出的代价；3)建立一套更改控制过程；4)用开发的方法来容纳变动；5)放弃项目。
3.3.4 检查表
需求：这个需求检查表包含一系列关于你的项目需求的自测题。
需求内容、关于需求的完善性、关于需求的质量。
3.4 结构设计先决条件
软件结构设计是较高级意义上的软件设计，它是支持详细设计的框架；结构也被称为“系统结构”、“设计”、“高水平设计”或者“顶层设计”；一般说来，结构体系往往在一个被称为“结构定义”或者“顶层设计”的单一文件中进行描述。
为什么要把结构设计当成先决条件呢？因为结构设计的质量决定了系统概念上的完整性，而这又会决定系统的最终质量；好的结构设计可能使创建工作变得很容易，而坏的结构设计则使创建活动几乎无法进行。
3.4.1 典型的结构要素
程序的组织形式：一个系统结构首先需要一个总体上的概括性描述；在结构设计中，你应该能找出最终组织形式的几种方案，并且应该知道为什么选中了现在这种组织形式；在结构设计中，应该在程序中定义主要模块；每一个模块作什么应该明确定义；每个模块之间的交界面也应该明确定义。
变动策略：变动产生的原因可能是由于反复无常的数据结构，也可能是由于文件格式和系统功能改变，新的性能等而引起的；结构设计应该清晰地描述系统应付变动的策略；结构设计中应该说明用于延缓变动的策略。
购买而不是建造的决定：创建一个软件的最彻底的办法并不是创建—而是去购买一个软件；如果计划中要求使用已有的程序，那它就该指出如何使这些重新被使用的软件适应新的需求，而且它应该证明这个软件可以通过改动来满足新的需求。
主要的数据结构：结构设计应该给出使用的主要文件、表和数据结构，同时，还应给出考虑的替代方案并评审做出的选择；不应该允许一个以上的模块访问数据结构，除非是通过访问子程序，以使得这种访问是抽象的而且是可控的；如果一个程序使用了数据库，那么结构中应该规定这个数据库的组织形式和内容；最后，应该遵循数据守恒定律。
关键算法：如果结构设计依赖于某一特定算法，那它应该描述或指出这一算法。
主要对象：在面向对象的系统中，结构中应指出要实现的主要对象，它应该规定每一个对象的责任并指出每个对象之间是如何相互作用的，其中应包括对于排序层次、状态转换和对象一致性的描述；结构中还应该指出考虑的其它对象，以及选择这种组织形式的原因。
通用功能：用户界面、输入／输出、内存管理、字符串存储。
错误处理：需要考虑的问题包括：1)错误处理是纠正还是仅仅测试错误？2)错误测试是主动的还是被动的？3)程序是怎样对付错误的？4)处理错误信息的约定是什么呢？5)在程序中，应该在哪一个层次上处理错误呢？6)每一个模块检验输入数据合法性的责任级别有多高？
坚固性(Robustness)：是指在发现错误后，一个系统继续运行的能力；在结构设计中需要从几个方面表述坚固性：1)裕度设计(over-engineering)；2)断言(assertions)；3)容错性(fault tolerance)。
性能：性能目标包括速度和内存使用。
通用的结构设计质量准则：一个好的结构设计特征包括对于系统中模块的讨论，每个模块中隐含的信息，选用和不选用某方案的原因；概念完整性是最重要的；每一次变动都应与总体和设计概念相符；结构的目标应该清楚地说明；结构中做出每一个决定的动机都要阐明清楚；好的软件结构往往是机器和语言相互独立；结构设计应该恰好在过分定义和定义不足的分界线上；结构中不应该有任何部分让你感到不舒服。
3.4.2 检查表
结构设计：一个好的结构设计应该阐明所有问题，这个表并不是用于指导结构设计的，而只是想提供一种方法。
3.5 选择编程语言先决条件
当程序员使用自己所熟悉的语言时，其工作效率要比使用陌生的语言高得多。
使用高级语言编程，其效率和质量要比使用低级语言高得多。
一些语言比其它语言更擅长解释编程思想；程序员也可能同样受到他所懂得的程序语言限制；程序语言影响程序员的思想方法。
3.5.1 语言描述
Ada语言：是一种在Pascal语言基础上发展的通用高级语言，它是在国防部的要求和资助下发展起来的，特别适用于实时和嵌入式系统。
汇编语言：汇编语言，是一种低级语言，每一条语句都与一条机器指令相对应。
Basic语言：Basic原来是一种解释性语言，现在则解释性和编译性两种形式都有。
C语言：C是一种中级通用语言，有某些高级语言的特点，例如，结构化数据、结构化控制流、对于机器的独立性、丰富的操作指令等。
C++语言：C++是一种面向对象的语言，除了与C兼容之外，C++提供了多态性和函数重载功能，同时，它还提供了比C更坚固的类型检查功能。
Fortran语言：Fortran是一种高级语言，引入变量和高级循环的概念，主要在科学和工程计算中使用。
Pascal语言：主要特征是严格的类型、结构化控制创建和结构化数据类型。
3.5.2 语言选择快速参考表
3.6 编程约定
在高质量软件中，你可以发现结构设计的概念完整性与较低层次实现之间的密切联系。
在复杂的软件中，结构设计指导方针对程序进行结构性平衡，而实现指导方式则在较低层次上实现程序的和谐统一，使得每一个子程序都成为总体设计的一个可以信赖的组成部分。
在创建工作开始之前，一定要写明你将要采用的编程约定，约定说明一定要写得非常详尽，使得在编程过程中无法对其进行改动。
3.7 应花在先决条件上的时间
用于问题定义、需求分析和软件结构设计的时间，随项目需要的不同而不同。一般来说，一个运行良好的项目通常把20%～30%的时间用于先决条件。
3.8 改变先决条件以适应你的项目
先决条件随项目规模和正式性不同而变化。
3.9 小结
(1) 如果想开发一个高质量的软件，必须自始至终重视质量问题；在开始阶段强调质量往往比在最后强调质量更为有效。
(2) 程序员的份内工作之一便是向老板和同事宣传软件的开发过程，包括在编程开始前从事先决条件准备工作的重要性。
(3) 如果问题定义工作做得不好，那么在创建阶段，所解决的问题可能并不是用户真正要解决的问题。
(4) 如果需求分析工作做得不好，很可能因此而漏掉要解决问题中的重要细节；在创建工作后更改需求，要比在需求分析阶段进行更改的成本高20到100倍；所以，在开始编程前一定要确认需求定义工作一切正常。
(5) 在编程前规定好约定，在创建工作结束后再改变代码来满足约定几乎是不可能的。
(6) 在创建活动开始之前如果无法完成准备工作，可以尝试在不太稳固的基础上进行创建活动。
本章小结：
本章介绍了在创建软件之前，我们需要做什么。
实际的软件项目中，在动手编代码之前，我们要做的一件非常重要的事情就是需求评审。这件事情做得是否好，可以决定一个软件项目的成败。
所谓的“需求”，通俗地讲就是要开发人员做什么。由于我们不是直接和客户沟通，因此要经过一个叫做SE的角色来了解需求，这就不可避免地可能会出现偏差，即做出的东西不是客户想要的。
我们如何进行需求评审呢？一般操作如下：
第一步：SE(系统工程师)将需求写成一个文档，并预定一个会议室，叫上相关开发人员和开发经理去评审。这里的“评审”，其实就是大家坐在一起讨论，看文档上面写的东西能否实现。
第二步：开发人员和开发经理根据实际情况，发表意见，对于无法完成的需求予以驳回，或者是提出另外一种实现方式。
第三步：大家就争议较大的需求进行集中讨论，最终定出一个大家都可以接受的方案，并通知客户，看是否能够得到他们的认可。
第四步：在与客户沟通之后，SE编写一个最终的需求文档，并通知开发人员和开发经理，进而才可以正式启动开发。
在软件项目中，我们一定要把问题扼杀在最初的需求阶段，否则越到后面，修改起来越难，花费的成本也越高。
很多公司(包括一些大公司)，是没有“需求评审”这个环节的，这样的公司做出来的东西，一般都会有很多问题，而且项目亏损的可能性极大。