唠嗑与思考：如何面对一个bug

昨晚独自在夜空下走了一段。空旷的马路偶尔有车驶过，轮胎与地面摩擦的发出噪声。我在繁灯的陪伴下，内心平静却又感到一丝孤独，思绪也逐渐发散。恰巧我刚被一个bug挫了锐气，于是我就对“面对一个bug该做什么选择”这个问题，进行了更加“宏观”的、偏向方法论的思考，然后进一步开始考虑“怎样debug才能收获最大”。想法还没有很成熟，写出来博君一笑。

首先，面对一个bug该做什么选择？

作为引子，先看一个实际问题的抽象。假如我们开车沿着导航去往某个目的地。开到一条陌生的路，发现路上有一个无法通过的坑。结合前人填坑的指南、自己的一些经验，经过简单的尝试，我们都没能填上这个坑。这时候反应会是什么呢？最后可能又会采取哪些措施呢？

就我个人而言，第一反应就是“要不要掉头回去换条路”。当然，诸如“能不能把坑填一填”“问问周围其他人怎么办”“导航是不是坏了”“我怎么这么倒霉”“别人会怎么解决现在的情况”等等想法也会渐渐涌出。有些想法或许会有很大帮助，有些想法则没有价值。

开车就像运行一段程序，目的地就是使用代码运行出正确的结果。而坑就是代码运行时遇到的、千奇百怪的bug。所以其实所谓“要不要掉头回去换条路”的方式，底层的思想就是“当前的坑解决成本过大”，认为“换一条路”可能是性价比更高的办法（即使认为另一条路也可能会有坑）。而“能不能把坑填一填”对应的就是试图解决bug，或许还可以借机提高自己调试bug的能力水平；更优秀的人在解决bug后，会选择分享自己的经验，归纳总结出“指导别人避坑、填坑的简易指南”。大多数情况下，我的选择介于两者之间，“把坑填到勉强能过的程度”，进而当作什么都没有发生，开着车扬长而去。

再把思绪收回，聚焦我遇到的这个bug：在调用插件组件的时候，调用热度图、折线图，代码能够无报错地运行并结束；然而用一模一样的手段调用条形图，则会导致页面卡死并自动关闭。我在经过一个小时心流、一个小时一般专注、三个小时不太专注的调试后，并没有成功解决bug。因为这个插件是老师推荐的，比较冷门且没有什么博客教程；并且根据我的判断，换个更加常见插件大概率比较容易实现，在我发消息询问老师能不能“能不能换个插件绘制条形图”的时候，老师表示：“别逃避问题了，这些解决问题的经验对你以后有很大帮助的。”

实际上，我提出“掉头换条路”的时候，希望得到的回应要么是同意，要么是“更专业的调试建议”。很明显，老师的回复并不符合我的期望，而我第一反应也不太服气，觉得死磕这个bug没有价值，只能感到时间的浪费，“换个插件”并不算逃避问题。经过一些思考，我还是选择了相信老师，决定和这个bug堂堂正正地对决，并且在对决中尽可能要有所收获。

不过当遇到难以逾越的“坑”，我最愿意采用的想法就是“换条路”，或者像鸵鸟一样选择把头埋进土堆，并用这样“更高效”的理由来说服自己，这就是一种逃避。回想高中竞赛，对于稍稍吃力一些的难题，我也会“机智”地选择逃避，这导致我后来进步越来慢，不会的题目还是不会。缺少这种“必须搞定的冲劲”，看似可以用一样的时间学更多知识，但可能学到的都是皮毛，大凡比较有价值的，可能都不会太简单。

老师略带批评的指点，其实是我在夜色下开始思考“如何面对一个bug”直接诱因。在没有特别大时间压力的情况下，核心的问题就是如何提高自己的代码调试能力，那选择应该就是“堂堂正正”。

那么接下来就自然而然地开始思考第二个问题，“怎样debug才能收获最大”？

首先想到的就是寻找关于debug的教程、练习题，培养debug的正确思维方式。这需要有精心设计一些bug，并且有对应的思路、答案可供练习者参考。练习者在解决这些bug的时候，可以更加系统地、明确地感受到bug产生的原因，并加快吸收。可惜的是，我在网上简单搜索了一下，并没有很容易地找到类似的教程。或许这个领域还是一个书籍的真空区，甚至我想我如果有能力的话，就动笔写一本书（书名大概会是《让我们一起捉虫子》），内容就是精心挑选100个有bug的代码供读者调试，并给出系统性、理论化的调试方法和解决方案。

其次就是调试工具的使用。还是拿填坑类比的话，如果说大一时候我调试能力是“空手搬砖级”（不太会debug），我现在可能就是“铲子级”（稍微会一点debug工具），而最终目标可能就是“大型挖掘机级”（我暂时不太理解的鬼神境界）。这之中差别可能就是来源于对调试工具理解的深度、使用的熟练度。

第三就是经常听说的代码测试。我现在还不太会写单元测试、try-catch也没有用过几次，希望未来一两年的时间里，我能够越来越熟练地掌握这些技术。如果可以根据教程，结合代码，学习调试、测试的方法，coding能力应该会进步神速。

不过稍微理了理自己的思绪，竟然已经水了这么多字数。先想到这一步吧，接下来该动手去做了。

水平有限，欢迎指点。感谢您的阅读和点赞。