代码大全 第2版PDF电子书下载

第1章 欢迎进入软件构建的世界 3

图1-1 构建活动用灰色的椭圆表示。构建活动主要关注于编码与调试，但也包含详细设计、单元测试、集成测试以及其他一些活动 4

图1-2 本书大致以图示的比例关注编码与调试、详细设计、规划构建、单元测试、集成、集成测试以及其他活动 5

第2章 用隐喻来更充分地理解软件开发 9

图2-1 文字写作这一隐喻暗示着软件开发过程是一种代价昂贵的试错（trial and error）过程，而非仔细的规划和设计 14

图2-2 很难将耕作这一隐喻恰当地引申到软件开发领域 15

图2-3 在简单结构上犯下错误，其惩罚也不过是一点时间，或是些许尴尬 17

图2-4 更复杂的结构需要更加仔细地规划 18

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

表3-1 修复缺陷的平均成本与引入缺陷的时间和检测到该缺陷的时间之间的关系 29

图3-1 修复缺陷的成本随着“从引入缺陷到检测该缺陷之间的时间”变长而急剧增加。无论项目是高度序列化（sequential）的（预先完成100％的需求和设计），还是高度迭代型（预先完成5％的需求和设计）的，这些都成立 30

表3-2 三种常见的软件项目种类，及其典型的良好实践 31

表3-3 跳过前期准备对于采用序列式开发法的项目和迭代式开发法的项目的（不同）影响 33

表3-4 关注前期准备工作对于采用序列式开发法的项目和迭代式开发法的项目的影响 34

图3-2 对于绝大部分的项目（即便是高度序列化的项目）来说，各种活动会在一定程度上有所重叠 35

图3-3 对于其他的项目，各种活动在项目开发期间会重叠起来。成功“构建”的关键之一，就是理解前期准备工作的完成程度，并据此调整你的开发方法 35

图3-4 “问题定义”为随后的开发过程打下基础 37

图3-5 在射击之前，确信你瞄准了正确的目标 38

图3-6 如果没有好的需求，你可能对问题有总体的把握，但却没有击中问题的特定方面 39

核对表：需求 42

图3-7 离开了良好的软件架构，你可能瞄准了正确的问题，但却使用了错误的解决方案。也许完全不可能有成功的构建 44

核对表：架构 54

核对表：前期准备 59

第4章 关键的“构建”决策 61

表4-1 高级语言的语句与等效的C代码语句行数之比 62

核对表：主要的构建实践 69

第5章 软件构建中的设计 73

图5-1 Tacoma Narrows大桥——一个险恶问题的实例 75

图5-2 一个程序中的设计层次。系统①首先被组织为子系统②。子系统被进一步分解为类③，然后类又被分解为子程序和数据④。每个子程序的内部也需要进行设计⑤ 82

图5-4 当子系统之间的通信没有任何限制时就会像这个样子 83

图5-3 一个有六个子系统的系统示例 83

图5-5 施加若干通信规则后，子系统之间的交互得以显著地简化 84

图5-6 收费系统由四种主要的对象构成，这些对象在本例中进行了一定的简化 88

图5-7 抽象可以让你用一种简化的观点来考虑复杂的概念 90

图5-8 封装是说，不只是让你能用简化的视图来看复杂的概念，同时还不能让你看到复杂概念的任何细节。你能看得到的就是你能——全部——得到的 91

图5-9 好的类接口就像是冰山的尖儿一样，让类的大部分内容都不会暴露出来 93

表5-1 常见设计模式 104

图5-10 G波利亚在数学领域发展的一套解决问题的方法，它同样可以用于解决软件设计中的问题（Polya 1957） 109

表5-2 设计文档的正规化以及所需的细节层次 116

核对表：软件构造中的设计 122

第6章 可以工作的类 125

表6-1 继承而来的子程序的几种形式 145

核对表：类的质量 157

第7章 高质量的子程序 161

核对表：高质量的子程序 185

第8章 防御式编程 187

图8-1 西雅图90号州际浮桥的一部分在一场风暴中沉没了，原因是未遮盖浮箱，而在风暴中进水，使得桥体过重而无法继续漂浮。在建设时要防范一些小事情，它们的严重性往往会超过你的预期 189

表8-1 支持几种流行的编程语言的表达式 198

