软件驱魔：调试和优化遗留代码的艺术

Amazon五星级畅销书，遗留代码调试和优化领域的代表性著作，资深专家10余年经验结晶，长销不衰不仅从实用性角度深入、系统地讲解了调试和优化遗留代码的方法、技术和最佳实践，而且从源头上告知读者如何避免掉进维护遗留代码的泥潭。

更多精彩，点击进入品牌店查阅>>

《软件驱魔：调试和优化遗留代码的艺术》是遗留代码调试和优化领域的代表性著作，是作者10多年来在软件bug中“驱魔”经验的结晶，Amazon五星评论。不仅从实用性角度深入、系统地讲解了调试和优化遗留代码的方法、技术和最佳实践，而且从源头上阐述如何避免掉进维护遗留代码的泥潭，编写出易于维护，甚至不需要维护的高质量代码。
《软件驱魔：调试和优化遗留代码的艺术》共分7章：第1章介绍用于构建易于修改和调试的软件的相关技术；第2章讲解如何定位和消除软件bug；第3章提供理解问题以及程序的有用方法；第4章讲述调试器在计算机内部的工作原理；第5章深入探讨优化内存的相关技术和方法；第6章则探讨如何从CPU运行效率的角度优化代码的经验和技术；第7章结合社会和环境因素给出一些宝贵的建议。

Bill Blunden，拥有康奈尔大学物理学学士学位和凯斯西储大学运筹学硕士学位。资深系统维护专家，从事相关工作10余年，对系统软件的维护、遗留代码的调试和优化有非常深入的研究。活跃于计算机安全类社区，常与计算机安全领域多名世界级安全专家交流探讨。

译者序
前言
第1章预防药 1
1.1?核心问题 2
1.1.1上市时间的压力 2
1.1.2不确定的规格说明 4
1.1.3以功能特性换时间 5
1.1.4写下来 5
1.1.5复杂性 8
1.2防御性编程 9
1.2.1内聚和耦合 9
1.2.2错误输入检查 12
1.2.3数据范围 18
1.2.4日志 20
1.2.5文档 28
1.2.6为改变而设计 31
1.2.7增量精炼 33
1.3单元测试 34
1.3.1自动化测试的动机 35
1.3.2实现框架的步骤 36
1.3.3框架扩展 43
1.4工具的配置 46
1.4.1使用编译器警告 46
1.4.2发行版本的设置 47
1.5机器相关性 48
1.5.1字节序 49
1.5.2内存对齐 50
1.5.3数据类型大小 51
1.5.4虚拟机的好处 52
1.6小结 53
1.6.1底线：为什么出现bug 54
1.6.2改进清单：bug主动预防 54

第2章调试技巧 55
2.1初始步骤 56
2.1.1复现问题 56
2.1.2无法复现的问题 56
2.1.3验证bug是真实存在的 59
2.2消除缺陷：快速修复 60
2.2.1检查近期改动 60
2.2.2使用跟踪信息 61
2.2.3似曾相识 61
2.2.4明确何时放弃 61
2.3消除缺陷：科学方法论 62
2.3.1一般步骤 62
2.3.2定位问题：增量集成法 63
2.3.3定位问题：二分法 64
2.3.4理解问题 64
2.3.5防范失误 65
2.3.6诊断工具 67
2.3.7基础调试操作 75
2.4保留记录 80
2.4.1个人记录 80
2.4.2协同开发下的记录 81
2.5小结 84

第3章理解问题 86
3.1知识是如何丢失的 87
3.1.1竞争 87
3.1.2人员流失 89
3.1.3升职 90
3.2难懂的代码 91
3.2.1设计问题 91
3.2.2混淆 95
3.2.3误导性的代码 104
3.3反向工程 105
3.3.1通用策略 105
3.3.2对策 111
3.3.3建立知识库 116
3.4小结 118

