第1章 0.000000095的误差夺走28条生命 1
飞向美空军基地的“飞毛腿”导弹 1
“爱国者”导弹系统结构 3
导弹与软件的对决 5
美军的应对 6
“爱国者”注定这天要出事 7
第2章 遥远的火星探测之路:
软件错误导致两架探测器成为火星尘埃 11
太空探测的“文艺复兴” 11
苏联:迈出火星探测第一步 11
美国:火星探测首次成功 14
第一架火星着陆器 15
火星探测的主力军——美国 18
火星探测重新升温 18
NASA的火星探测计划 19
MCO尝试进入轨道 20
MCO通信中断 21
气动减速 22
单位标记不一致导致的悲剧 23
另一台探测器:MPL 26
虽然已进入火星大气层,但是…… 26
MCO与MPL留下的教训 27
第3章 “喂?喂?”一行代码导致的AT&T;长途电话系统瘫痪事件 29
AT&T;的历史 29
值得信赖的AT&T;长途网络 31
出现网络故障 33
问题的起因在于一行错误代码 35
电话事故之后 35
第4章 软件错误带来的黑暗:2003年美国东北部大停电 39
韩国9·15停电事故 39
2003年美国东北部大停电 41
灾难开始 42
接连跳闸 46
最后的堡垒——Sammis-Star 345千伏输电线 48
临界点 51
iPad上市当天排起的长队 53
为什么没有处理预警? 56
第5章 不灭的“约克城”号 59
约克城 59
太平洋战争和“约克城”号 59
军费缩减计划示范舰 67
光荣的硬件,不争气的软件 68
第6章 因特网蠕虫病毒的开始——莫里斯蠕虫 71
互联网的特性 71
具备攻击与防御能力的软件 72
软件漏洞:蠕虫病毒出现 72
和蠕虫的斗争 74
“大虫”后续 76
莫里斯事件逸闻 77
第7章 软件也能使战机坠毁 79
瑞典JAS 39“鹰狮”战斗机坠毁事故 80
“鹰狮”试飞机坠毁 80
再次坠毁 81
原因在于软件 83
航空器中软件的作用日益突出 84
第8章 70亿美元的烟花秀:
阿丽亚娜5号运载火箭航班501 87
蓬勃发展的商业化航天技术 87
阿丽亚娜5号火箭的研发 88
阿丽亚娜5号运载火箭航班501 89
事故还原 89
结论 97
第9章 软件可用性的错误设计:“文森斯”号事件 101
战火从陆地蔓延到海面 103
关系日益紧张的美国和伊朗 106
失误和误判,命运的交响曲 108
射向伊朗航空655次航班的导弹 114
飞机被击落之后 114
第10章 计算机难以理解的人类的时间计算 115
闰年 115
微软的野心之作与闰年Bug 116
让全世界游戏玩家备受煎熬的PS3闰年Bug 118
医院系统故障,纸笔代替电脑 119
罢工的导航仪 120
日常生活中的Y2K Bug 121
第11章 游戏Bug 125
生活中的电脑游戏 125
各种游戏Bug 125
《星战前夜》 128
《魔兽世界》 129
第12章 核武禁果 133
飞向苏联上空的核导弹 134
佩特罗夫的判断 135
佩特罗夫判断之后 137
北美防空联合司令部:NORAD 137
凌晨3点钟的电话 138
第13章 医疗仪器软件杀人:Therac-25医疗事故 141
与日俱增的癌症患者与癌症治疗方法 141
放射治疗 142
Therac-25的研发 143
1985年6月,Therac-25的第一位受害者 145
1985年7月,Therac-25的第二位受害者 146
1985年12月亚基马谷纪念医院,Therac-25的第三位受害者 148
1986年3月东得克萨斯癌症治疗中心,Therac-25的第四位
受害者 149
1986年4月东得克萨斯癌症治疗中心,Therac-25的第五位
受害者 153
1987年1月亚基马谷纪念医院,Therac-25的第六位受害者 155
事故原因1:软件 156
事故原因2:用户界面 159
事故原因3:文档 160
事故原因4:AECL对软件的无知 160
软件错误带来的惨剧 161
第14章 因软件错误而消失的火星探测器 169
“火星全球勘测者”号 169
“火星全球勘测者”号突然终止任务 171
软件错误惹的祸 173
开启火星探测机器人时代的“索杰纳” 175
“勇气”号:真正的火星探测机器人 178
“勇气”号的第一次危机:出现软件错误 178
“勇气”号的第二次危机:轮子出现故障 180
最后的“勇气”号 180
第15章 玩弄世界于股掌之间的金融软件Bug 183
温哥华证券交易所事件 183
四舍五入惹的祸 184
澳大利亚昆士兰州银行卡终端机故障 185
导致公司破产的软件Bug 187
第16章 软件本可以阻止的飞行事故:
大韩航空801次航班和美国航空965次航班空难 191
关岛惨案:大韩航空801次航班 191
坠毁前的记录 192
本可以阻止的事故 195
假如软件发挥了应有的作用 196
美国航空965次航班 198
开始出错 201
“我们现在在哪?” 206
部分责任在于软件 208
第17章 153亿美元的彩票:数字预算会计系统 211
徘徊在地狱和天堂之间的政府 211
数字预算会计系统的开发 211
“较差”的项目 212
无视审计结果并强行运行系统 213
意料之中的漏洞 213
终于酿成大错 214
复合型人才的重要性凸显 214
第18章 丰田汽车“踏板门”事件与软件 217
“刹车失灵了” 218
丰田召回危机 219
丰田软件检测 223
ECU软件有可能导致汽车突然加速 224
Bug百出的丰田软件 226
Barr Group报告和丰田的低头认错并无直接关系 227
写给软件开发者的后记:为了开发无Bug软件 229
最早的Bug 229
软件的原罪:Bug 229
软件开发过程 231
软件Bug的成本 231
编码规范 232
静态代码分析 234
这本书带给我的,是一种全新的视角来审视技术的发展。我一直认为,科技进步是线性的,是不断朝着更美好、更高效的方向前进的。但这本书却以一种近乎残酷的方式,揭示了科技发展背后潜藏的巨大风险。作者没有回避那些令人不安的细节,而是将那些曾经发生的、足以让很多人损失惨重甚至付出生命的“Bug”赤裸裸地展现在读者面前。让我印象特别深刻的是,书中对一些大型项目在开发过程中遇到的种种阻碍和失误的描绘,那些看似微不足道的疏忽,最终却成为了吞噬整个项目的“毒药”。这让我不禁思考,我们是否过于自信地追求“更快、更强”,而忽略了“更稳、更安全”的重要性?这本书让我认识到,技术的光鲜亮丽之下,隐藏着无数需要被审视和警惕的隐患。它不仅仅是关于软件缺陷,更是一种关于“失败的哲学”,一种关于如何从错误中学习,如何建立更 robust(健壮)的系统和流程的深刻反思。它迫使我重新审视我对技术进步的理解,认识到每一次的突破都可能伴随着巨大的代价,而对这些代价的认识,恰恰是我们继续前进的动力和指南。
评分读完这本书,我感觉自己的思维方式被彻底颠覆了。过去,我一直认为软件开发是一个高度理性、逻辑严谨的过程,每一个环节都应该在控制之中。然而,这本书用一系列触目惊心的案例,狠狠地扇了我一巴掌。从航天飞机的失误到金融系统的崩溃,再到医疗设备的安全隐患,作者如同一个技艺精湛的解剖师,将那些隐藏在繁复代码中的“病灶”一一呈现。让我印象最深刻的是一个关于航空管制系统的章节,一个小小的优先级判断错误,差点酿成一场空中浩劫。作者在描述那一刻的紧张和绝望时,字里行间都充满了画面感,我仿佛能听到警报声此起彼伏,飞行员们在生死边缘挣扎。更让我惊叹的是,作者并没有停留在罗列失败案例,而是深入分析了这些“Bug”产生的根本原因:是流程上的漏洞?是沟通上的障碍?是团队文化的问题?还是人类自身认知的局限性?这种多维度的审视,让我看到了软件缺陷背后所折射出的复杂人性和社会因素。这本书迫使我去思考,技术本身是中立的,但它的应用却充满了不确定性,而所谓的“完美”往往是脆弱的假象。它让我认识到,对风险的敬畏,对细节的极致追求,以及跨学科的协作,才是避免灾难的关键。
评分这本书的封面设计非常有吸引力,那种深邃的蓝色背景,中间跳跃着一个红色的、不规则的符号,仿佛在诉说着一种危险和神秘。我拿到它的时候,第一感觉就是它绝对不是一本轻松的读物,而是一场关于技术深渊的探索。我本身不是一个纯粹的程序员,但我对科技发展带来的那些不为人知的隐患一直充满好奇。尤其是近年来,我们经常听到各种因软件错误导致的大规模系统瘫痪、数据泄露,甚至是影响到日常生活方方面面的灾难性事件,这些都让我深思。我一直想知道,那些看似微小的代码缺陷,是如何演变成足以颠覆整个体系的“致命Bug”的?这本书的名字恰好击中了我的痛点,它承诺要揭示那些不为人知的幕后故事,那些隐藏在完美用户界面下的脆弱逻辑。我期待它能像一部引人入胜的纪录片,用生动的故事和案例,深入浅出地讲解那些复杂的概念,让我们这些非专业人士也能理解其精髓。我希望作者能够带领我穿越代码的迷宫,去感受那些曾经发生过的惊心动魄的事件,去了解那些在危机时刻奋力挽救的技术人员的心路历程,以及从这些事件中我们能汲取到哪些宝贵的教训,以避免重蹈覆辙。这本书的价值,我预感将远不止于技术层面,它更像是一面镜子,映照出我们在追求技术进步的同时,需要付出的审慎和责任。
评分我一直对工程领域的“偶然性”和“必然性”之间的微妙关系很感兴趣,而这本书在这方面给予了我极大的启发。作者通过大量真实案例,巧妙地将那些看似偶然的软件缺陷,背后却有着深刻的必然逻辑展现在我们面前。比如,一个在某个特定条件下才会触发的“Bug”,其根源可能在于项目管理中的某个决策失误,或者是一个被忽视的行业标准。这本书让我明白了,很多灾难并非凭空而来,它们是无数个小小的失误、错误的判断、以及思维盲区累积的必然结果。作者在分析这些案例时,并没有简单地指责某个个人或团队,而是深入挖掘了导致这些问题的深层原因,包括技术架构的缺陷、沟通机制的失效、以及组织文化的影响。这让我看到了“致命Bug”的出现,往往是一个系统性问题的体现。这本书的价值在于,它不仅仅是揭露了失败,更是提供了一个宝贵的学习平台,让我们能够从别人的错误中汲取教训,从而构建出更具韧性、更可靠的系统。它让我明白,真正的工程智慧,在于预见风险,管理风险,并在不可避免的错误中找到学习和成长的机会。
评分我是一名软件测试工程师,每天的工作都围绕着“发现Bug”展开。我一直觉得,我的工作就是个“找茬”的活,把那些不符合预期的东西挑出来。但是,读了这本书之后,我才真正理解到,我这份工作的意义远不止于此。这本书让我看到了,一个微小的Bug,一旦出现在关键的节点,它能够引发多么可怕的连锁反应。我记得书里讲到一个关于自动驾驶汽车的案例,一个隐藏了多年的算法Bug,最终导致了严重的交通事故。作者在分析这个Bug时,不仅仅是描述了它的技术细节,更是描绘了受害者家属的悲痛,以及整个社会对自动驾驶技术的信任危机。这让我第一次如此深刻地体会到,我的工作不仅仅是为了让产品“可用”,更是为了守护用户的安全和信任。这本书让我更加坚定了我的职业信念,也让我开始反思,我是否能够做得更好?除了机械地执行测试用例,我是否能够更深入地思考潜在的风险,更主动地去提出改进建议?这本书为我打开了一扇新的大门,让我看到了一个更广阔、更具挑战性的职业前景,也让我认识到,作为一名测试人员,我肩负的责任有多么重大。
评分挺有意思的一本书~图灵社区推荐的书
评分还不错还可以
评分好
评分不错,书籍挺新的,还可以。
评分还不错还可以
评分不错
评分挺有意思的一本书~图灵社区推荐的书
评分很不错的读物
评分老公买的
本站所有内容均为互联网搜索引擎提供的公开搜索信息,本站不存储任何数据与内容,任何内容与数据均与本站无关,如有需要请联系相关搜索引擎包括但不限于百度,google,bing,sogou 等
© 2025 book.coffeedeals.club All Rights Reserved. 静流书站 版权所有