这是我参与更文挑战的第14天，活动详情查看： 更文挑战

引子

今天不想再写应用级别的文章, 改变下思路, 想和各位新人小伙伴们聊聊如何正确并快速的处理Bug

有过一段时间工作经验的兄弟们一定或多或少注意到

在每天7.5小时的工作时间内, 改Bug这件事会占据其中的50%甚至70%

就像那句戏言, 不是在改Bug, 就是在创造Bug的路上

所以, 我们到底该如何快速解决Bug, 提高工作效率从而划水呢?

为什么会有Bug

这个问题乍一看像是废话, 但在笔者看来, 却是解决问题的重中之重, 不信看看我列出的如下情形:

1. 自己手残, 成为Bug制造机
2. 对于标准库不熟悉, 错误的使用了其中的方法造成异常
3. 对于业务逻辑不熟悉, 导致数据产生问题
4. 第三方包的代码错误, 导致运行中产生问题
5. 自己所用语言存在的坑

你看, 其实Bug产生的原因无非就是这些, 如果各位能快速的确认自己面对的Bug类型, 解决思路自然而然就清晰了

这里只讲方法论, 并不讨论具体的解决方案哦

如何确认Bug

我发现很多兄弟在遇到Bug的第一反应, 就是从自己脑海过往的经验中寻找问题的根源, 随后说出那句最经典的话

“我好像遇到过这个问题, 我猜/我觉得可能是XXX的原因, 试试把XX改成XX看看还报错么”

问题的根源就在于”我猜/我觉得”

计算机或者说写代码, 是一门严谨的科学, 对于0和1来说, 对就是对, 错就是错, 不存在什么猜测和觉得, CPU也不是靠感觉来运行的

市面上大部分的编程语言都会明确打印出错误信息

在面对Bug或异常的第一时间, 应该是一字一句的仔细读代码打印出的错误信息或日志, 而不是靠自己的经验去判断, 就算要, 也是读完错误日志再去

我们平时最讨厌的不就是长辈用自己的人生经验来教导自己么, 为啥我们还要对计算机宝宝这样呢?

所以, 请各位兄弟们谨记, 在出现代码抛异常的Bug时, 先读懂打印的错误信息

在出现业务异常的Bug时, 先对比预期结果和实际结果, 分析它们的不同

万万不可靠感觉走天下

如何寻找Bug解决方案

首先, 我只是个普通的程序员, 并不是天之骄子

那么, 我遇到的Bug大部分高手们都遇到过, 我是可以从网上找到正确的解决方案的

所以, 我需要做什么事呢?

首先, 我会寻求同事和技术总监的支援, 远亲不如近邻, 大神不如爱你的小伙伴

如果它是开源包中的问题, 那么我会去这个开源代码Github主页中的Issues中寻找有没有结果

如果它是标准库和编程语言的坑, 我会去官方文档寻找答案

如果以上内容都不是, 我会选择一个好的搜索引擎(例如必应)或者好的论坛(例如国外某知名网站), 对错误信息而非我的猜测进行搜素, 并认真查看和我情形类似的解决方案

如何减少Bug

老生常谈, 多在掘金写总结文章, 定时回看