一位编程老手13年来处理棘手bug的18个心得

分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友 微信微信
查看查看133 回复回复2 收藏收藏 分享淘帖 转播转播 分享分享 微信
查看: 133|回复: 2
收起左侧

一位编程老手13年来处理棘手bug的18个心得

[复制链接]
不是我教你诈 发表于 2016-7-26 00:34:03 | 显示全部楼层 |阅读模式
快来登录
获取优质的苹果资讯内容
收藏热门的iOS等技术干货
拷贝下载Swift Demo源代码
订阅梳理好了的知识点专辑

作者简介:Henrik Warne是瑞典斯德哥尔摩的一名软件开发员。从事编程行业已有20多个年头,现在仍热爱编程。目前,他是TriOptima公司的开发员,负责为财务风险管理系统开发软件。之前,他在Symsoft从事移动通讯系统的开发。更早些,在爱立信为移动交换系统开发软件,并在一家小型初创公司待过,为VoIP开发嵌入式系统。主要从事开发员的工作,不过也做过几年的系统测试员和支持工程师。

一位编程老手13年来处理棘手bug的18个心得

一位编程老手13年来处理棘手bug的18个心得 - 敏捷大拇指 - 一位编程老手13年来处理棘手bug的18个心得


我在《从你的bug总结经验教训》一文中写道,我一直在如何跟踪遇到的最有意思的bug。我最近回顾了全部194个bug(时间跨度达13年),看看从中学到了什么经验教训。下面是最重要的几个经验教训,分为编码、测试和调试这三大类:




一、编码

这些是在过去給我带来棘手bug的所有问题:

1. 事件顺序:处理事件时,很有必要提出下列问题:事件是否可以以一种不同的顺序到达?如果我们从来没有收到该事件,会怎样?如果该事件连续出现两次,又会怎样?即使通常情况下这永远不会出现,但系统(或交互系统)的其他部分中的bug可能会导致这出现。

2. 处理太早:这是上述“事件顺序”的一种特殊情况,不过它已引起了一些棘手的bug,所以它自成一类。比如说,如果信令消息接收太早,在配置和启动过程完成之前接收,许多奇怪的行为就会出现。另一个例子:当某个网络连接还没有被列入空闲列表就被标为断开。调试这个问题时,我们总是假设它在处于空闲列表时被设为断开(但为什么它又没有从列表上撤下?)。没考虑到有时动作发生太早要怪我们没想到。

3. 隐蔽故障:一些跟踪起来最棘手的bug(一方面)是由出现隐蔽故障、继续执行而不是給出错误的代码引起的。比如说,系统调用(比如绑定)返回未加检查的错误代码。另一个例子:遇到错误元素后,直接返回而不是给出错误的解析代码。调用在故障状态下继续持续一段时间,这大大加大了调试的难度。最好一旦检测到故障情况,就返回错误。

4. if语句:有几个条件的if语句給我带来了许多bug。即使if语句概念上很简单,有多个条件需要跟踪时,它们也很容易搞错。如今我试着重写代码,力求更简单,避免要处理复杂的if语句。

5. Else:有几个bug是没有适当考虑如果条件为假会发生什么而引起的。几乎无一例外的是,每个if语句应该有一个else部分。此外,如果你在if语句的一个分支中设置了某个变量,可能应该在另一个分支也要设置该变量。与此相关的是标志(flag)被设定的情况。仅仅添加设定标志的条件很容易,但是容易忘了添加应该重新设定标志的条件。任由永久性设定的标志留在那里可能会在将来导致bug。

6. 不断变化的假设:一开始最难预防的许多bug是由不断变化的假设引起的。比如说,一开始,可能每天只有一个客户事件。然后,按照这种假设编写了许多代码。后来某个时候,设计发生了变化,允许每天有多个客户事件。出现这种情况后,就很难改变受到新设计影响的所有情况。很容易找到显式依赖该变化的所有项,但是难就难在,找到隐式依赖旧设计的所有情况。比如说,可能有代码读取某一天的所有客户事件。隐式的假设可能是,结果集从不大于客户数量。我没有好的办法可以预防这类问题,欢迎读者建议。

