• 静思
  • 吴言片语
    • 吴言
    • 片语
    • 杂七杂八
  • 死于青春
    • 一路走好
  • 乌合麒麟
  • 纪念
    • 5.12
    • 3.23
  • GitHub
    • A List of Post-mortems
    • The Art of Command Line
  • 关于
    • Privacy Policy

程序员的信仰

金鳞岂是池中物,一遇风云便化龙

HOME » 技术生活 » 我习惯中的bug处理方式

我习惯中的bug处理方式

2015 年 12 月 18 日 @ 上午 10:33 by Jay | 被踩了 3,205 脚

这是一年多前的一封我写给部门的内部邮件,现在拿出来分享下

Hi,all

我一直在强调“有战斗力的team”,也一直在强调各种流程,比如对于bug的修复流程,我一直主张尽量利用JIRA对bug的整个生命周期进行管理,尤其是截图、comment、work log、commit和code review,但是在推行过程中遇到了一些阻力。其它有关“耗费时间精力”、“太繁琐”于我而言都不是理由,我认为真正的问题在于1、大家对流程的好处没有深刻的体会;2、没有sample去参照去学习

对于comment,我们的JIRA里有一些是“已修复”,大部分没有任何comment,而真的利用comment进行交流的很少。可能大家更习惯于线下交流,但我想说的是,线下交流固然方便、省时间,但是对于一个团队的积累是没有太大好处的,比如,应该没人能告诉我这个快两年前的bug的原因是什么,又是怎么解决的:(略)。另一点,在一个remote的team里,是没有办法进行实时的线下沟通的,能够依靠的就只有bug tracer里的comment和各种记录,这一点大家可以随便找一个开源项目,去bugzilla、jira里翻翻就知道了。对于这样的项目,开发人员变化很快,用户量很大,只有详细的bug记录才能保证1、整个项目尤其是bug的生命周期是可追溯和可分析的;2、对于开发、测试、用户都能很好地利用之前的记录判断一个新bug是否duplicated,是否与已有的bug相关。而有些比较极端的开源项目,在你新建bug之前是必须进行搜索操作的,确保你将要提的bug在一定程度上是“新的”,从而避免浪费开发人员排查的时间;3、对于新加入团队的开发和测试人员,只需要花点时间就能对之前项目的bug情况有个大致的了解,也能给之后的bug修复和测试提供一些方向性的指导

在这一点上,我们刚刚起步,需要时间去打磨和积累

以下分享一个今天刚修完的bug,展示一个“我(在之前的team中)习惯的bug处理方式”。相关链接:(略)

1、这个bug在我3/28接手时和曹明做过基本的沟通,大致了解了bug的情况。但是由于之后一直没腾出时间,所以有近一个月的时间没有处理,等今天我想处理时,发现对之前沟通的内容已经完全没有了印象,于是要求曹明将之前的情况添加到comment中:

(略),在此感谢曹明的comment写得很详细,我们之后没有进行任何二次沟通

2、看到comment后我便开始看相关代码,并很快定位到了原因。此时我完全可以直接进行修复、提交测试,但我还是按照自己的习惯将详细原因记录了下来,并附上了截图:(略)。随后加了个comment给了解决方案:(略),并给出了不同方案的对比。最后,记录了30分钟的work log:(略)

3、大概6点半开始进行修复,也就花了十几分钟,然后在本地进行了测试并通过,同时附上了线上数据清理的SQL:(略)。此时我也可以直接标记resolved并提交测试,但是觉得这个bug的测试需要进行数据库操作,相对麻烦,于是给了相应的数据筛选SQL和造数据的方法,并给了相应的截图证明“我的确修复了”:(略)。然后提交代码,新建code review,标记resolved并记录一个小时的work log。做了这些事情,花了我大约半个小时的时间,我的想法很简单:1、测试方式、修复截图我都提供了,之后的验证过程QA应该不会再来问我,不会打断我之后的时间,我也就不用再花时间去回忆今天的修复过程、相关SQL,然后向QA讲解;2、上线文档中需要的SQL我也提供了,之后QA在写验收报告时也不需要来打断我我的时间。总之,看似我花了十几分钟修复一个bug,却花了更多的时间去写一些“额外”的信息。我的收益在于,正常情况下我之后的时间不会再被与这个bug相关的任何事务打断,QA的验证工作也应该会因为这些comment简化不少。我多花了半个小时的时间,但避免了之后的时间碎片,同时缩短了QA的验证时间,整体上来讲是相当划算的。最重要的,即使两年之后,根据这些comment以及提交的相关代码,任何一个开发、测试人员都可以很方便地恢复今天的场景,了解这个bug的来龙去脉。

