今天工作上有一个难题无法攻克，以至于我花了大量的时间在这个难题上面。
当时的我，已经被这个难题中的一个细节给“迷倒”了。
这个细节就是，我费尽心思去寻找 android 中冲突资源的 module name，希望通过 compile.exclude 的形式去掉该冲突。
因此，我不停的在搜索这个 module name 是怎么被定义的，最终本末倒置，时间全都浪费在这个细节上了。
我钻牛角尖了。
我被一个不知道是否重要的细节给迷住了。
然后我浪费了大量的时间在探索这个问题上。
当不得已下班的时候，我回头一看，才发现：
自己已经花了一个下午和一个晚上的时间，来研究这个问题了！
不能及时跳出大坑，目光被锁死在一个无关紧要的细节上面，这就像是“捡了芝麻，丢了西瓜”一样。
在回家的路上，我开始跳出这个问题之外，审视自己的行为到底哪里出了偏差。
在这其中，我虽然不停在做事情，但：
- 效率很低。没有找到 20% 的关键问题，而在 80% 中死抠细节。
- 忘掉了本愿。一直在执行，却没回头想过目标到底什么。
- 方法不对。横冲直撞，没有用对方法。
我们在探索问题的时候，就像在大海里面航行一样。
努力和认真，就好比在海里划船。
如果没有目标，你的划船功夫就是白费的。你都不知道自己要去哪里！
这时候的努力和认真，反而会把你推得离答案越来越远。
最终，我意外发现了排查 bug 的妙招。
其实排查 bug 和做实验非常类似，需要很强的调研能力和分析能力，都是从无到有的定位、解决问题。
如果我们能掌握设计实验的原理，那么在设计如何排查 bug 的时候，也能事半功倍。
实验的套路，能很好的转化为排查 bug 的套路。
关于这一点，我希望能新开一篇文章来谈谈。
今天的复盘，就到这里。
P.S.：我们应该找到了主题，在开始行文。
今天的文章，我的主题是不明确的。然而我就开始行文了。
就像我排查 bug 的时候，连根本的问题都没找到，就开始排查一样。
模糊的错误信息害人害己。
P.S.：如何更好的描述一个事情，其实真的很难。
今天的内容，可以尝试使用写故事的形式进行编制：
1、找到坏人，引出悬念
2、发现冲突，引出英雄
3、剧情展开
4、冲突；英雄第一次出手，失败了
5、英雄改变了自己
6、英雄战胜了坏人；高潮！
7、给续集留下悬念
