🐛 记录一次最失败的 debug 过程
!本篇文章过于久远，其中观点和内容可能已经不准确，请见谅!~
想分享的是一次哭笑不得的 debug 寻找记~，不是最傻的一次调试精力，但是找到问题最想摔键盘的一次，必须复盘下~~
记录一次最失败的 debug 过程。
国庆 7 天长假回家归来后就遇到很多烦心事，好不容易来到心爱的工位前，打开电源，擦拭键盘，打开项目，启动开发环境....
飘红了~~
大意是找不到某个支持库，放到我现在马后炮就是两下鼠标的问题，当时却是一场疯狂的 debug 过程。现在总结下来犯了很多不应该的错误：
不应该啊，之前还好好的，没动啊~~~
确实代码在节前是没问题的，重启后出现问题，很自然的会这么想。
但是实际上并不是全部错误都是代码的问题，一个项目开发调试过程中依赖了很多 sdk、本地环境等，很多都是有版本要求，比如单单开发 flutter 就涉及到 Flutter SDK、Dart SDK、Shell、AS 版本要求等，还包括安卓套件 Android SDK、support 包、JDK、Gradle、build-tools、platform-tools等，一旦其中依赖变动，可能是开发者工具自动更新设置，也可能是自己手动升级，很容易导致项目跑不起来。
所以以后如果出现问题，排除了自己编写的代码问题，一定要想想是不是某个依赖升级或者修改了。
点击飘红到框架代码中，心想这块自动生成的，不会有问题的，向上找找错误 Stack 也没什么值得看的~~~ 到底哪里出问题了啊！！
看到飘红的时候，问题的定位是开发者工具自动生成的目录里，不知道为啥，脑袋里默认这块是没问题的（其实点进去能看到出错的地方），所以没有从这块详究。反而更加确信是自己的环境问题了。
从这也能推断出来，用的一些比较热门的框架、协作同事的运行代码，其实都会有这个问题，而很多时候调试也默认这些东西没问题，看来以后还是需要保留一些警觉的。
肯定是之前升级的问题，我把全部依赖也升级到最新的，肯定没问题~~~
在认为是自己的环境问题之后，在不清楚问题的情况，尝试创建新项目没问题，不同的新项目形式也没问题，然后就各种升级到最新版，花了很多时间来验证哪个环境配置的问题，最后差点重新装整个 Android 开发环境。
这些都是在大概知道问题，但是不确定，然后胡乱升级，尝试不同的依赖版本，期待莫名其妙的好。就像是下面的漫画似的：
看起来很搞笑，但是有时候真的是这样的。
解决不了，只能搜索了~~~
技术栈问题分不清，这个项目是 flutter 和 Android 混合的，Android 部分是 flutter sdk 负责，所以搜索问题的关键词一直想的都是 flutter + bug，其实并不是，在这块搜索不出任何有用的东西。
项目这么着急，居然还出现这个问题，现在有一个临时解决方案，拷贝到别的项目下可以开发，但是没法协作，不行只能暂时先顶着了~~
调试的过程中，一般的小问题一下能看出来，中等问题也大概有思路，最担心的调试是不知道哪里出错了的时候，更是花了很多时间都没有任何头绪，项目进度耽误很多，导致心浮气躁。
这个时候心里就偏向于更多比如暂时可用的方案，可能会解决暂时的问题，但是后续的开发肯定会受到影响。
调试 bug 就像是调查一个案件，从线索入手，推断问题所在，而不是想当然的认为谁是凶手，然后刑讯逼供。
- 第一时间从最开始的错误开始排查，不用屏蔽不熟悉的代码；
- 无论是开发者工具生成、框架的代码还是自己的代码，都照查不误；
- 在复杂依赖的环境下，不确定问题的时候不要花太多时间尝试不确定的解决办法来胡乱尝试；
- 问题没有思路的时候果断请求同事从不同角度提供建议，协助调试；
- 无论花多长时间，保持情绪稳定，中断休息等方式，保持自己的状态；
感谢您的阅读，本文由 Ubug 版权所有。如若转载，请注明出处：Ubug（https://ubug.io/blog/worst-debug）