延伸一句,之前有一些开发人员向我诉苦自己的时间经常被QA占用或打断,我的解决方案是:多替对方想想,提前把QA可能会来问的东西告诉他们,并尽量详细些,到时候就能理直气壮地说一句“自己看comment去,我都写了”(当然如果QA对于5603有任何问题,仍然可以直接来问我)。而如果真的是很复杂的信息,(重复)沟通在所难免,那也主动一些,提前找他们沟通,因为与其自己的大块时间被动地被他们的问题打碎,不如提前充分利用自己已经存在的碎片时间把信息分批告诉他们。同样一个小时,整块的和打碎的价值相差十万八千里,这跟内存是一个道理

至此,整个bug的修复基本完成,只等待验证和code review


-- EOF --

除非注明(如“转载”、“[zz]”等),本博文章皆为原创内容,转载时请注明: 「转载自程序员的信仰©」
本文链接地址:我习惯中的bug处理方式

分享

  • 点击分享到 Facebook (在新窗口中打开) Facebook
  • 点击以分享到 X(在新窗口中打开) X
  • 更多
  • 点击分享到Reddit(在新窗口中打开) Reddit
  • 点击分享到Telegram(在新窗口中打开) Telegram
  • 点击以在 Mastodon 上共享(在新窗口中打开) Mastodon

赞过:

赞 正在加载……

相关

Posted in: 技术生活 Tagged: career, coding
← WebP测试
我就是喜欢你看不惯我,却不得不和我一同建设中国特色社会主义的样子 [zz] →

android (9) apple (20) augmentum (9) Beijing (21) bt (8) career (28) coding (38) firefox (10) google (36) hibernate (11) ibm (11) iphone (10) java (93) linux (16) m$ (26) mac (58) macos (27) nazca (9) olympics (8) oo (8) playstation (10) rip (8) Shanghai (39) spring (9) tips (45) tommy emmanuel (8) ubuntu (12) usa (23) windows (9) 北航 (17) 博客 (29) 吐槽 (8) 周末 (9) 和谐社会 (26) 小资 (11) 愤青 (40) 方言 (10) 朋友 (77) 歌词 (8) 烟酒不分家 (18) 爱国 (19) 爱情 (8) 犯二 (15) 破解 (8) 足球 (11)

烫手山芋

  • 再谈苹果的输入法:这一次是靠OS X自带的输入法来翻身的~ - 被踩了 27,445 脚
  • 生活,就是一个期待跟着一个期待 - 被踩了 21,359 脚
  • 星巴克饮品缩写大全(Starbucks Drink ID Codes)[zz] - 被踩了 18,417 脚
  • 从一个全角冒号说一下我为什么不感冒iOS - 被踩了 14,333 脚
  • 有关Character.isLetter()和Character.isLetterOrDigit() - 被踩了 13,591 脚

刚拍的砖

  • leo 发表在《再谈苹果的输入法:这一次是靠OS X自带的输入法来翻身的~》
  • 花 发表在《再谈苹果的输入法:这一次是靠OS X自带的输入法来翻身的~》
  • 无名氏 发表在《从一个全角冒号说一下我为什么不感冒iOS》
  • Jay 发表在《Mac OS geek级问题》
  • Wei Wang 发表在《再谈苹果的输入法:这一次是靠OS X自带的输入法来翻身的~》

随便看看

  • 这一天,我们创造了记录9 年 ago
  • 在Struts中使用Validator实现可配置的信息校验(一)9 年 ago
  • 足球的疯狂17 年 ago
  • 子曰[子曰]20 年 ago
  • 中国互联网网站集体维护名单(2009.6.3起)[zz]10 年 ago

文以类聚

光阴似箭

其他操作

  • 登录
  • 条目 feed
  • 评论 feed
  • WordPress.org

Copyright © 2025 程序员的信仰.

Jay's Omega WordPress Theme by Jay

 

正在加载评论...
 

    %d