第4章调试器内部机制 119
4.1调试器的种类 119
4.1.1机器调试器与符号调试器 119
4.1.2调试基础：自定义构建 125
4.1.3调试基础：系统调用 136
4.1.4调试基础：解释器 151
4.1.5内核调试器 155
4.1.6界面：命令行与图形用户界面 157
4.2符号调试器扩展 157
4.2.1动态断点 157
4.2.2单步执行 158
4.3应对策略 159
4.3.1系统调用 159
4.3.2移除调试信息 160
4.3.3代码盐 161
4.3.4混合内存模型 162
4.4小结 163

第5章优化：内存占用 165
5.1被遗忘的历史 167
5.2程序的内存布局 168
5.2.1场景：单段程序 169
5.2.2场景：仅代码段和数据段 170
5.2.3场景：所有4种段类型 171
5.3代码段 172
5.3.1剪切粘贴式编程 172
5.3.2宏 175
5.3.3僵尸代码 177
5.4数据段 177
5.4.1双重用途的数据结构 178
5.4.2位域 180
5.4.3压缩算法 181
5.5栈 183
5.5.1活动记录 184
5.5.2函数参数 188
5.5.3局部变量 190
5.6堆 191
5.6.1内存池 192
5.6.2回收 196
5.6.3延迟实例化 197
5.6.4跟踪内存使用情况 199
5.7小结 201

第6章优化：CPU周期 202
6.1程序控制跳转 203
6.1.1标签与GOTO 203
6.1.2函数参数 205
6.1.3带可变参数的函数 206
6.1.4系统调用 207
6.1.5递归 210
6.2程序控制分支 211
6.2.1查找表 211
6.2.2switch与if-else 213
6.2.3常见情况放在前，罕见情况放在后 215
6.3程序控制循环 215
6.3.1循环不变量 216
6.3.2函数调用 217
6.3.3数组引用 219
6.3.4分解复合布尔表达式 220
6.3.5循环展开 221
6.3.6循环干涉 221
6.3.7提取程序分支语句 221
6.4内存管理 222
6.4.1处理开销 223
6.4.2引用局部性 226
6.5输入/输出 227
6.5.1缓存 228
6.5.2缓冲 229
6.5.3先进的技术 230
6.6异常 231
6.6.1动态注册模型 234
6.6.2静态表模型 235
6.6.3处理开销 235
6.6.4滥用异常 237
6.7昂贵的操作 237
6.7.1消除常见的子表达式 237
6.7.2浮点运算神话 237
6.7.3强度折减 239
6.7.4同步 240
6.7.5简写操作符的神话 243
6.8快速修复 243
6.8.1更好的硬件 243
6.8.2约束问题 244
6.8.3编译器设置 244
6.9小结 245
6.10信息汇总 246

第7章最后的赠言 247
7.1对于源代码完整性的其他威胁 248
7.1.1时髦技术：一个案例研究 248
7.1.2洗脑101 249
7.1.3真正的问题 249
7.2保持书面记录 250
7.2.1悄悄记录 250
7.2.2隐私的神话 250
7.3历史总是重演 251

