码迷,mamicode.com
首页 > 其他好文 > 详细

【工作总结】我是怎样处理别人写的bug

时间:2020-03-26 19:05:34      阅读:84      评论:0      收藏:0      [点我收藏+]

标签:帮助   关注   原因   很多   span   其他   size   打开   日志   

线上的bug,如果是自己写的,一看日志大多数情况就会很快找到原因,毕竟熟悉。
但是如果不是自己写的,可能就需要花费一点时间了。

 

遇到这种情况,我通常是这样处理:

第一步查看错误日志,对报错情况有个基本的了解。如果能从报错日志中找到 工程-方法 的信息,直接打开对应的工程,找到报错的地方。如果找不到报错的地方,就可以找前端、测试或者对应的开发明确调用的url。
同时,最好叫提交bug的技术支持/用户,截图或者录制视频。把出错的场景记录下来,明确出错的使用场景,出错的用户,出错的情况,这对之后的排错有很大的帮助。

第二步:和测试一起复现这个问题。测试非常清楚页面的操作,和测试一起复现问题可以事半功倍。

第三步:复现成功后,查看对应的代码。从出错点出发,一步一步推演错误原因。如果粗略阅读一遍代码后无法发现一些明显的错误点,这个时候需要注意梳理业务逻辑关系,如果业务太复杂,可以不必要关注具体的业务细节,而是把关注点放在数据的流转上,也就是数据是怎样产生,经过那些表流转。通常在梳理这些业务逻辑关系的时候,就能够查到逻辑上的错误

第四步:找到可能的错误原因后,修复问题。然后自测,自测完成后,走线上bug修复流程,完成整个修复。需要注意的是,修复bug的时候,我们会经常发现之前的代码不合理的地方,这个之后我的建议是这这次Bug修复版本中不要去动它。因为这块代码不是我们写的,我们可能很难预估修改一句代码带来的影响。我认为最好的处理方式是,找到对应的开发,告知自己的理解,两个人互相探讨一下,如果确实有问题,再跟leader说一下,让他安排人修改。

第五步 记录bug。如果解决bug的过程中你学到了新的知识,这个时候应该趁热打铁,记录下来。毕竟好记性不如烂笔头。

最后多一句嘴。面对上级分配的bug,很多程序员一看不是自己写的,就不处理,直接转给对应的程序员。这样做确实更快捷,在紧急bug修复时,这应该是最好的方式。但是其他情况,我建议大家还是笑纳这些bug。解决越多的bug,你对业务就越了解,在团队的地位就越重要。


以上都是经验之谈,可能并不符合所有公司的业务。欢迎大家指正和交流。

 

【工作总结】我是怎样处理别人写的bug

标签:帮助   关注   原因   很多   span   其他   size   打开   日志   

原文地址:https://www.cnblogs.com/catlkb/p/12576326.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!