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

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

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

缺陷可以随时发生,从代码编写完毕到代码发布后的成年累月!

无论你开发什么样的软件,都需要创建一些流程,通过这些流程,可以告诉你软件哪里出了问题,并且应该如何修复!

1、缺陷管理系统

既有简单用途的,也有全面流程管理的,但其目的都一样。

  • 确保不会遗漏缺陷。
  • 通过提供一个缺陷报告的标准格式,把所有相关信息都包含其中!
  • 作为审查线索,可以确保我们知道每一个版本还有哪些缺陷未解决。
  • 也可以作为软件发布的重要信息来源 可以设定缺陷优先级,并确定先解决哪个。
  • 为相关利益方提供一个有效的沟通方式,确保在团队之间传递时准确提供了相关信息
  • 作为一个管理工具,提供了该项目的当前状态

2、如何写出一份出色的缺陷报告

一份好的缺陷报告宁多勿少,因为我们无法知道哪些信息是相关的,哪些是无关的。

  • 报告应该是具体的、明确的和详细的。
  • 报告也应该是最小化的、唯一的。比如报告1万字,其是否可以消减?哪一个版本出现缺陷,其它版本有没有?

3、简化流程-通过消减不利条件来提高缺陷报告质量

如果没有人花时间和精力向你反映问题,你就不能找出这些缺陷,也不会修复它!

  • 明确说明如何报告缺陷。 提高多种选择: 比如电子邮件、直接交谈、在线沟通等!
  • 要尽量简单 :要求用户执行的动作要尽量少,否则其可能不会完成
  • 模板不要太死板 :确保每个区域设置合理选项,比如“以上都不是”。 尊重用于隐私:用户的数据属于他们,而不是属于你,要遵守相关隐私策略。

4、有效沟通

聪明是一个软件工程师的必要条件,大多数在学校都有良好的成绩,但这并不能保证我们不会犯错。在应用领域客户依靠他们的专长,可能理解的比你好,因此当存在明显误解的时候,要记住你可能出错了!

  • 从用户的角度设想一下会发生什么,你的目标是把他们的观察结果和他们的解读分开。
  • 和非技术人员沟通,唯一办法是要有耐心,解释一下为何这些细节很重要,并通过必要的步骤说服他们收集相关数据。
  • 发布你的缺陷数据库,虽然让大家看到你的“爆料”可能很可怕,但其好处巨大。
  • 提高反馈,收到缺陷报告时,需积极回应并支持他们继续下去。
  • 拜访用户,拜访用于可以比任何缺陷报告了解的更多 。

5、与支持人员协作

技术支持,QA,客户工程师,技术客户经理等都可以在调试过程中提高帮助!

  • 可以考虑和QA团队的一名同事在诊断阶段一起工作
  • 为了确保客户团队能帮助我们解决沟通问题,你应该能够判断并确保所有相关信息已被确认,避免吹毛求疵以及一些相关细节,可以考虑要求他们执行一项特定进程,来提高缺陷报告质量
  • 偶尔也做做客户支持,以表示对客户的尊重,避免被用户封杀
  • 由于QA的所具有的不同视角,他们需要守护的是避免与开发团队先入为主的“同流合污”,但也容易过火!比如作者所工作的一个公司开发和QA团队之间存在很深的隔阂,QA能得到的信息就是一个已编译的二进制文件,开发团队唯一能得到信息就是“通过”或者“失败”。
上一篇:Error:"MetaStoreClient lost connection. Attempting to reconnect (1 of 24) after 5s. getCurrentNotificationEventId" occurs as HiveServer2 fails to start as it cannot connect to Metastore in HDP 3.0


下一篇:<读书笔记>软件调试之道 :问题的核心-重现问题