<读书笔记>软件调试之道 :问题的核心-如何修复缺陷

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

修复缺陷

对于一个好的修复来说,不仅仅是让软件运行正确,还需要为将来奠定基础。一些列零散的未经仔细考虑的修改,都将是原本的简洁设计逐步消失。

好的修复必须同时实现以下目标:

  • 修复问题
  • 避免引入回归
  • 维持或者提高代码的整体质量

-----------需要参考的规则如下----------

1、清除障碍

  • 确保一切从头开始,当你不舍得抛弃诊断阶段所做的修改时,利用源码控制系统。
  • 需要对所做的修改进行快速审核,不要跳过这一步!
  • 随时做记录,或者保留相关文件的副本。

2、测试

  • 如果开发过程包括测试优先(测试驱动)开发,因此你拥有一个自动化测试框架和大量的单元测试工具,修改源码时,这种方法在避免引入回归方面能够收到良好的效果。
  • 运行现有的测试程序,并证明它们能够通过
  • 添加一个或者多个新的测试程序,后者修复现有的测试程序
  • 修复缺陷证明你的修复起了作用(以前的失败不再出现)
  • 证明没有引入任何回归(以前通过的测试现在都没有失败)

3、修复问题产生的原因而非修复现象

实际工作中,非常时期,一边是客户愤怒的大声叫嚷,一边是项目经理不耐烦的脸色,你可能就迫于压力只是让缺陷消失,然后进行下一个任务;或者是因为你分析的远远不够,也会导致仅仅修复现象,而非原因。无论这么做多么不好,起码你了解根本原因,并且采取了一个“明智”的办法迅速解决了问题。但是这个办法只是修复缺陷的三个目标之一,后两者更加重要。此时要发挥学术真诚的精神,如果不能确信自己真正理解了问题的症结,就不要相信你的修复!

4、重构

最近几年,随着敏捷开发方法的日益普及,最显著的两项技术的广泛应用就是自动化测试和重构技术。 重构是改善既有代码设计而不改变其行为的过程,具体参考《重构:改善既有代码的设计》。

修复缺陷往往不涉及重构,但是如果缺乏经验的话,为修改缺陷而做出的必要修改时会产生重复,这是不该有的,这就是《程序员修炼之道》一书中描述的“不要重复你自己”的原则。

在修复缺陷之后重构比先重构再修复更合理,当然,如果修复工作很复杂,可能要反复经历修复和重构的过程!

切记:重构的同时不可改动代码功能,同样也不能修复缺陷!

5、签入

要合理利用源码控制系统,如果将很多错误集合起来一起签入,就会大大降低其作用

请坚持这项原则:一次逻辑修改只做一次签入

6、代码审查

代码审查没有固定执行时间,有时让同事参与修复的初期阶段,有时只是让其签字确认!该方法是开发过程固有的一部分,而不必看成一个很正式的调试方法!

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


下一篇: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