美文网首页当我写下一亿行代码读书
【0.1代码编写知识】之【软硬件的错误排查之道】

【0.1代码编写知识】之【软硬件的错误排查之道】

作者: 当我写下一亿行代码 | 来源:发表于2019-03-05 22:01 被阅读21次

以下摘录自《调试九法:软硬件的错误排查之道》

调试规则

  • 理解系统
  • 制造失败
  • 不要想,而要看
  • 分而治之
  • 一次只改一个地方
  • 保持审计跟踪
  • 检查插头
  • 获得全新观点
  • 如果你不修复bug,它将依然存在

理解系统

这是第一条规则,因为它是最重要的。

  • 阅读手册
  • 仔细阅读每个细节
  • 掌握基础知识
  • 了解工作流程
  • 了解工具
  • 查询细节

制造失败

虽然看起来很简单,但如果不制造失败的话,调试就会变得很困难。

  • 制造失败
  • 从头开始
  • 引发失败
  • 但不要模拟失败
  • 查找不受你控制的条件(正是它导致了间歇性失败)
  • 记录每件事情,并找到间歇性bug的特征
  • 不要过于相信统计数据
  • 要认识到“那”是可能会发生的
  • 永远不要丢掉一个调试工具

不要想,而要看

凭空想象,问题可能有几千条原因。而实际的原因只有去看了才能发现。

  • 观察失败
  • 查看细节
  • 植入插装工具
  • 添加外部插装工具
  • 不要害怕深入研究
  • 注意海森堡效应
  • 猜测只是为了确定搜索的重点

分而治之

当bug的藏身之地不断被缩小一半时,它将很难再隐藏下去。

  • 通过逐次逼近缩小搜索范围
  • 确定范围
  • 确定你位于bug的哪一侧
  • 使用易于查看的测试模式
  • 从有问题的一端开始搜索
  • 修复已知bug
  • 首先消除噪声干扰

一次只改一个地方

我们在生活中要有一点先见之明。如果你所做的更改没有起到预期的作用,那么就把它改回来。它们可能会产生无法预料的影响。

  • 隔离关键因素
  • 用双手抓住黄铜杆
  • 一次只改一个测试
  • 与正常情况进行比较
  • 确定自从上一次正常工作以来你改变了什么地方

保持审计跟踪

不要只是在心里记住“保持审计跟踪”这条规则,而要把它写下来。

  • 把你的操作、操作的顺序和结果全部记录下来
  • 要知道,任何细节都可能是重要的
  • 把事件关联到一起
  • 用于设计的审计跟踪在测试中也非常有用
  • 把事情记录下来!

检查插头

一些显而易见的假设往往是错误的。请恕我赘述,假设错误通常是最容易修复的错误。

  • 质疑你的假设
  • 从头开始
  • 对工具进行测试

获得全新观点

不管怎样,你都需要休息一下,喝杯咖啡。

  • 征求别人的意见
  • 获取专业知识
  • 听取别人的经验
  • 帮助无处不在
  • 放下面子
  • 报告症状,而不要讲你的理论
  • 你提出的问题不必十分肯定

如果你不修复bug,它将依然存在

现在你已经掌握了所有的技术,没有理由再让bug存在了。

  • 查证问题确实已被修复
  • 查证确实是你的修复措施解决了问题
  • 要知道,bug从来不会自己消失
  • 从根本上解决问题
  • 对过程进行修复

**从帮助台得到的观点是不明确的

只能通过远程方式了解问题,眼睛和耳朵接收到的信息并不十分准确,而且关键是时间紧迫。

  • 遵循规则。 无论用户多么糊涂,都必须找到应用规则的途径。
  • 对行动和结果加以确认。 用户会误解你的意思,同时会犯错误。通过确认他们所说和所做的一切可以及早发现这些问题。
  • 使用自动工具。 不要让用户参与系统生成的日志和远程监控与控制工具。
  • 即使是最简单的假设也需要确认。 是的,有些人就是不知道有电才能使用字处理器。
  • 使用可用的故障检修指南。 要处理的很可能就是已知的、好的设计。不要忽略历史。
  • 帮助完善故障检修指南。 如果找到了某个已知系统的一个新问题,将解决问题的所有内容进行归档可以帮助下一位支持人员。

相关文章

网友评论

    本文标题:【0.1代码编写知识】之【软硬件的错误排查之道】

    本文链接:https://www.haomeiwen.com/subject/weyauqtx.html