7. 日志:深入了解程序执行的任务至关重要,尤其是逻辑很复杂时。务必要添加足够多(但是别太多)的日志,那样你就能弄清楚为什么程序在执行它执行的任务。如果一切正常,日志并不重要,但是一旦出现了问题(这不可避免),你会很高兴添加了适当的日志记录。、




二、测试

作为一名开发者,除非进行了测试,否则我不会说搞完了一项功能。至少,这意味着每一行新代码或更改后的代码至少执行了一次。此外,单元测试或功能测试也很好,但还不够。新功能还必须在类似生产环境的环境下加以测试和探究。唯有如此,我才可以说搞完了一项功能。下面是bug在测试方面给予我的一些重要的经验教训:

8. 零和空:务必要以零和空(合适的情况下)来进行测试。对于字符串而言,这意味着既指长度为零的字符串,又指内容为空的字符串。另一个例子:在发送任何数据(零字节)之前,测试TCP连接的断开。没有使用这些组合来测试是bug悄然出现的头号原因,我在测试时是原本可以发现这些bug的。

9. 添加和删除:新功能常常需要能够为系统添加新配置,比如说用于电话号码翻译的新配置文件。所以测试它切实可行、以便添加新的配置文件很自然不过。然而,我发现很容易忘了还要测试配置文件的删除。

10. 错误处理:处理错误的代码常常很难测试。最好由自动测试来检查错误处理代码,但有时这不可能。这种情况下,我有时采用的一招就是,临时修改代码,让错误处理代码运行。要做到这一点,最容易的方法就是反转if语句,比如说将if语句由error_count > 0反转为error_count == 0。另一个例子是误拼数据库列名,让所需的错误处理代码运行。

11. 随机性输入:常常可以发现bug的一种测试方法就是使用随机性输入。比如说,H.323协议的ASN.1解码可处理二进制数据。通过发送有待解码的随机性字节,我们发现了解码器中的几个bug。另一个例子是使用测试调用生成脚本,其中调用持续时间、回复延迟、第一方挂断等都是随机生成的内容。这些测试脚本暴露了无数bug,尤其是接踵而至的事件引起的干扰。

12. 检查什么不该发生:测试常常包括检查所需的动作已发生。但它很容易忽视相反的情况――检查不该发生的动作确实没有发生。

13. 自行编写工具:我通常构建自己的小工具,好让测试更容易。比如说,我在处理面向VoIP的SIP协议时,写了一个小脚本,就返回我所需要的头和值。有了这个工具,许多个别情况测试起来很容易。另一个例子是可以进行API调用的命令行工具。通过从小处着手,然后根据需要逐步添加功能,我最后开发出了非常实用的工具。自行编写工具的好处就是,我获得了所需的那种功能。

不过根本不可能在测试中发现所有bug,有一回,我改变了由两部分组成的处理关联号码的机制:路由地址前缀(始终一样),以及从000到999的动态分配号码。问题是,查找关联时,动态分配号码的第一位数字在查询地址表之前就被误删除了。所以,不是寻找637之类的号码,你寻找的是37,而这个号码不在表中。这意味着,它一直寻找到100,所以前100个调用正常,而之余的所有900个调用失效。所以除非我在重新启动之前测试了100多次,否则在测试时发现不了这个问题。




三、调试

14. 讨论:在过去对我帮助最大的调试方法就是与同事讨论问题。我常常只要向同事描述问题,就足以认识到问题是什么。此外,即使同事不是很熟悉相应代码,常常也能給出好主意,表明哪里可能有问题。我在处理最棘手的bug时,与同事讨论这一招来得尤其管用。

15. 密切关注:调试某个问题花很长时间时,常常是由于我做了错误的假设。比如说,我以为问题出现在某个方法中,而实际上这个问题根本不会出现在这个方法中。或者抛出的异常并不是我假设的那个异常。或者我以为在运行软件的最新版本,实际上运行的是旧版本。因此,一定要核实这些细节,而不是犯想当然的毛病。很容易看见预期看见的问题,而不是实际摆在那里的问题。

