标签：帮助 关注 原因 很多 span 其他 size 打开 日志
线上的bug，如果是自己写的，一看日志大多数情况就会很快找到原因，毕竟熟悉。
但是如果不是自己写的，可能就需要花费一点时间了。
遇到这种情况，我通常是这样处理：
第一步：查看错误日志，对报错情况有个基本的了解。如果能从报错日志中找到 工程-方法 的信息，直接打开对应的工程，找到报错的地方。如果找不到报错的地方，就可以找前端、测试或者对应的开发明确调用的url。
同时，最好叫提交bug的技术支持/用户，截图或者录制视频。把出错的场景记录下来，明确出错的使用场景，出错的用户，出错的情况，这对之后的排错有很大的帮助。
第二步：和测试一起复现这个问题。测试非常清楚页面的操作，和测试一起复现问题可以事半功倍。
第三步：复现成功后，查看对应的代码。从出错点出发，一步一步推演错误原因。如果粗略阅读一遍代码后无法发现一些明显的错误点，这个时候需要注意梳理业务逻辑关系，如果业务太复杂，可以不必要关注具体的业务细节，而是把关注点放在数据的流转上，也就是数据是怎样产生，经过那些表流转。通常在梳理这些业务逻辑关系的时候，就能够查到逻辑上的错误
第四步：找到可能的错误原因后，修复问题。然后自测，自测完成后，走线上bug修复流程，完成整个修复。需要注意的是，修复bug的时候，我们会经常发现之前的代码不合理的地方，这个之后我的建议是这这次Bug修复版本中不要去动它。因为这块代码不是我们写的，我们可能很难预估修改一句代码带来的影响。我认为最好的处理方式是，找到对应的开发，告知自己的理解，两个人互相探讨一下，如果确实有问题，再跟leader说一下，让他安排人修改。
第五步： 记录bug。如果解决bug的过程中你学到了新的知识，这个时候应该趁热打铁，记录下来。毕竟好记性不如烂笔头。
最后多一句嘴。面对上级分配的bug，很多程序员一看不是自己写的，就不处理，直接转给对应的程序员。这样做确实更快捷，在紧急bug修复时，这应该是最好的方式。但是其他情况，我建议大家还是笑纳这些bug。解决越多的bug，你对业务就越了解，在团队的地位就越重要。
以上都是经验之谈，可能并不符合所有公司的业务。欢迎大家指正和交流。
标签：帮助 关注 原因 很多 span 其他 size 打开 日志
原文地址：https://www.cnblogs.com/catlkb/p/12576326.html
