代码大全 第2版【2025|PDF|Epub|mobi|kindle电子书版本百度云盘下载】

代码大全 第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;M654

图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