第1章
预防药
概要
老实说，相比那些在事后马虎的人而言，对那些在一开始就马马虎虎的人我会毫不犹豫地将其淘汰掉。这听起来相当冷酷无情，这的确冷酷无情。但是，这并不是那种“如果你无法忍受炙热，那就远离厨房”的提醒，它更深刻。我不愿与那些马马虎虎的人共事。这是软件开发的进化论。
—— Linus Torvalds 在Linux内核邮件列表里关于内核调试器的讨论中如是说
维护工程师的角色是驱逐那些潜藏在遗留软件里的邪恶幽灵，他们夜以继日维护着那些软件，上下交困，怨声载道，就像在穿过公司的那条小径上孤独前行。每天，他们都面临诸如：
修复bug
性能提升
这样的挑战。本书前面4章会重点关注于前者。最后两章会关注后者。
在1896年出版的一本名为 《Hawkin’s New Catechism of Electricity》 的电气手册中，首次提出bug这个术语，“在有限范围内，用于指明与电气设备相关的或电气设备工作中出现的任何缺陷故障”。这个术语在Rear Admiral Grace Murray Hopper（COBOL语言的发明者) 的帮助下逐步进化成用于表示计算机程序的故障。
与bug打交道是程序员最讨厌的工作任务之一。基于此，处理软件bug最好的时机就是在软件的实现阶段。换句话说就是，在问题即将成为软件发行版本中的一部分之前, 这些bug还没有“潜伏”到软件中，就修复它，这样，维护工程师在后续的工作中，就不用再陷入处理这些问题的烦恼中。包括Linus Torvalds在内的很多专业人士，都认同这套思路。
《孙子兵法》有云：“上兵伐谋，其次伐交，其次伐兵，其下攻城。攻城之法，为不得已。”解决大问题固然重要，杜绝小问题同样不可小视；解决大问题彰显才华卓越，杜绝小问题更显先见之明。作为软件工程师，要有远见，尽早地实现缺陷的隔离和修复。这样，你就不用再担心凌晨3点钟还会接到来自愤怒的系统管理员的电话。
本章讨论用于减少代码受到bug影响的预防性测量。如果你是正在参与构建一个全新软件的工程师，或者你正在新增软件特性，那么，你需要认真地阅读本章。此外，如果你已经接手了你从未写过的一个应用（并且这种情况应该很常见），那么，我推荐你先跳过本章，从下一章开始。一旦你处理完那些讨厌的bug，你可以再回到本章，使用本章介绍的技术来帮助你清理补丁程序。

……

据记载，在典型的软件项目生命周期中，维护阶段的成本占总成本的60%以上。研发需要什么样的排场，什么样的环境，一般都会在设计阶段确定，一旦完成第一个版本的部署，接下来的大部分资源都将用于修复bug，增加新的功能，并依次修复这些新的功能所产生的bug。多数的软件应用程序在发布后的开发周期如图1所示。

