Effective Debugging：软件和系统调试的66个有效方法
迪欧米迪斯·斯宾奈里斯
2173人在读
15.4万字总字数
¥25定价
迪欧米迪斯·斯宾奈里斯
本书所要讲解的调试知识，包括与调试有关的策略、工具及方法。我们当前在开发并运作一款复杂的计算系统时，可能会遇到各种问题，而这些调试知识，则使大家能够应对这些问题。过去我们所说的调试，主要是指检测并修复程序错误，而当前却很少有哪个程序会孤立地运作，即便是一个很小的程序，也会与外部的程序库相链接（通常是动态链接）。更为复杂的程序会运行在应用程序服务器中，会调用Web服务，会使用关系型数据库及NoSQL数据库，会从目录服务器上获取数据，会运行外部的程序，会利用其他的中间件，也会纳入很多第三方的软件包。于是，要想令整个系统及服务正常地运作，就必须确保其中的组件不会发生故障，这些组件可能是由公司内部人员所开发的，也可能是由第三方所提供的，它们所在的主机或许分布在全球各地。为了应对这种局面，软件开发行业开始重视DevOps规程，这套规程旨在同时强调开发者和其他IT专业人员所应担负的职责。与之类似，本书想使读者在面对故障时也能够具备这样一种全面的观念，因为在面对一些极为困难的问题时，我们通常无法立刻判断出该问题到底是由哪一个软件组件所引发的。
要相信自己可以定位并解决bug，可能是这篇文章最重要的内容了。 Agent时代，调试一个问题的速度，几乎完全取决于你的表达能力，调试技术本身不那么重要。 张银奎老师的软件调试的著作，本来一直拖着没读，没想到现在已经越来越不需要了，果然学的够慢，就不用学了么。😅
作者做了充分地系统思考和总结，端到端地介绍了有关调试方方面面的知识。 也许有一天，大家都能写出好代码，软件世界没有bug，调试成为上古神器。
2024.No84： 24年第39本技术书。适合有几年工作经验，值得反复阅读的技术书籍，能学习到很多调试技巧。Java开发可能是最简单，IDEA调试能力异常强大。能了解到很多其他语言里的概念和工具。Shell、DTrace、Git、乃至Wireshark等工具还要持续深入学习并实践。
作者系统地列举了下排查bug的思路，以及一些常用的工具，值得一读。
作者分享了很多程序员研发技巧，值得一读。
依旧还是看每本书，都能想到程博。书里介绍的大部分方法程博都教过，或者从负面吐槽过我(比如问我为什么能忍受每次重现要做那么多事，明明通过脚本或者配置就可以省去很多时间之类的)。也有一些之前没有接触过的方法，或者不是第一反应会用到的。 对于书里介绍部分的工具，之前工作中也使用过一些，不过还是少数。还有些像gdbinit strace perf在绿导师的操作系统课里也都有提到，希望后面有时间可以再详细研究一下提到的工具。 总体来说，我觉得还是值得推荐的，毕竟我觉得是值得我多读几遍的。
积累书中提到的对工作有影响的可实践小方法： 1.把你的代码讲给“小黄鸭”听：当你写代码的时候和当你尝试把代码逻辑解读给小黄鸭听的时候，大脑的思考区域是不同的，很多时候问题在转念一想的过程中就会暴露； 2.多利用现有的工具：代码静态扫描工具、即时编译小插件、apache的多线程图形化界面工具都能帮助程序员可视化代码的调用逻辑和过程； 3.在调试的时候尽可能视觉区域扩大点：自己以前的习惯就不是很好，视觉区域较小会导致思考断断续续，不够连贯丝滑，尽可能把代码逻辑、数据库交互、第三方调用这些过程都能在两个屏幕上完全呈现； 4.利用好codeReview：把代码审核当成是一种工作的习惯，而不是在心理上觉得是一种“对人的针对”，能够尽早发现问题，问题被解决的成本就越低； 5.关注diff对比：diff调用过程中差异点，如果是代码变化了就diff代码，如果代码没变化就diff入参、diff数据库交互、diff第三方交互； 6.用二分查找定位问题：如果在一坨代码中找一个bug，就用二分查找，不断缩小问题的范围，借助断言、条件判断、注销逻辑等能提高二分查找揪bug的速度。
虽然这本书豆瓣评分只有6.5分，但是其实这本书真心输在名字取的不好，这本书应该改名叫Debugging Crash Course，同样的内容，评分肯定能高不少。这本书在尝试着把所有和调试相关的思路都梳理一边，所以有大量的对很多人来说可能都已经变成常识的内容，而且所有的内容都是点到即止，比如工具就是说几个名字，然后挑一个举一个最简单的例子，这些东西对调试老手而言几乎没有用处，但是对于新手而言简直就是一本调试指南！我觉得四颗星还是对得起的。
作者经验丰富，列举了不少调试的方法和干货，学到了一些以前不知道的工具。
推荐所有工程师阅读！这不是一本单单教你如何调试代码的书，而是讨论了整个软件项目周期中如何保障和提升工程质量的最佳实践！