代码大全读书笔记（二）

第一部分 打好基础

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

3.1 前期准备的重要性

使用高质量的实践方法是那些能创造高质量软件的程序员的共性。

前期准备适用于现代软件项目吗？

准备工作的中心目标就是降低风险：一个好的项目规划者能够尽可能早地将主要的风险清除掉，以使项目大部分的工作能够尽可能平稳地进行。
最常见的项目风险：需求分析和项目计划。

准备不周全的诱因

那些分配去做前期准备活动的开发人员并不具备完成这一任务的专业技能
WISCA综合症/WIMP综合症：Why Isn’t Sam Coding Anything?或Why Isn’t Mary Programing?

关于开始构建之前要做好前期准备的绝对有力且简明的论据

诉诸逻辑

制定计划，管理上：需要的时间/人数/计算机台数，技术上：想要建造什么，防止浪费钱建造错误的东西，思考如何去做。

诉诸类比

程序员是软件食物链的最后一环。架构师吃掉需求，设计师吃掉架构，而程序员则消化设计。
针对将要构建的每一片段，先弄清楚哪些是最关键的需求和架构要素。

诉诸数据

发现错误的时间要尽可能接近引入该错误的时间。缺陷在软件食物链中呆的时间越长，它对食物链后级造成的损害就越严重。

3.2 辨明你所从事的软件的类型

迭代开发法对前期准备的影响

迭代式开发法与序列式开发法，都需要进行前期准备，能够减少成本。
预先详细说明100%的需求和设计是不切实际的，对绝大多数项目来说，尽早把哪些是最关键的需求要素和架构要素确定下来，是很有价值的

在序列式开发法和迭代式开发法之间做出选择

序列化方法考虑如下：

• 需求相当稳定
• 设计直截了当，而且理解透彻
• 开发团队对这一应用领域非常熟悉
• 项目的风险很小
• ”长期可预测性“很重要
• 后期改变需求、设计和编码的代价可能较昂贵

迭代开发考虑如下：

• 需求并没有被理解透彻，或者处于其他理由你认为它是不稳定的
• 设计很复杂，或者有挑战性，或者两者兼具
• 开发团队对这一应用领域不熟悉
• 项目包含许多风险
• “长期可预测性”不重要
• 后期改变需求、设计和编码的代价很可能较低

事实上，在软件开发中，适用迭代开发法的情况比适用序列式开发法的情况多得多

3.3 问题定义的先决条件

对这个系统要解决的问题做出清楚的陈述。
“问题定义”只定义了“问题是什么”，而不涉及任何可能的解决方案

问题定义应该用客户的语言来书写，而且应该从客户的角度来描述问题
“未能定义问题”的处罚是，你浪费了大量时间去解决错误的问题。这是双重处罚，因为你也没有解决正确的问题。

3.4 需求的先决条件

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

为什么要有正式的需求

• 有助于确保是用户（而不是程序员）驾驭系统的功能。
• 有助于避免争论
• 有助于减少开始编程开发之后的系统变更情况

需求稳定的神话

稳定的需求是软件开发的圣杯

在构建期间处理需求变更

• 使用需求核对表来评估你的需求的质量
• 确保每个人都知道需求变更的代价
• 建立一套变更控制程序
• 使用能适应变更的开发方法（演进原型法）
• 放弃这个项目
• 注意项目的商业条例
  
  

3.5 架构的先决条件

软件架构是软件设计的高层部分，是用于支撑更细节的设计的框架
架构的质量决定了系统的“概念完整性”，后者决定了系统的最终质量

架构的典型组成部分

程序组织

• 架构应该定义程序的主要构成块
• 明确各个构造块的责任
• 明确定义各个构造块的通信规则

主要的类

• 详细定义所用的主要的类
• 指出各个类的责任，以及该类如何与其他类交互
• 包含对累的继承体系、状态转换、对象持久化等的描述

数据设计

• 描述所用到的主要文件和数据表的设计
• 数据通常只应该由一个子系统或一个类直接访问
• 详细定义所用数据库的高层组织结构和内容

业务规则

• 详细描述特定的业务规则

用户界面设计

• 用户界面常常在需求阶段进行详细说明
• 模块化设计以便可以替换用户界面

资源管理

• 数据库连接
• 线程
• 内存
• 句柄
• …

安全性

• 描述实现设计层面和代码层面的安全性的方法

性能

• 详细定义性能目标

可伸缩性

• 系统增长以满足未来需求的能力

互用性

• 系统与其他软件/硬件共享数据和资源的任务实现

国际化/本地化

• 准备让程序支持多个locale的技术实现
• 字符集的支持情况

输入/输出

错误处理

• 错误处理是进行纠正还是仅仅检测？
• 错误检测是主动的还是被动的？
• 程序如何传播错误？
• 错误消息的处理有什么约定？
• 如何处理异常？
• 每个类在验证其输入数据的有效性方面需要负何种责任？
• 你是希望用运行环境中内建的错误处理机制，还是想建立自己的一套机制？

容错性

• 检测错误再试一次
• 辅助代码在主代码出错时使用
• 表决算法
• 产生一个无害的虚假值代替错误值
• 遇到错误时，让系统转入某种“部分运转”的状态，或“功能退化”的状态

架构的可行性

• 论证系统的技术可行性

过度工程

• 健壮性是指“系统在检测到错误后继续运行”的能力

关于“买”还是“造”的决策

• 购买软件或者免费下载的开源软件

关于复用的决策

变更策略

• 清楚描述处理变更的策略
• 指出“延迟提交”所用的策略

架构的总体质量

• 架构应该是带有少许特别附加物的精炼且完整的概念体系
• 架构应该描述所有主要决策的动机
• 优秀的软件架构很大程度上是与机器和编程语言无关的
• 架构应该踏在对系统“欠描述”和“过度描述”之间的那条分界线上
• 架构应该明确地指出有风险的区域
• 架构应该包含多个视角
• 架构不应该包含任何仅仅为了取悦老板的东西
• 架构不应该包含任何对你而言很难理解的东西
  
  

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

花费在问题定义、需求分析、软件架构上面的时间，依据项目的需要而变化，并取决于项目的规模

key point

• 构建活动的准备工作的根本目标在于降低风险。要确认你的准备活动是在降低风险，而非增加风险。
• 如果你想开发高质量的软件，软件开发过程必须由始至终关注质量。在项目初期关注质量，对产品的正面影响比在项目末期关注质量的影响要大。
• 程序员的一部分工作是教育老板和合作者，告诉他们软件开发过程，包括在开始编程之前进行充分准备的重要性。
• 你所从事的软件项目的类型对构建活动的前期准备有重大影响------许多项目应该是高度迭代的，某些应该是序列式的。
• 如果没有明确的问题定义，那么你可能会在构建期间解决错误的问题。
• 如果没有做完良好的需求分析工作，你可能没能察觉待解决问题的重要细节。如果需求变更发生在构建之后的阶段，其代价是“在项目早期更改需求”的20至100倍。因此在开始编程之前，你要确认“需求”已经到位了。
• 如果没有做完良好的架构设计，你可能会在构建期间用错误的方法解决正确的问题。架构变更的代价随着“为错误的架构编写的代码数量”增加而增加，因此，也要确认“架构”已经到位了。
• 理解项目的前期准备所采用的方法，并相应地选择构建方法。