图1软件应用程序在发布后的开发周期
产品发布后的开发周期始于新增一个功能，或者提交一份bug报告。在这两种情况下，单元测试和系统测试常用来确定补丁代码是否工作正常。一旦程序的执行已经足够稳定，就可以通过剖析应用程序来定位性能瓶颈。然后实施各种各样的优化技术，以提高执行速度和减少内存占用。随着客户要求加入新特性和修复bug，这种周期会周而复始地发生，应用程序也正是这样不停地向前演进。
关于软件工程的大多数书籍更关注一个应用程序从立项到发布的各个开发阶段（例如，需求、分析、用例、实现等）。大家都知道，从头写一个程序会是一件更容易、更开心的事。而软件维护则更像是计算机科学中后娘养的孩子。大多数教授都不愿在公众面前提及，这是因为讨论维护工作的严酷性可能会引发各种问题……一些相当危险的问题。当你最终的辛苦努力只是做一件令人沮丧的维护工作时，你会质疑当初为什么要花四年去获取一个计算机学位。如果老师告诉学生有关软件工程这一职业的真相，肯定有很多学生会逃离计算机科学专业。一个较小的院系将成为削减预算的牺牲品，并且声誉扫地，所以你最好相信，教授们更愿意避开一些不愉快的事实，以保证他们班级的规模。
这本书不同。与其避而不见，不如直视软件行业肮脏的现实，让我们重温记录，看清自己未经审查的真相。为了有备无患，本书将探讨那些方便程序员调试和优化遗留软件的工具。换句话说，这本书要讨论的是：怎样维护那些已被他人“玩死”的软件。沏杯好茶，选个合适的椅子，开始你的重温之旅，但不要抱怨我没提醒你。
一个海军陆战队侦察员曾经告诉我，武术家没有资格谈论哪些技战术具有“战斗力”，除非他们曾经在遇到生命危险的时候使用过。本着这种精神，我觉得本书不该轻率地提供关于软件维护的建议，除非作者在压力非常大的情形下使用过它们。这本书倾向于具有实战价值的战术而特意避免了象牙塔里的抽象概念。我对自己曾经所使用过的简单工具情有独钟，一般的维护工程师并没有太多的时间浪费在云图或时髦的开发方法上。维护工程师有活儿要干，并且必须立刻搞定。而本书所介绍的战术，就是在战壕里，在毫无准备的情况下就可以使用的战术。
历史动因
早在铁器时代（即20世纪60年代末和70年代），大多数软件工程师没有太多的计算机资产可以使用。像房间那么大的CDC 6600计算机只有65 000 个60位字的内存（小于一兆字节）。在这样的环境中，对于工程师而言，为了节省空间，每一个位都是非凡的长度，不容浪费。同时，处理器速度也是一个严重的问题。大多数人在前一天下午把程序留给系统操作员，等到第二天再回来取结果。因此，当时工程师们不得不认真平衡内存使用及需求，并且尽量减少消耗的CPU周期数。
当然，这种情况已经得到改变。1998年，我负责的Windows NT工作站有两个450MHz奔腾处理器，2GB内存。CDC 6600售价为700万美元。而我的NT工作站的成本不足5000美元。今天的工程师不再需要面对从程序中挤压每盎司性能的压力（我几乎可以听到CDC工程师发牢骚，“想当年……”）。说穿了，我们可以变得懒惰，是因为硬件在帮助我们弥补空缺。如果程序运行得不够快，我们可以通过更多的硬件来解决，随着廉价配件的不断涌现，在短期内，这是一个现实的解决方案。
但总有走到尽头的一天。物理定律要求电子的电路通路大于3个氢原子。一旦这条通路变得比这更窄，电子就不再表现为基本粒子，而变得像逃犯一样乱窜（即出现量子隧穿）。这意味着计算机处理器的收缩尺度是有极限的。终有一天，制造商不再有免费的午餐吃。在某个时刻，为了提高计算能力，势必需要让处理器变得更大，以容纳更多的晶体管。
真到了那一天，提高软件性能的重担又将重新压到软件工程师的肩上。需要发明更好的算法及其实现方式。发生在20世纪60年代的优化工作将重新出现在下一代推动应用程序性能的急先锋身上。
注意
究竟什么时候我们会遇上这个瓶颈？我确信大多数芯片提供商并不期望那样。1989年，英特尔发布了80486，它的设计尺度是一微米（百万分之一米）。炭疽病菌的长度大约是1～6微米。人的头发的直径大约是100微米。据戈登·摩尔的观察，给定区域内晶体管的数量每18个月就会增加一倍，这就是众所周知的摩尔定律。换句话说，晶体管的设计尺度每3年就会减半。如果把1989年作为一个起点，当时晶体管的设计尺度为1微米，那么你应该能够通过简单计算得到，这样的演进在2022年将会结束。即使CPU厂商拿得出来一些东西，我怀疑在2100年后，CPU也不可能持续地收缩变小。Zarathustra如是说。
在铁器时代，调试工作常常伴随着读取十六进制转储日志和重建栈帧。找bug是痛苦费时的工作。因此，工程师们提出了精确的策略，以防止bug发生及在它们出现时能够快速地修复它们。今天，大多数工程师只需在代码中放置断点，通过GUI调试器单步调试自己的程序就可以了。GUI调试器和霰弹式修改（shotgun surgery）已经取代了老一辈工程师们引以为豪的探测技能。
我并不是说GUI调试器不好，事实上，我本人也非常喜欢它。我只是说，有时仅凭GUI调试器无法发现问题的根源。在这些情况下，必须通过系统的学习和实践磨炼出来的诊断技能才能解决问题。除了GUI调试器，可以使用这些技能来解决难题。
有效地使用工具并没有坏处，除非你完全依赖于它们。这让我想起艾萨克?阿西莫夫（Issac Asimov）写的一个叫做“电的感觉”的故事。在这个故事中，后代变得如此依赖于计算机，以至于完全忘记了如何执行基本的算术运算。在故事的结尾，主角之一在他的头脑中进行乘法运算：
9乘以7，舒曼深感满意，是63，我不需要一台电脑来告诉我这个结果了。我所拥有的头脑就是一台计算器，这种感觉真是太惊人了。
随着时间的推移，软件应用程序变得越来越大。回到1981年，第一版的PC DOS大约有4000行汇编代码。快进到20世纪90年代中期，Windows NT 4.0超过了1600万行代码。21世纪，我们可能会看到达到10亿行代码的软件应用程序。虽然现代的调试工具令人印象深刻，但随着软件的复杂度曲线不断地攀升到最高点，当代开发人员所采用的非正规方式并不足以应对。
虽然一般软件工程师的优化和调试技巧已经退步，但随着卓越的硬件和工具不停地出现，称职的工程师依然会花时间去掌握这些被遗忘的艺术。时间和精力的投资将以技能的增长作为回报，而这些技能会使他们成为更好的工程师。没有什么比在凌晨3:00被愤怒的客户叫醒更惨的了。有了这本书，你可以免受打扰，安心地睡个好觉。
本书读者对象
根据美国劳工统计局数据，2001年全美范围内有超过100万的软件工程师受雇用。其中大概有半数的工程师做着各种各样的维护工作。因此，这本书针对很大范围的软件从业人员。
维护编程工作没有什么吸引力。它更像是在钢厂工作：繁琐和充满危险。管理层专门高薪招聘的顾问，也只是完成早期工作而已，他会像逃避瘟疫一样地远离维护工作。为什么呢？因为维护工作够糟糕，所以咨询架构师尽力避免它。这份工作相当单调乏味，令人沮丧，平庸至极，毫无成就感可言。这就是为什么他们愿意把这份工作给你这样一个新来的家伙。
一般维护工程师通常会得到几千行代码和一些简单说明，然后被告知需要对其进行一些改进。他们很难从原始开发团队中分得一杯羹，而且往往面临的是更严格的工期。此书献给那些奋战在昏暗的隔间里，喝着隔夜咖啡，默默无闻的维护程序员。他们默默地问自己：“我是如何跑来接手这个烂摊子的？”
世界上的维护工程师们：我感受到了你们的痛苦。
本书结构
时至今日，软件开发往往会遵循一系列基本步骤，包括构建、测试、调试和调优。有很多介绍这种一般流程的模型。例如，久负盛名的瀑布模型（参见图2）就是最早期描述这些开发步骤是如何有序开展的模型。

