调试网络断线工作心得
在最近的工作中，遇到一个因为网络断线导致界面显示异常的问题，与这个问题纠缠两三天，最后终于解决了。解决这个问题的过程，非常有必要记录下，算是调试经验心得吧。
问题背景
当软件所处的网络状态不好导致软件断线，上层界面显示异常。
思考方法
我一开始打算是从代码入手，一步步往上看。由于现有软件有断线重连的逻辑，这块功能不是我负责的，刚开始有点蒙圈，花了些时间搞清楚断线重连的逻辑，然后就这问题发生的背景开始思索是哪个步骤出了问题，沿着这个路径，把网络断开的后续流程画成时序图，再结合上层处理界面的逻辑，增加若干调试代码，在若干次尝试中，有重现过那么几次，但大部分时候是正常的，这下，不知道怎么办了。
每当工作中遇到难啃的问题时，我有以下两个方法来缓解：
- 就此问题已经做出的尝试以及结果，请教周围其他不忙的同事
- 先把这个问题放一放，解决手头上不那么难的问题和需求
大多数情况下，这两种方法都会使用。通过解决手头上其他问题，可以给受挫的自己鼓气加油。向其他同事请教，我会重新讲述一片这个问题的背景和尝试解决的方法和结果，同事大部分只能指点一二，最后还是要靠自己来解决。
具体措施
这个问题是偶发问题，解决偶发问题，关键在于提高重试频率，增发问题发生概率。在这里，首要的是构造一个不稳定的网络环境，推荐使用 NetLimiter 来控制特定进程的网络状态。对于其他问题，可以尝试一些自动化工具或者Mock软件来快速构造测试压力，使得问题更加容易出现。
由于正常情况下，软件的超时检测时间以及重连间隔都比较长。在这里，为了更好的触发问题，可以降低软件的超时检测时间以及重连间隔，最好达到一断网就能马上触发断线事件。
经过调试发现，有时候在程序中加入断点，会影响通知模块的处理，有可能造成加上断点时，程序表现的正常，去掉断点，程序就不对了。针对加断点造成程序执行路径变化的问题，我也不是很清楚，在后期的调试过程中，逐渐减少断点的使用，增加调试打印，输出些关键变量。
最后方案
针对该问题的解决方案，有上层界面修改和底层修改。考虑到上层修改影响范围小，可控性较好。底层修改影响的范围大，不好把握影响范围，最后采用的修改上层的解决方案，算是质量和进度的妥协了吧。
回顾
从之前面对问题的一头雾水，逐层抽丝剥茧分析后，直到最后解决这个问题，做到最后，居然不记得之前对这个问题一无所知的心理状态，每每想到这个问题，自然而然的从最佳分析路径一路到解决方案，中间没有任何弯路，这种感觉真是奇怪。就好像，对一个事物从不理解到彻底理解后，自己就再也回不到不理解的状态。改完这个问题后，真是浑身舒畅，这感觉真舒畅。
