一次艰难debug的反思

已经很久没有遇到如此顽固的bug了，总共耗费了我近1个礼拜的时间。期间的种种冲突，个人崩溃，最终解决方案的形成，到回过头来的反思，实在有太多值得梳理的东西。

从结果上来讲，这是个人js基础极端薄弱的集中体现，是对js闭包、基本流程和运转方式掌握不到位的综合反应。正因为基础薄弱，所以debug到某个阶段，竟然不知道该如何制定探索方案。

从调式的方式来讲，面对这样顽固的bug，我并没有做到冷静分析、科学梳理。在跨过某一个节点后，我可耻地又成为了newbie时期的模样：对一切都持神秘的态度。不过是因为别人提了一句，这个系统有点混乱。自己似乎一下子就找到了什么光明正大的理由，就可以把所有的责任推卸出去，可以不用、不必去把问题找出来。

这种黑盒态度，等同于封建迷信，似乎要凭借什么不可告人的运势、辛苦和神秘，才能够将一个问题解决。这是我所厌恶的，但却依旧不断再犯的东西。从信念上讲，我再一次将问题划归为了“不可知”，于是，整个形势就陡然发生了巨变。因为你将一个问题判定为了“不可知”，你允许了侥幸心理的存在。因为你的侥幸心理，你对一切就不再保持一颗空灵之心，不再相信逻辑、相信理智。

所谓的将理智抛诸脑后，就是开始颠倒黑白、指鹿为马。

• 你在过往经历中能找到某个类似bug的解决方案，不是因为你做了很多的无用功，而是因为你在这种低效的搜索中，恰好碰到了解决方案。所以这里的秘诀不是做无用功，而是枚举法、网格搜索法，不断地低效穷举。而如果你能够以更优的策略做搜寻，一定是可以更快地解决bug。

• 总是用苦力和莫名其妙的怪异方法做比对，只会让自己徒劳耗费精力。但内心却总是有一种情感上的寄托，似乎历尽艰难，就能有回报。所以这是非理性的第二点：不是精准地找到是什么东西、核心策略导致你有回报、有成功，而是诉诸于“苦难情节”。

• 越是找不到方法，就越是陷进去，开始不思考、不用谋略去制定测试和探索方案。像一只苍蝇一样乱撞。更可怕的是，自己越是这样，就越是深深不可自拔，不知道如何停下来，徒劳地耗费时间。

• 再往后更可怕的是什么呢，开始像学生时代做不出数学竞赛题目时，思绪胡乱遨游，开始诉诸于命运、劫难、劫数等玄幻的封建迷信。似乎终有此劫无法逃避。可实际呢？一个技术问题解决不了和劫数有什么关系？无非是技术基本功不扎实，学的东西不到位，掌握的东西不细致。可自己早已脱离了理性，开始在“不可知”的世界里越走越起劲儿。

伴随着非理性的，是自己抗压力的严重失衡。在高压之下，自己无法理性思考问题，无法合理地、系统性、有条理地制定自己的探索方案。面对一个bug，特别是一个神奇现象的bug，你能做的应该是不断地通过“不同种类”的测试，来将可能出现问题的范围缩小。这个时候，最重要的就是精心制定合理的测试方案。

没有条理、没有理性的探索方式，就会导致制定出N个只会得出相同结论的test case。那么请问，这样的方案有何意义？如果你已经在某个方向上做了测试，那么你至少应该让问题的范围缩小一半，即是二分。而如果你的测试用例连这么基本的标准都无法达到，请问，你制定出来的探索方案还合理吗？

再来，当你感觉到“应该”要用测试用例缩小问题的定位范围，而“实际”感觉困难或者不能时，你就应该果断地停下来细细思考，而不是闷头继续写一堆、执行一堆毫无用处的测试方案。你该从头到尾去梳理一遍，自己做过哪些测试，它们意味着什么，但同时又不意味着什么。关键就是要想清楚它们“不意味”着什么，才能发现还有哪些地方和模糊点尚待测试。这是关节处。

所谓工程师，最重要的就是要能够把问题、把过程梳理得透彻，能够明察秋毫。什么叫明察秋毫？就是连羽毛、头发丝那样的细节、差别都可以发现。工程师的部署，应该。那么，一个大前提便是，你至少要能够把每一粒尘埃都装进自己的脑海里做到心中有数。如果你只能够觉察到某一部分的尘埃，那有怎么去谈论让每一粒尘该都有的放矢呢？

科学、工程的世界里，不允许有模糊不清的地方。你可以不知道，但你不能够把“不知道”当作知道，更不可以把“不知道”归因于各种莫名其妙的“不可知”黑盒。工程师的任务，首先要能够明确地察觉出、理清楚哪些是清楚的、哪些是不清楚的。基于这个认识，再理性地制定攻克方案，而不是蛮干、更不是寄托于“神谕”或者“祈祷”，期望通过侥幸使自己的方案发挥效果。

这次经历，唯一值得称道、也是我解决这个bug的重要因素，便是我没有闭门造车，而是以开放的心态诚恳地向周围的朋友求助。在与他们的谈话中、建议下，自己不断获得启发，从而能够将这个bug解决。终于，在只求“解决问题”这个方面，自己更为激进一些了。

感谢向我提供帮助的这些朋友们，有你们真好。

近期回顾

《》
《》
《》

如果你喜欢我的文章或分享，请长按下面的二维码关注我的微信公众号，谢谢！

更多信息交流和观点分享，可加入知识星球：

VIP赞赏专区：