<读书笔记>软件调试之道 :问题的核心-修复后的反思

声明:本文档的内容主要来源于书籍《软件调试修炼之道》作者Paul Butcher,属于读书笔记。欢迎转载!

--------------------------------------------------------------------------------------------------

有时尽管修复设计的是一个孤立的代码区,但你还是需要大局观,在修复缺陷之后花时间反思一下!

一旦确定了错误的来源,就可以采取措施避免它再发生!有些情况下,只不过是告诉你未来在在这一方面要更加小心!

在事后要反思并总结,尤其你发现了错误的模式只发生在特定的点或者特定的原因下时。极少数情况下,需要对自己敲响警钟!

1、问五个为什么,总体来说大部分情况下都能对你有帮助,比如:

  • 软件崩溃了,出错了,为什么?
  • 该代码不处理数据传输过程中的网络故障,为什么?
  • 没有专门检测网络故障的单元测试,为什么?
  • 最初的测试人员并没有意识到并创建一个这样的测试,为什么?
  • 我们的单元测试没有考虑到软件故障,为什么?

可能很快就会得到,我们在原先的设计中没有考虑到软件故障这个问题症结,也可能有很多步骤。

2、根本原因分析

  • 需求 需求是否完整、清晰并且未被误解?。
  • 设计 在架构或者设计中是否存在疏漏,是我们没有考虑到还是没有正确的按照设计来做。
  • 测试 对代码的测试是否达到了足够的覆盖率?或者测试本身就有问题呢?
  • 构造 是开发人员写代码是犯了一个很简单的错误,或是误解了某些基础技术?

3、和同事交流问题注意事项

让同事知道他犯错了这件事情可能比较危险,一方面这个有价值的信息需要让同事知道以免其重蹈覆辙,另一方面,由于程序员不善交际沟通,可能由于口无遮拦把事情搞砸,所以你的善意可能得不到友好的回应,但是是需要做一些有益的事情。

  • 首先最重要的,要有正确的出发点,不要只是为了得到自己的优越感。
  • 在交流前,要三思并换位思考,如果自己犯错了该怎么办?
  • 要清楚知道其性格特点!
  • 避免妄作评判,不要说“你应该怎样”,而可以说“我们可以怎样”
  • 要有建设性 要记住你也可能说错了!

4、关闭循环

如果你着手的项目有一套自己的规范:比如编码规范、测试规范、文档规范、报告/跟踪过程、设计指南、性能需求。当修复缺陷时,你是否需要更新最终用户文档作为修复记录?或为下一个版本更改日志?或者把它交给QA部门?该工作是否需要对特定客户或者项目进行跟踪(涉及到返修甚至召回)?

时间: 2024-11-05 06:21:52

<读书笔记>软件调试之道 :问题的核心-修复后的反思的相关文章

&lt;读书笔记&gt;软件调试之道 :从大局看调试-理想的调试环境

声明:本文档的内容主要来源于书籍<软件调试修炼之道>作者Paul Butcher,属于读书笔记.欢迎转载! ----------------------------------------------------------------------------------------------------- 自动化测试 1.有效的自动化测试 明确说明测试结果是否通过 不需要安装.测试后也能够撤销对环境所做的任何修改 单击运行所有的测试 全面覆盖,做到足够解决完全覆盖是可能的 2. 自动化测试

&lt;读书笔记&gt;软件调试之道 :从大局看调试-零容忍策略

声明:本文档的内容主要来源于书籍<软件调试修炼之道>作者Paul Butcher,属于读书笔记.欢迎转载! -------------------------------------------------------------------------------------------- 缺陷优先 如何使缺陷修复与软件开发相结合? 如何估计缺陷修复花费的时间? 如何确保项目不会陷入<人月神话>中所描述的无数缺陷修复的焦油坑中呢? 缺陷优先 要采用早起缺陷修复原则,并且基于以下两

&lt;读书笔记&gt;软件调试之道 :问题的核心-如何修复缺陷

