世上最痛苦的事情莫过于看别人的代码，而如果这个人的代码又写的极其不规范，逻辑混乱，胡乱堆砌，不知所云的时候，痛苦简直成指数倍增长！
今天定位一个和二维码拍摄相关的问题
问题描述：相机入口有拍二维码和拍应用2种模式。拍应用解析缓冲时锁屏，解锁后相机会黑掉or恢复成拍摄模式（缓冲view依旧显示，但是模式已经乱掉，既无法继续拍应用，也无法拍二维码），但是home键切后台却不会（再切回来依旧是正常的解析缓冲页）。
解决过程：
因为我也是刚刚接手这一块，心想home键置后台和锁屏没什么区别，为毛会导致这样的问题？
刚刚开始看这一块，想着先搞清楚是咋回事儿吧，经过一番纠结，总算在混乱的代码之中大致理清楚了处理流程。
bug描述是锁屏会出现，home切后台不会出现，原谅我这人比较落后，首先的想法就是打断点看着两者的区别，结果显然没啥区别。然后又猜想是不是onPause/onResume的时候界面没有控制好（界面控件极多极混乱），找了半天，好像也没有什么特别明显的错误。接着又猜想是不是相机的控制有问题，找了半天也没发现。纯逻辑排查不成，只好关键点打日志，终于发现了一点蛛丝马迹。
原来，在onResume的时候，代码会根据一个sharedPreferences的键值来对扫描控制Handler-ScanHanlder重新做一个初始化，这个sharedPreferences存储的就是最常用的firsrt_use,首次调用。but!!!它调完了以后，却没有给这个first_use赋值为false并commit!!!后面ScanHandler重新初始化却又依赖这个键值对……于是导致了上面的问题。
结论：
也就是说，最终导致bug的其实是一个很小的失误，并且和我看见这个bug后所猜测的原因一条也不符合……并且，它花了我2个多小时来定位（当然，一半的原因可能是我对代码不熟）。
感想：
有些bug是你一看就知道很难定位的，还有一些，是看上去似乎颇好定位，实际却不是那么好定位的（比方说上面的这个bug），但是……真正引发难定位bug的，往往都是code过程中的一些细节。可能只是缺少一个安全性判断，然而又没有抛异常，可能是一个switch,没有考虑全面，又没有加一个default处理……很多小问题并不会影响程序的运行，但是问题却会层层递进，直到在一个你完全不会想到的地方爆发出来，成为一个无法容忍的bug，但是此时，你已经无法一眼看出它的源头了。
这样的bug，真的是不好定位，等到你花了大把时间，反复尝试重现，终于顺着可怜一点踪迹摸到了始作俑者，此刻你只想仰头长啸——‘谁TM写的垃圾代码！’or‘我TM怎么会犯这种低级错误！’
所以，平常code，还是多细心多考虑全面一点，不要只是为了先做一个东西出来而忽略了质量。写代码就像江湖，出来混，总是要还的。今天你可以一天搞定一个程序，明天说不定要花一周来解bug，还不如花3天好好写，说不定只要2天就能让程序稳定。所谓快，最终都是慢罢了！静下心来做事，与大家共勉。