对于一个程序员而言，有一样东西是绝对不想碰见却又一定会遇到的，那就是Bug。
鲁迅曾经说过，当我们遇到Bug时要冷静，不要慌。
好吧，鲁迅并没有说过这句话
开发应用程序是一个非常有压力的工作，没有人是完美的
因此在这个行业中，代码中出现bug是相当普遍的现象
一个bug并不可怕
可怕的是发现一个Bug，修改之后，会出现一群Bug
此时，我相信你的内心是崩溃的...
对于牛逼的程序员来说，可能会细细琢磨，保持冷静慢慢修复完。
“但是，这只是牛逼的程序员” 含着泪也要把这句话加粗。
那么对我们新手来说，碰到bug该怎么处理呢？
最近，小知从自己的一个大神朋友那里学了几个方法，在这里分享给大家.
▲ 优先解决那些可重现的，可重现的bug特别好找，反复调试测试就好了，先把好解决的干掉，这样最节约时间。
▲ 对于某些bug没有头绪或者现象古怪不知道从哪里下手，找有经验的同事问一下思路，因为在那种开发多年的大型系统里，经常会反复出现同样原因的bug，原因都类似，改了一处，过一阵子另外一处又冒出来，而且无法根治。
▲ 放大现象，有些bug现象不太明显，那么就想办法增大它的破坏性，把现象放大。这只是个思路，具体怎么放大只能根据具体的代码来定。比如：美剧《豪斯医生》里有一集，怀疑病人心肺有问题，就让病人去跑步机上跑步，加重心肺负担，从而放大症状。
▲ 二分法定位，把程序逻辑一点点注释掉，看看还会不会出问题，类似二分查找的方法，逐步缩小问题范围。
▲ 模拟现场，有时候我会问自己，如果我要实现bug描述的现象我要怎么写代码才行？比如：我遇到一个死锁问题，但是检查代码发现所有的锁都是配对的，没有忘记解锁的地方，而且锁很简单就是一个普通的临界段， 保护几行赋值语句而已。这样的代码怎么写才能让他死锁呢？我想如果让我故意制造这样一个现象，只有在上锁的时候强制杀掉线程了。既然这样就可以去看看有谁 强杀线程了没有。
▲ 制作工具，针对某些bug编写一些调试辅助工具。比如，我那个系统没有完善的崩溃报告，虽然也有dump，但是分析出来的callstack经常不准。于是我为解决崩溃问题编写了个工具，会自动扫描代码，在每个函数入口和出口插入log，以此来定位崩溃点。
▲ 掩盖问题，虽然这样做有点不厚道，但是有时不得不这么做。有些bug找不到真正的root cause，但是又要在规定时间内解决，那么我们就可以治疗症状而不去找病因。比如用try catch掩盖一些奇怪的崩溃。不到万不得已不要这么干，未来可能会付出更大代价。
而对于自己和别人写的Bug，程序员的心理也是不同的。
面对别人写的bug：握草,怎样的一个撒比才能写出这样的bug啊
幸好有哥在，哥就是救世主！
面对自己写的bug：
别人发现：有bug,不能够啊！你测试过了么？可以重现么？我警告你不要搞事啊！
真有啊？慌什么慌，谁还没写过BUG咋的？
自己发现：还好发现了，哥真是犀利！看看那群废物
这么明显的bug都看不出来，大撒比！
So，下次当你发现程序员写的代码出现bug时
请你这样优雅的指出：
怎么样，在座的各位程序员躺枪了么？