图8-2 让软件的某些部分处理“不干净的”数据，而让另一些部分处理“干净的”数据，即可让大部分代码无须再担负检查错误数据的职责 204

核对表：防御式编程 211

第9章 伪代码编程过程 215

图9-1 一个类的创建过程可以千变万化，但基本上会以本图所示的顺序发生 216

图9-2 这些是创建一个子程序所需经历的主要活动，常是以图示的顺序进行 217

图9-3 在构建程序的时候，你将实施所有这些步骤，但不一定要按照任何特定的顺序 225

核对表：伪代码编程过程 233

第10章 使用变量的一般事项 237

图10-1 “长存活时间”意味着一个变量历经了许多语句，而“短存活时间”意味着它只历经很少的语句。“跨度”则表明了对一个变量引用的集中程度 246

图10-2 序列型数据就是按照一种确定顺序处理的数据 254

图10-4 迭代型数据是重复性的 255

图10-3 选择型数据允许你使用这一项或者那一项，但不会同时使用两者 255

核对表：使用数据的一般事项 257

第11章 变量名的力量 259

表11-1 更多变量名的例子，其中有好的也有差的 261

表11-2 变量名太长、太短或刚好合适的示例 262

表11-3 C++和Java的命名规则示例 277

表11-5 Visual Basic的命名规则示例 278

表114 C的命名规则示例 278

表11-6 用于文字处理程序的UDT示例 280

表11-7 语义前缀 280

核对表：变量命名 288

第12章 基本数据类型 291

表12-1 不同类型整数的取值范围 294

核对表：基本数据类型 316

第13章 不常见的数据类型 319

图13-1 各数据类型所用的内存量用双线框表示 324

图13-2 能帮助我们考虑指针链接步骤的示例图 329

表13-1 直接访问全局数据和通过访问器子程序访问全局数据 341

表13-2 对复杂数据一致和不一致的操作 342

核对表：使用不常见数据类型的注意事项 343

第14章 组织直线型代码 347

图14-1 如果代码组织良好，那么围绕各段的方框就不应该交叠，但有可能嵌套 352

图14-2 如果代码组织不良好，那么围绕各段代码的方框就会交叠 353

核对表：组织直线型代码 353

第15章 使用条件语句 355

核对表：使用条件语句 365

第16章 控制循环 367

表16-1 循环的种类 368

核对表：循环 388

第17章 不常见的控制结构 391

图17-1 递归式是对付复杂事物的很有价值的工具——在用于对付适当问题的时候 394

核对表：不常见的控制结构 410

第18章 表驱动法 411

图18-1 如图名所示，直接访问表允许你访问感兴趣的表元素 413

图18-2 信息并不是按照特定顺序存储的，每条消息用ID标识 417

图18-3 除了消息ID之外，每种消息有其自己的格式 418

图18-4 索引表不是直接访问，而是经过居间的索引去访问 425

图18-5 阶梯方法通过确定每项命中的阶梯层次确定其归类，它命中的“台阶”确定其类属 426

核对表：表驱动法 429

第19章 一般控制问题 431

表19-1 狄摩根定理的逻辑表达式的转换法则 436

图19-1 一个用数轴顺序做布尔判断的例子 440

表19-2 计算子程序中决策点数量的技术 458

核对表：控制结构相关事宜 459

第20章 软件质量概述 463

图20-1 强调软件的某个外在特性，可能会对另一些特性产生正面或者负面的影响，也可能没有任何影响 466

表20-1 各个小组在每个目标上的排名 469

表20-2 缺陷检测率 470

表20-3 极限编程的缺陷检出率评估值 472

图20-2 既不是最快的，也不是最慢的开发方法生产出的软件缺陷最多 475

核对表：质量保证计划 476

第21章 协同构建 479

核对表：有效的结对编程 484

核对表：有效的详查 491

表21-1 协同构建技术的比较 495

第22章 开发者测试 499

图22-1 随着项目规模的增大，开发者测试所耗费的开发时间百分比会更少。程序规模对测试的影响将在第27章“程序规模对构建的影响”做出详细描述 502

图22-2 随着项目规模的增长，在构建期间产生的错误所占的比例会下降，然而即使是在巨型项目里面，构建错误也会占全部错误的45％至75％ 521

核对表：测试用例 532

第23章 调试 535

图23-1 尝试用多种方法重现错误以准确判定错误原因 545

表23-1 变量名之间的心理距离示例 556