16. 最近的变化:过去可以运行的代码现在无法运行时,这常常是最后一个变更的对象引起的。有一回,最近变化的对象只是日志,但是日志中的错误引起了更大的问题。为了让诸如此类的回归更容易找到,有必要在不同的提交代码中实行不同的变更,并且要清楚说明变更。

17. 相信用户:有时候用户报告问题时,我的本能反应是“这不可能。他们肯定是哪里弄错了。”但是我已学会了摈弃这样的反应。结果往往证明,用户报告的正是实际发生的问题。所以如今,我对用户报告的问题信以为真。当然,我仍反复核查各方面已正确设定。但是我碰过好多情况下,之所以发生奇怪的问题,是由于不同寻常的配置或意料之外的使用,而我默认的假设是,它们是正确的,程序是错误的。

18. 测试修正版:bug的修正版准备就绪后,它必须进行测试。先在没有修正版的情况下运行代码,观察bug。然后打上修正版,重复测试用例。现在,错误行为应该消失。遵照这些步骤可以确保它其实是个bug,确保修正版确实解决了问题。这很简单,又必不可少。




四、其它意见

这13年来我一直在跟踪我遇到的最棘手的bug,这期间发生了很大的变化。我开发过一个小型嵌入式系统、一个大型电信系统以及一个基于Web的系统。我用C++、Ruby、Java和Python编写过代码。我用C++编码时期的几类bug已完全消失,比如堆栈溢出、内存损坏、字符串问题以及某些形式的内存泄漏。
我遇到的其他问题(比如循环错误和个别情况)少了很多,那是由于我一直对更多的逻辑进行单元测试。但是,这并不意味着没有bug,还是有bug。这篇文章总结的经验教训帮助我在编码、测试和调试这三个阶段尽量减小破坏。要是你在预防或查找bug方面有什么其他的实用技巧或方法,欢迎留言交流。

都看到这里了,就把这篇资料推荐给您的好朋友吧,让他们也感受一下。

回帖是一种美德,也是对楼主发帖的尊重和支持。

*声明:敏捷大拇指是全球最大的Swift开发者社区、苹果粉丝家园、智能移动门户,所载内容仅限于传递更多最新信息,并不意味赞同其观点或证实其描述;内容仅供参考,并非绝对正确的建议。本站不对上述信息的真实性、合法性、完整性做出保证;转载请注明来源并加上本站链接,敏捷大拇指将保留所有法律权益。如有疑问或建议,邮件至marketing@swifthumb.com

*联系:微信公众平台:“swifthumb” / 腾讯微博:@swifthumb / 新浪微博:@swifthumb / 官方QQ一群:343549891(满) / 官方QQ二群:245285613 ,需要报上用户名才会被同意进群,请先注册敏捷大拇指

嗯,不错!期待更多好内容,支持一把:
支持敏捷大拇指,用支付宝支付10.24元 支持敏捷大拇指,用微信支付10.24元

评分

参与人数 1金钱 +10 贡献 +10 专家分 +10 收起 理由
Anewczs + 10 + 10 + 10 32个赞!专家给力!

查看全部评分

firefighter 发表于 2016-7-26 14:10:44 | 显示全部楼层
老司机 你好!
swifter 发表于 2016-7-26 16:44:13 | 显示全部楼层
老司机 你好!
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

做任务,领红包。
我要发帖

分享扩散

都看到这里了,就把这资料推荐给您的好朋友吧,让他们也感受一下。
您的每一位朋友访问此永久链接后,您都将获得相应的金钱积分奖励
热门推荐

合作伙伴

Swift小苹果

  • 北京治世天下科技有限公司
  • ©2014-2016 敏捷大拇指
  • 京ICP备14029482号
  • Powered by Discuz! X3.1 Licensed
  • swifthumb Wechat Code
  •   
快速回复 返回顶部 返回列表