伙计取下壁上挂的一块乌黑油腻的东西，请他们赏鉴，嘴里连说：“好味道！”引得自己口水要流，生怕经这几位客人的馋眼睛一看，肥肉会减瘦了。肉上一条蛆虫从腻睡里惊醒……
伙计忙伸指头按着这嫩肥软白的东西，轻轻一捺，在肉面的尘垢上划了一条乌光油润的痕迹，像新浇的柏油路，一边说：“没有什么呀！”顾尔谦冒火，连声质问他：“难道我们眼睛是瞎的？”大家也说：“岂有此理！”……
肉里另有两条蛆也闻声探出现。伙计再没法毁尸灭迹，只反复说：“你们不吃，有人要吃----我吃给你们看----”店主拔出嘴里的旱烟筒，劝告道：“这不是虫呀，没有关系的，这叫‘肉芽’----‘肉’----‘芽’。”方鸿渐引申说：“你们这店里吃的东西都会发芽，不但是肉”
究竟什么是bug，对于经常玩游戏的我们来说，bug通常是游戏过程中出现的种种意外
例如突然掉出地图外
迷之物理引擎
以及各种贴图bug
这些与用户期望大相径庭的软件行为，就叫bug。然而要解决这些bug并不是一件容易的事情。
解决bug是一件费时又费力的事情，尤其是在商业化中，这些都是要算在人力成本中的，不然为什么很多无良的游戏厂商出的游戏bug频出，就是因为优化和修复bug实在是太费钱了。
这里不得不黑一下育碧公司，旗下的刺客信条：大革命被誉为显卡革命：大掉帧，以及各种贴图bug
不过为什么要称育碧是无良厂商呢，因为很多游戏厂商只顾着快速发新游戏圈钱，然后就像下图一样
那么如何debug呢？
以下转载自知乎
1. 优先解决那些可重现的，可重现的bug特别好找，反复调试测试就好了，先把好解决的干掉，这样最节约时间。
2. 对于某些bug没有头绪或者现象古怪不知道从哪里下手，找有经验的同事问一下思路，因为在那种开发多年的大型系统里，经常会反复出现同样原因的bug，原因都类似，改了一处，过一阵子另外一处又冒出来，而且无法根治。
比如：我那个系统里有个特别危险的API，接口参数比较难用，一旦有人用错了某些情况下就会出诡异的现象，解决很简单，找到调用这个API的地方把调用方式写对就好了。为什么不根治呢？因为要保持兼容性不能改接口了。Windows系统里就好多这种烂API。
问下老员工吧，说不定他们都遇到过好多次了。
3. 放大现象，有些bug现象不太明显，那么就想办法增大它的破坏性，把现象放大。这只是个思路，具体怎么放大只能根据具体的代码来定。
比如：美剧《豪斯医生》里有一集，怀疑病人心肺有问题，就让病人去跑步机上跑步，加重心肺负担，从而放大症状。
4. 二分法定位，把程序逻辑一点点注释掉，看看还会不会出问题，类似二分查找的方法，逐步缩小问题范围。
5. 模拟现场，有时候我会问自己，如果我要实现bug描述的现象我要怎么写代码才行？
比如：我遇到一个死锁问题，但是检查代码发现所有的锁都是配对的，没有忘记解锁的地方，而且锁很简单就是一个普通的临界段，保护几行赋值语句而已。这样的代码怎么写才能让他死锁呢？
我想如果让我故意制造这样一个现象，只有在上锁的时候强制杀掉线程了。
既然这样就可以去看看有谁强杀线程了没有。
6. 制作工具，针对某些bug编写一些调试辅助工具。
比如，我那个系统没有完善的崩溃报告，虽然也有dump，但是分析出来的callstack经常不准。于是我为解决崩溃问题编写了个工具，会自动扫描代码，在每个函数入口和出口插入log，以此来定位崩溃点。
7. 掩盖问题，虽然这样做有点不厚道，但是有时不得不这么做。有些bug找不到真正的root cause，但是又要在规定时间内解决，那么我们就可以治疗症状而不去找病因。比如用try catch掩盖一些奇怪的崩溃。不到万不得已不要这么干，未来可能会付出更大代价。
我觉得这对于我们这些编程新手而言都是个很好的办法，解决bug是一件任重道远的事情，且编且珍惜。