最难解决的错误代码_为什么有些错误比其他错误难解决?

最难解决的错误代码

有很多不同的因素会影响发现和修复错误所需的时间。 其中一些我们已经过去了 。 错误报告的质量如何–您能理解吗,它是否包含重现该问题的步骤。 该报告的发布时间-自那时以来可能发生了多少变化,人们会记住您是否需要询问他们详细信息。 设置测试环境以重现该错误需要进行多少工作。是否可以重现该错误。

还有其他因素。 那种错误。 代码库的大小,它有多旧,有多丑陋以及有多脆弱-如果您尝试更改它,它会破裂。 您有多少语言经验,以及对代码的理解程度,是否编写过代码或至少在以前工作过。 您的工具在调试,分析和导航代码以及重构方面的性能如何。 您已经进行了哪些测试来捕获回归。 以及您在解决问题,缩小问题范围,然后提出安全,整洁的解决方案方面的能力如何—尤其是在您没有编写也不理解的代码中。

缺口和盲点

马克·艾森斯塔特(Marc Eisenstadt)在“我的毛虫战争故事”中发现,造成臭虫修复成本最重要的因素是:

  • 因果差距。 将故障与代码中的实际缺陷相去多远? 有时,代码恰恰在问题所在的地方失败。 在其他时候,您可以看到有些问题,但是无法追溯到发生问题的地方。
  • 复制该错误有多困难或多昂贵。 它是否涉及其他系统? 设置测试系统涉及多少工作? 该错误是否仅在重负载下长时间运行系统或具有大量并发会话后才会显示? 问题是断断续续的吗? 它是特定于配置的吗?如果是,您是否可以访问该配置? 您是否熟悉这些工具,并且您的调试或跟踪工具会告诉您任何有用的信息吗? 启用调试器后,问题是否消失了( Heisenbug问题)?
  • 错误的假设。 哪里出了问题以及您认为有什么问题是非常不同的,或者您对平台或语言的了解不多,无法理解哪里出了问题或在哪里看,所以您从错误开始。 您有一个盲点,除非您得到其他人的帮助才能看到它,否则您将无法解决此问题。 知识和固执都是这里的重要因素。 您必须有足够的知识才能知道从哪里开始寻找东西,并且必须足够顽固不放弃。 但是顽固地坚持一个假设太长时间,即使-特别是-如果它是一个好的假设,也会使您无法继续前进并发现错误。

有些错误比其他错误更容易修复

与往常一样,Capers Jones关于修复错误的成本有很多话要说-参见“ 2011年软件质量状况”

修复错误所需的时间取决于错误的类型。 修复安全漏洞的平均时间:10小时。 设计错误:8.5小时。 数据错误:6.5错误。 编码错误:仅3小时。 无效的错误:4.75小时–找出一个错误实际上不是错误,平均需要4.75个小时,而修复一个编码错误则只需3个小时! 缠住你的头。 重复:1小时(以找出此错误已被报告,因此您也可以忽略它)。

但是我们前面还谈到了很多问题:修复这些错误的最大时间可以是平均时间的10倍以上。 无法复制的错误是最难的-如果可以完全修复,这些类型的错误平均最多需要40个小时才能修复。

严重程度费用

该漏洞的严重程度也会影响查找和修复所需的时间。 平均而言,严重Severity 1的错误(系统故障或最大客户(或CEO)对您大吼大叫,因为某些错误或数据库已被攻击者破坏)平均在6小时内得到修复。 9小时内出现严重错误(严重性2)。 如果您根本不愿意解决这些问题,则次要(严重性3)错误需要3个小时,而琐碎的错误(严重性4)只需1小时。

有趣的是,最严重的错误(严重性1)比其他主要的错误花费的时间更少–可能是因为,当系统停机时,您的最佳人员会立即注意控制损坏。 但是快速修复这样的错误并不意味着它很便宜。 严重性1紧急情况还有其他间接成本,包括事件管理和升级的运营支持成本,以及根本原因分析以找出问题出在哪里,以及需要采取的任何后续行动以确保这样的问题不会再发生。 关键错误永远都不便宜,至少如果您正确地修复它们也不会便宜。

这取决于您何时发现错误

所有这些数据均假定您正在修复生产中发现的错误。 每个人都知道,在开发周期中发现漏洞的时间越早,修复的成本就越便宜–如果自动测试或静态分析检查报告您刚刚更改的代码中存在错误,那么您当然可以立即对其进行修复。 著名的规则“在交付后发现和修复软件问题通常比在开发早期发现并修复它要贵100倍”。 还是呢?

“我们对打击缺陷的了解”中 ,不同的研究表明,以100:1的经验法则适用于严重和严重缺陷(因为涉及直接和间接成本)。 但是对于非严重的错误,工作量乘数要低得多:仅为2:1。 对于在持续部署模型中工作的团队而言,情况尤其如此,开发,测试和生产之间的界限变得模糊,并且将修补程序投入生产所需的成本和时间也最小。

代码库的年龄和大小

修复漏洞的成本还取决于系统的年代以及漏洞的年代。 在运行的最初几个月中,通常会由编写代码的同一位程序员Swift发现并通常Swift修复错误。 随着时间的流逝,发现和修复错误变得越来越困难,部分原因是已经报告并解决了不费吹灰之力,更常见,更明显和更容易重现的问题,现在您将获得更多的信息。困难的情况或计时问题。 部分原因是,随着时间的流逝,修改代码的程序员与编写代码的程序员的可能性较小,因此,对于不得不解决问题的人来说,花更多的时间就可以进入游戏。

这取决于系统的大小。 较大的系统具有更多的错误,并且修复大型系统(尤其是真正的大型系统)中的错误的成本更高。 严重性为2的错误(平均而言,最难修复)在最多1000个功能点(大约或少于50,000行Java代码)的系统中平均需要9个小时或更短的时间才能解决。 但是在更大的系统(500,000+行代码或更多行)中,平均时间长达12小时。 在最大的系统中(另一个更大的数量级),修复相同类型的错误平均需要24小时。 接下来,我想看看程序员在修复错误方面的价值。

参考: 为什么有些错误比其他错误更难解决? 来自我们的JCG合作伙伴 Jim Bird在Building Real Software博客中获得。


翻译自: https://www.javacodegeeks.com/2012/07/why-are-some-bugs-harder-to-fix-than.html

最难解决的错误代码

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值