这篇文章是《调试九法：软硬件过错的排查之道》的浏览笔记。这本书的宗旨，是介绍怎么修复bug：找出bug产生的缘由、并给出修复方案。
调试bug的九个规则罗列如下，建议将这个清单打印出来，摆放在工作时候能看到之处。文章源自微观生活（93wg.com）微观生活-https://93wg.com/20518.html
调试规则文章源自微观生活（93wg.com）微观生活-https://93wg.com/20518.html
接下来一次看下每一个规则的核心理念，从名字上来看，每一个规则看起来都比较显明（PS：因为翻译的问题，有些词可能没那么容易理解），然而理解这些规则以及利用这些规则中间还是差了不少距离的。文章源自微观生活（93wg.com）微观生活-https://93wg.com/20518.html
规则1：理解系统文章源自微观生活（93wg.com）微观生活-https://93wg.com/20518.html
你必需掌握系统的工作原理和它是怎么设计的，在某些情况下还要知道为何这样设计。如果你没有理解系统中的某个部份，那么这一般为出问题之处。（这不单单是墨菲定律的问题，如果你不能理解你所设计的系统，你的工作可能会变得一团糟糕）。文章源自微观生活（93wg.com）微观生活-https://93wg.com/20518.html
怎么理解系统呢？文章源自微观生活（93wg.com）微观生活-https://93wg.com/20518.html
浏览手册文章源自微观生活（93wg.com）微观生活-https://93wg.com/20518.html
逐字逐句浏览手册，细心理解每一个细节文章源自微观生活（93wg.com）微观生活-https://93wg.com/20518.html
知道什么是正常的，知道什么是正常的可以帮助你注意到什么是不正常的文章源自微观生活（93wg.com）微观生活-https://93wg.com/20518.html
知道工作流程，要理解业务，要讲系统的工作进程对应到具体要解决的现实问题文章源自微观生活（93wg.com）微观生活-https://93wg.com/20518.html
选择适合的工具，选择适合的辅助（监控、插桩）工具可以帮你理解系统
查阅细节，经验有时候会骗人，记忆有时候会犯错
规则2：制造失败
这一点比较容易理解，就是问题复现，在日常工作中，你在排查一个问题的进程中，最重要的一步就是复现问题——能复现的问题都能解决。
这里有几个要点需要注意：
引起失败，而不要摹拟失败，不要尝试用不同的方式去摹拟问题，而要摹拟以及构建引起bug产生的前提
debug的动作，不要影响过错的产生方式，可以影响过错的产生频率
从头开始，需要有一个正常的状况到不正常的状况的进程，从开始正常的状况开始察看，直到问题产生；
终极方案，节制变量法，将可能引起过错的因素顺次排除了；排除了所有可能的缘由后，剩下那个谜底，不管多么不可思议，都是事实。
规则3：不要想，而要看
亲眼看到底层的失败是无比重要的，如果你猜测失败是怎么产生的，那往往会修复一些根本不是bug的问题。
在软件世界里，察看象征着设置断点、添加调试语句、监视程序值和检查内存；在医学领域，需要测试血样以及进行X光透视。
对细节的察看应当到什么程度适合呢？简单的谜底是：一直察看，直到把问题的缘由锁定在几种可能以内。
在系统设计的时候，就要斟酌到将来调试、排查问题的情况，将日志视为系统设计的一部份—打印一些关键日志，或者设计一些打开日志的开关，以便在生产环境针对某个case进行调试。
日常生活中有不少插桩的case：
体温计丈量体温
自行车轮胎漏气时，都是将轮胎打满气，然后放在水里检查哪里漏气
天然气中加入了臭鸡蛋的气息
规则4：分而治之
反复将问题分成好的一半以及坏的一半，然后缩小搜寻规模，然落后一步钻研有问题的那一半链路。
规则5：一次只改一个处所
初中就学过的节制变量法。在修改bug时候，如果某个改动没有修复bug，就应当当即把它改回来。
规则6： 维持审计跟踪
记下你的每一步操作、顺序以及结果；魔鬼藏在细节中；将一些事情关联起来思考；好记性不如烂笔头；
规则7：检查插头
一些不言而喻的假定多是过错的；是否运行了正确的代码？是否打了正确的包？插头是否掉了？从一些最基本的问题开始确认，不少时候问题就出在这里。对自己使用的工具进行测试，由于工具也是一种软件，难保不会出问题。
规则8：取得全新观点
“要想从新理清一个案子的头绪，最佳的办法就是把它讲给他人听。” ——福尔摩斯，《银色马》
向他人解释问题的进程，会让你对问题进行从新的梳理以及理解，这时候候可能发现以前没有发现的问题。
bug产生了，以除了掉bug为骄傲，而不是非得以自己除了掉bug才骄傲。
无论你是跟什么人求助，或者需要他人什么样的帮助（征求意见、获取专业知识、听取经验），在向他人描写问题的时候，一定要记住一件事——讲演症状、而不是讲你的理论；此外，有些症状你可能不是十分肯定，也能够描写出来。
规则9：如果你不修复bug，它将仍然存在
“当危险已经离你很近时，谢绝承认它其实不是英勇的表现，而是笨拙。” ——福尔摩斯，《最后一案》
如果你不修复bug，它不会自动消失。依照前面的规则解决问题后，要进行一次回归验证，确保已经修复问题，并且没有引入新的问题。
我的感想
这本书里的不少案例都是是硬件相关的，对于软件开发工程师来讲不太熟识，无非在浏览的进程中，建议可以想一想自己在工作中排查问题的场景，是否依照一定的章法去排查的？有无从最基本的假定开始确认？有无查阅文档？有无关注本次变更的内容？有无依照二分法进行排除了？
作为软件开发工程师，在实际工作中很少有机会从0开始构建一个系统，更常见的情况是接手保护一个已经运行了几年、阅历了几代的系统。写代码只是工作中的一部份，还有不少其他的事情需要做：修复bug、需求评审、系分评审、项目排期等等。
修复bug（解决问题）的能力，是软件工程师的核心竞争力之一。在最开始的工作中，有时候会羡慕老司机的“直觉”——看到一个过错日志，就大概知道是哪里有问题，后来自己查问题查得多了以后，自己也get到了这类“直觉”，也理解了——这不是直觉，这是已经被实践验证过不少次的经验，即便这样，我也会告诫自己——不能完整依赖这类经验，经验有助于缩小待验证的规模，还是需要事实（重现问题）去证实前面的猜测。
以上就是微观生活（93wg.com）关于“笔记｜软件调试的技巧”的详细内容，希望对大家有所帮助！
评论