读代码大全2——第三章 三思而后行：前期准备

只需要做几个大项目，就能体会到：事先做好计划能避免很多压力。

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

在实现一个系统之前，需要理解 这个系统应该做什么 以及 它应该如何做到这些

诉诸逻辑

思考如何去做

诉诸类比

架构师吃掉需求，设计师吃掉架构，程序员消化设计。

诉诸数据

两种较好的方案

1. 计划好预先对大约80%的需求做出详细说明，并给“稍后再进行详细说明的额外需求”分配一定的时间。然后再项目进行过程中，实施系统化的变更控制措施——只接受那些最有价值的新需求；
2. 预先只对最重要的20％的需求做出详细说明，并且计划以小幅增量开发软件的剩余部分，随着项目的进行，对额外的需求和设计做出详细说明。

在构建期间处理需求变更

• 确保每一个人都知道需求变更的代价：最简单的对付这种新功能中毒症患者的方法是说：“这听起来是一个不错的主意。不过由于它不是需求文档里的内容，我会整理一份修订过的进度表和成本估计表，这样你可以决定是现在实施，还是过一阵子再说。”
• 建立一套变更控制程序：你知道自己只需要在特定的时候处理变更；而客户知道你打算处理他们的提议。
• 使用能适应变更的开发方法
• 放弃这个项目
• 注意项目的商业案例：那些记得“考虑自己的决定所带来的商业影响”的程序员的身价与黄金相当。
• 使用需求和对表来评估需求的质量
  • 针对功能需求
    • 是否详细定义了系统的全部输入，包括其来源、精度、取值范围、出现频率等？
    • 是否详细定义了系统的全部输出，包括目的地、精度、取值范围、出现频率、格式等？
    • 是否详细定义了所有输出格式（Web页面、报表，等等）？
    • 是否详细定义了全部外部通信接口，包括握手协议、纠错协议、通信协议等？
    • 是否列出了用户想要做的全部事情？
    • 是否详细定义了每个任务所用的数据，以及每个任务得到的数据？
  • 针对非功能需求（质量需求）
    • 是否为全部必要的操作，从用户的视角，详细描述了期望相应时间？
    • 是否详细描述了其它与计时有关的考虑，例如处理时间、数据传输率、系统吞吐量？
    • 是否详细定义了安全级别？
    • 是否详细定义了可靠性，包括软件失灵的后果、发生故障时需要保护的至关重要的信息、错误检测与恢复的策略等？
    • 是否详细定义了机器内存和剩余磁盘空间等最小值？
    • 是否详细定义了系统等可维护性，包括适应特定功能的变更、操作环境的变更、与其它软件的接口的变更能力？
    • 是否包含对“成功”对定义？“失败”的定义呢？
  • 需求的质量
    • 需求是用用户的语言书写的嘛？用户也这么认为吗？
    • 每条需求都不与其它需求冲突吗？
    • 是否详细定义了相互竞争的特性之间的权衡——例如，健壮性与正确性之间的权衡？
    • 是否避免在需求中规定设计（方案）？
    • 需求是否详细程度上保持相当一致的水平？有些需求应该更详细地描述吗？有些需求应该更粗略地描述吗？
    • 需求是否足够清晰，即使转交给一个独立的小组去构建，他们也能理解吗？开发者也这么想吗？
    • 每个条款都与待解决的问题及其解决方案相关吗？能从每一个条款上溯到它在问题域中对应的根源吗？
    • 是否每条需求都是可测试的？是否可能进行独立的测试，以检验满不满足各项需求？
    • 是否详细描述了所有苦难的对需求的改动，包括各项改动的可能性？
  • 需求的完备性
    • 对于在开始开发之前无法获取的信息，是否详细描述了信息不完全的区域？
    • 需求的完备度是否能达到这种程度：如果产品满足所有需求，那么它就是可接受的？
    • 你对全部需求都感到很舒服吗？你是否已经去掉了那些不可能实现的需求——那些只是为了安抚客户和老板的东西？

架构的典型组成部分

程序组织、主要的类、数据设计、业务规则、用户界面设计、资源管理、安全性、性能、可伸缩性、互用性、国际化／本地化、输入输出、错误处理、容错性、架构的可行性、过度工程、关于“买”还是“造”的决策、关于复用的决策、变更策略、架构的总体质量

架构核对表

针对各架构的主题

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

架构的总体质量

• 架构是否解决了全部需求
• 有没有哪个部分是“过度架构”或“欠架构”？是否明确宣布了在这方面的预期指标
• 顶层设计是否独立于用作实现它的机器和语言
• 是否说明了所有主要的决策的动机
• 你作为一名实现该系统的程序员，是否对这个架构感觉良好

推荐的书籍

掌握需求过程 人民邮电出版社

编写有效用例 机械工业出版社

软件架构实践 清华大学出版社

面向模式的软件体系结构 卷1:模式系统 机械工业出版社

软件架构编档 清华大学出版社

软件架构评估 清华大学出版社

企业应用架构模式 机械工业出版社

统一软件开发过程 机械工业出版社

快速软件开发——有效控制与完成进度计划 电子工业出版社

解析极限编程——拥抱变化 人民邮电出版社

要点

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