核对表：关于调试的建议 559

第24章 重构 563

核对表：重构的理由 570

核对表：重构总结 577

图24-1 相对于大规模修改，小的改动更容易出错（Weinberg 1983） 581

图24-2 真实世界混乱不堪并不等于你的代码也得同样糟糕。将你的系统看做理想代码、混乱的真实世界，以及从前者到后者的接口的结合 583

图24-3 改善产品代码的策略之一就是在拿到拙劣的遗产代码时对其重构，由此使其告别混乱不堪的真实世界 584

核对表：安全的重构 584

第25章 代码调整策略 587

表25-1 编程语言的相对执行时间 600

表25-2 常见操作所用时间 601

核对表：代码调整策略 607

第26章 代码调整技术 609

核对表：代码调整方法 642

第27章 程序规模对构建的影响 649

图27-1 交流路径的数量与项目成员数量的平方大致 650

表27-1 项目规模和典型的错误密度 652

图27-2 随着项目规模的增大，通常需求和设计犯的错误会更多。有些时候，错误仍然主要来自构建（Boehm 1981,Grady 1987,Jones 1998） 652

表27-2 项目规模和生产率 653

图27-3 小项目以构建活动为主。更大的项目需要做更多的架构、集成工作和系统测试工作才能成功。图中并未显示“需求工作”，因为其工作量并不（像其他活动那样）直接是程序大小的函数（Albrecht 1979；Glass 1982；Boehm、Gray and Seewaldt 1984；Boddie 1987；Card 1987;M 654

图27-4 软件构建的工作量与项目大小呈近似线性的关系。其他活动的工作量随项目规模扩大而非线性地增加 655

图28-1 本章讲述与构建相关的软件管理话题 661

第28章 管理构建 661

核对表：配置管理 669

图28-2 项目早期的评估结果注定不会很准确。随着项目推进，评估的准确度会越来越高。在项目进行过程中要定期地重新评估，用你在每一项活动中学到的知识去改进你对下一项活动的评估 673

表28-1 影响软件项目工作量的因素 674

表28-2 有用的软件开发的度量环节 678

表28-3 有关程序员如何分配时间的一种观点 681

第29章 集成 689

图29-1 华盛顿大学的露天足球场坍塌了，因为它在建造时不能支撑自己的重量。很可能在完工后它会足够牢固，但是它的建造顺序是错的——这是一个“集成”错误 690

图29-2 阶段式集成也称为大爆炸集成，其理由很充分 691

图29-3 增量集成有助于项目增长，就像雪球从山上滚下来时那样 692

图29-4 在阶段式集成中，你一次集成许多组件，很难知道错误在哪。错误既可能位于其中任何一个组件，也可能位于组件之间的连接处。在增量集成中，错误通常要么是在新的组件中，要么是位于新组件和系统之间的连接中 693

图29-5 在自顶向下的集成中，首先加入顶部的类，最后加入底部的类 695

图29-6 除了严格的自顶向下进行集成，你也可以在各个竖直划分的功能块中自上而下地进行集成 696

图29-7 在自底向上集成中，先集成底部的类，后集成顶部的类 697

图29-8 除了按纯粹的自底向上的步骤进行集成，你也可以分块进行这种集成。这样做模糊了自底向上集成和功能导向的集成（本章稍后将描述）之间的界线 698

图29-9 在三明治集成中，首先集成顶层类和广泛使用的底层类，然后集成中间层类 698

图29-10 在风险导向集成中，首先集成你认为最棘手的类，然后实现较容易的类 699

图29-11 在功能导向的集成中，以一组“构成一项‘可确认的功能’”的类为单位进行集成——通常（但不总是）一次集成多个类 700

图29-12 在T-型集成中，你建造并集成系统的一个直插到底层的块，以验证架构的假设，然后建造并集成系统的挑大梁部件，为开发余下的功能提供一个框架 701

核对表：集成 707

第30章 编程工具 709

核对表：编程工具 724

第31章 布局与风格 729

核对表：布局 773

第32章 自说明代码 777

核对表：自说明代码 780

核对表：好的注释技术 816

第33章 个人性格 819

第34章 软件工艺的话题 837

图34-1 程序可划分为多个抽象层。好的设计使你可以把很多时间集中在较高层，而忽略较低层的细节 846

第35章 何处有更多信息 855

参考文献 863

索引 885