一、前言
22年底后，团队人员变动后，项目疑难线上问题的跟进解决工作落到我身上，同年承担大型项目的开发，其复杂性以及紧凑的时间线导致QA阶段BUG数量较多。
23年是我的BUG元年，累计解决BUG数量超500个。 
在我刚入职XX时，我Leader是个BUG专家，很多时候在描述现象后，能快速定位到BUG根因；
年轻的我十分羡慕这种功力， "Coding五分钟，Debug三小时"，Debug效率提升会让你少加很多班，省下的时间可以拿去撩妹，打机，或者去舔你老板拿高绩效。
500个BUG，你已经深入理解你负责的业务系统，同时对代码运行的底层逻辑有抽象整体的感知，这都能很大程度提升Debug效率。
500个BUG，从措手不及，到游刃有余。
二、疑难BUG案例
什么是疑难BUG，定义也许有很多种，但一定有个共性， "无法"复现，展开如下
- 存在复现路径，但概率复现
- 存在复现路径，但十分隐蔽，定位后可以稳定复现
这里分享两个疑难BUG案例
2.1 Bluetooth Sco 无限重连干扰通话
简述下背景，项目使用 Agora（声网）构建RTC功能，VIP用户在使用过程出现音频断续问题；问题十分棘手
- 无法复现
- Agora技术团队介入排查近一周后没有结论
在完成手头优先级较高的需求后，介入排查，基于用户描述，在关闭蓝牙后，问题消失，以此为切入点，与AgoraTeam协同梳理RTC层蓝牙连接相关日志，发现蓝牙Sco连接在不间断断开重连，因现象无法复现，对此我们提出一些猜想
❌ 猜想一：Samsung SM-S908E（Android 13）系统重复执行startBluetoothSco
日志显示，SCO_UPDATE广播在重复回调 Disconnected → Connecting → Connected，初步确定是重复执行sco连接导致通话异常；且因在通话过程中，用户携带了蓝牙手表等原因，大家的猜想基本一致（但因缺乏复现设备，暂无法验证）；
在AgoraTeam提供修复包（监听Disconnected广播并主动stopBluetoothSco）后， 打包验证失败，猜想错误
❌ 猜想二：AgoraSDK 在特定场景下，重复执行 startBluetoothSco
个人经验，（Android）系统往往是稳定的（除非是Beta版本），所以我猜测业务层有重复执行startBluetoothSco的逻辑，但在和AgoraTeam确认后，SDK理论上在joinChannel时执行一次startBluetoothSco，猜想错误
猜想三：SeaTalk 在特定场景下，重复执行 startBluetoothSco
福尔摩斯说过："当你排除一切不可能的情况，剩下的，不管多难以置信，那都是事实。"
在提出这个猜想后，我们把关注点从RTC层移到了业务层 ，回溯业务日志后，发现（新版本）确实在重复调用startBluetoothSco，在出包委托用户验证后，成功修复
2.2 锁屏状态接听通话异常
背景简述，用户在通话一分钟左右后，音频无法正常传输，一般使用RTC功能，需要开启前台服务保活，我们在正常路径尝试后无法复现，于是提出猜想
❌ 猜想一: 用户对应用开启了电池受限模式，在进入后台后，系统录音服务被暂停
应用默认电池模式是优化状态的，我们在把应用切到受限模式后切到后天进行通话，Samsung-S12可稳定复现
但在与用户联系确认后，却发现应用处于电池优化状态，事情变得棘手了，在猜想无法快速验证且找不到切入点时，我们可以看下日志，把核心路径的链路梳理完毕后，也许你能找到一些线索，细节如下 
可以发现用户的异常通话，均是在锁屏状态下收到来电，然后快速锁屏（进入后台），当应用进入后台后，系统暂停了录音服务；根据日志路径成功复现，并提出猜想
❌ 猜想二：特定路径下，系统兼容性问题
控制设备系统变量，相同的路径下低版本无法复现，可确定属于新版本代码引入的问题
猜想三：特定路径下，Service启动失败
锁屏状态下，收到来电，CallService压根没执行，这会导致SeaTalk进入后台时，没有前台服务，系统认定为后台进程，音频采集线程被暂停，猜想成立
2.3 挑战
在接手一些"无法"复现的疑难BUG时，我对相关逻辑完全是零基础的陌生状态，这要求开发
- 在短时间内快速掌握核心流程逻辑，全面理解上下文，排除干扰因素
- 再进一步基于问题现象或日志，结合相关技术，确定复现路径，提出猜想，再进行验证
有些问题属于VIP性质，十分紧急，时间压力会比较大，在压力巨大的场景快速解决，能进一步提升研发专业能力。
三、沉淀
Debug三个核心过程，定位（查找根因） -- 梳理（捋清楚上下文）-- 修复（Coding，必要时重构）-- 归因分析（尝试找出优化点，设计避免重犯机制）；普通开发往往会忽略"梳理"和"归因分析"这两个步骤，缺乏"梳理"，会导致在修复阶段引入其他BUG，缺乏"归因分析"，往往会导致在后续迭代过程，出现类似的问题。
量变促进质变，随着解决的线上问题与业务 BUG 越来越多，总结出一套方法论，前提需对技术原理有正确理解，并且对业务足够熟悉
流程节点可细化，类似验证阶段，针对不可复现的问题，需进行模拟验证，进一步保障假设成立