图2瀑布开发模型
许多工程师以各种理由嘲笑瀑布模型。在今天的硅谷时代，整个开发过程只有两个步骤，那就是实现和维护，以及由谁来决定程序执行的边界。
本书共分7章。我试图通过第1章介绍几个技巧，或许这样，你就可以跳过接下来的三章，即我提出建议，指出如何编写bug较少的代码。如果你没有获得一个令人羡慕的职位，从头开始编写软件，那么你可以忽略第1章。第2～4章重点讨论优雅的调试艺术。我不仅着眼于调试代码的策略，还检查调试器内部是如何运作的。
除了调试之外，大部分维护工程师将工作时间花在了提高程序性能的调优上。第5章和第6章将专门解释如何更有效地利用计算机的资源。本书最后一章会给出一些来之不易的忠告。
下面给出每个章节更详细的介绍。
第1章：预防药
程序的原作者几乎总是对大多数bug负责。那些将一个软件从无到有构建起来的工程师，具有特权地位，他们有唯一的机会制定约定，以尽量减少在他们的创作中嵌入bug的数量。该章重点讨论那些可以用于构建易于修改及调试的软件的相关技术。
第2章：调试技巧
该章介绍如何按步骤来定位和消除软件bug。开始将讨论如何验证你所要处理的问题实际上是一个bug。接下来，会讨论科学的方法，并解释如何将其应用到bug的处理中。坚持你的工作，并为后续工程师提供跟踪指南，该章着眼于可用于跟踪维护工作的方法。