声明:本文档的内容主要来源于书籍<软件调试修炼之道>作者Paul Butcher,属于读书笔记.欢迎转载! 修复缺陷 对于一个好的修复来说,不仅仅是让软件运行正确,还需要为将来奠定基础.一些列零散的未经仔细考虑的修改,都将是原本的简洁设计逐步消失. 好的修复必须同时实现以下目标: 修复问题 避免引入回归 维持或者提高代码的整体质量 -----------需要参考的规则如下---------- 1.清除障碍 确保一切从头开始,当你不舍得抛弃诊断阶段所做的修改时,利用源码控制系统. 需要对所做的修

&lt;读书笔记&gt;软件调试之道 :问题的核心-诊断

声明:本文档的内容主要来源于书籍<软件调试修炼之道>作者Paul Butcher,属于读书笔记. 不要急于动手! 尽管可以利用各种工具和技术以及软件自身查找缺陷,但是你最重要的财富是你的智慧 一种调试方法 提出假设->设计实验->假设不成立,重新开始 采用不同类型的实验 进行几种不同类型的实验,但是每种实验必须有一个明确的目标.比如软件内部运行状态.软件的输入参数.本身编码逻辑. 实验必须起到验证的作用 实验是一种达到目的手段,而不是目的的本身.可以通过实验用来证明或者推翻假设.

&lt;读书笔记&gt;软件调试之道 :问题的核心-重现问题

声明:本文档的内容主要来源于书籍<软件调试修炼之道>作者Paul Butcher,属于读书笔记. 重现第一,提问第二 问题重现是实证过程的最强大武器,如果不能重现问题,你也无法证明修复了它 首先按照缺陷报告的描述的步骤来做, 抓住重点,包含三个控制因素 软件本身:确保你使用的软件版本和bug提交的版本一致,使用相同的编译工具和相同的编译参数. 软件运行环境:如果要与外界环境交互,则确保使用相同外部系统.比如测距仪,需要在同样的光照环境.温度和供电方式. 提供的输入:如果软件代码的运行和配置参数

&lt;读书笔记&gt;软件调试之道 :从大局看调试-发现代码存在问题

声明:本文档的内容主要来源于书籍<软件调试修炼之道>作者Paul Butcher,属于读书笔记.欢迎转载! ----------------------------------------------------------------------------------------------- 缺陷可以随时发生,从代码编写完毕到代码发布后的成年累月! 无论你开发什么样的软件,都需要创建一些流程,通过这些流程,可以告诉你软件哪里出了问题,并且应该如何修复! 1.缺陷管理系统 既有简单用途的,

&lt;读书笔记&gt;软件调试之道 :实证方法

有效调试不仅仅是排除缺陷,其包含如下几个步骤 弄明白软件为何运行错误 修复这个问题 避免破坏其它部分 保持或者提高代码的总体质量 确保同样的问题不在其它地方发生,也不会再次发生 构建实验.观察结果 依赖观察和经验,而不是理论和纯逻辑推理 阅读源码,推理软件的运行状况,通常效率低下而危险 要仔细的构建实验环境并观察软件的运行状况 需要澄清的几个问题 你知道发生了什么吗? 要明确知道到底发生了什么,什么情况下发生的. 不要完全依赖缺陷报告,缺陷报告本身的错误也不会少 如果没有缺陷报告,应该在了解整个

&lt;读书笔记&gt; 代码整洁之道

概述 1.本文档的内容主要来源于书籍<代码整洁之道>作者Robert C.Martin,属于读书笔记. 2.软件质量,不仅依赖于架构和项目管理,而且与代码质量紧密相关,本书提出一种,代码质量与整洁成正比的观点,并给出了一系列行之有效的整洁代码操作实践,只要遵循这些规则,就可以编写出整洁的代码,从而提升代码质量. 3.该书介绍的规则均来自于作者多年的实践经验,涵盖从命名到重构的多个编程方面,具有很好的学习和借鉴价值. 4.习艺要有二:知和行.你应当学习有关规则.模式和实践的知识,穷尽应知之事,并

LDD读书笔记_调试技术

先写一个个人比较喜欢的调试技巧. 1. menuconfig中打开CONFIG_DEBUG_KERNEL 2. objdump -d -S(大写) *.o > file 可以得到混合C和汇编的代码 或者 make *.lst 也能得到 3. addr2line -f -e vmlinux address(0xcxxxxxxxx) 能得到address对应的函数名和所在的文件中的行数 4. 根据OOPS信息, 查看R13(SP), R14(LR), R15(PC)寄存器的值, ARM架构 ?pri