Bug
无论是对于测试还是开发
来说，应该都不陌生，虽然我们经历的大部分
bug有的被其他人修复了并且在
互联网
分享出来了，这时候我们通过
Stackoverflow、Baidu、
Google
等搜索引擎找到答案了。
但是我们在工作中也可能会遇到一些疑难的
bug，这里bug我们在搜素引擎上找不到解决方案，可能好几天都不得其解，这些迟迟没有解决的bug往往搞得人焦头烂额。
那作为一个苦逼的程序员，究竟碰见过哪些高难度的
bug呢？
下面，我们来看看他们与
bug的故事。
程序员小罗：
写
JS，自己手机没电了，拿同事老张的安卓机调试，很简单的获取用户微信昵称，结果死活获取不到，一直显示为null。应该是跨平台问题，因为之前在自己iPhone上是没有bug的，拼命看api文档，但是都没提到这方面。急死我了。
……刚刚老张告诉我他的昵称就是null。……老张已被打死……前面夸张修辞，老张最后当然没死，腿打断了而已。
电商行业程序员小马哥：
也谈谈自己遇到的一个
bug吧，我之前是做电商的，某较大的电商平台，突然有一天，C2C的店主反馈，看到的订单不是自己的，看到后台的商品列表也不是自己的。
当时在睡午觉，看到这个问题，立马吓醒了，平时
5个投诉就是一个故障单，那还都是一点体验上的小问题，这种订单混乱，商品混乱的错误，真是要紧急死了
于是，主管，总监都来看这个问题，一群大佬在后面看着，赶紧找最近几天的发布，测试情况，一个个回退，一个个检查，最后都无法解决问题，要知道时间一分一秒过去，半个小时还解决不了就要出大事了
后续又有用户来投诉，直接电话联系，远程控制电脑，发现操作起来巨慢，于是顺口问了一下用户的网络是什么网络。
结果他说是：
“某城宽带”，一瞬间，有点感觉了，继续问其他几个投诉的客户都是“某城宽带”，然后我们打电话到那个宽带的运营商，得到的回复是“年底了，为了省流量，他们做了一部分缓存”
他们做了缓存做了缓存
……
缓存
……
存
……
可是为毛
TM的动态请求还做缓存啊，修改商品和订单的时候，随机返回成功或者失败 ……
1.这个和时间戳也没关，我们都加了token的，他们也忽略了
2.
你没猜错，他们把
POST和GET动态请求也缓存了，就是说你提交了一个POST修改商品的请求，他从环缓存里面随便丢个回复给用户，用户感觉修改成功了，其实请求根本没到我们这边
，
是的，就是这么丧心病狂。
系统管理员老王：
从前
我是个
系统管理员，平时去机房登录服务器时都是站着操作。有一次腰疼，搬了个凳子坐在了机器前面，完蛋，死活登录不进去，提示密码错误。于是
我
站了起来，重新输入了一次密码，进去了。
后来
我
觉得奇怪，于是抽时间做了测试，发现：只要一坐下，就密码错误，站起来就好了。
这个
Bug 在
我
的职业生涯中持续了好几年
，一直以为是什么灵异事件。
直到有一天公司升级设备给
我
换了个键盘。原来是老键盘上有两个键装反了，站着打字是看着键盘，坐着盲打就错了
，真的是很无语啊
……
海外程序员
Steven：
曾经听说过一个让人目瞪口呆的
bug，分享给大家。
该
bug发生于麻省理工，当时其系统管理员接到统计系主任的求助电话，主任在电话中说：“咱们的邮件系统无法发送距离 500 英里以外的地方，准确地说好像是 520 英里。”
此时的系统管理员内心是
“毫无波澜”的，嗯!
然后，他开始了漫长且苦逼的测试，最后发现邮件服务器操作系统
(SunOS)被人更新了，因为操作系统发行版往往配备旧软件，因此邮件软件实际上是被降级了(Sendmail 8 -> Sendmail 5) ，最后的结果是：Sendmail5 试图解析Sendmail8 的配置文件。
所以，为什么一定是
500 英里呢?且看大神讲解：
原因是这样的，
Sendmail 5面对陌生的配置文件，凡是不理解的部分都会忽略，凡是没设置过的配置项自动设置成0。这样其中有一个被设置成0，只一向就是（连接远端SMTP服务器的超时时间）timeout to connect to the remote SMTP server。后来经过实验，发现0秒的timeout会导致Sendmail在3毫秒后中断连接。
所以，你会问为啥是
500miles？
在当年，
MIT的校园网是没有那么多router的，也就没那么多网络延迟，所以连接一个远端主机的时间大概是光所需的时间。于是3毫秒，就意味着：
0.003*3*10
8
*0.001*0.621=558.9000000000001
558英里。也就是588英里以外的服务器，都无法连接到，而588以内的服务器，都可以正常通信。
面对这些各式各样难调的
bug，那
程序员如何快速高效的改
bug
呢
？
先根据情况试一下下面的步骤：
1. 换个环境试试
2. 换个用户试试
3. 换个操作方式试试
4. 换一下数据试试
5. 换个浏览器试试
6. 换个版本试试
根据上的情况搞清楚下面这几个问题：
1. 这个BUG什么情况下出现？什么情况下不出现？两种情况的区别在哪里？
2. 这个BUG之前没有，现在出现了，中间都动了什么？
3. 这个BUG生产环境出现测试环境不出现，两个环境区别是什么？
4. 同样的功能，这样操作没有BUG，那样有BUG，两个操作的区别是什么？
这些问题搞清楚了，先尝试采用代码回退、配置调整、环境替换等方式验证
BUG是否会消失，然后再找其中的原因。
下面列出一些常见的疑难
BUG类型以及每种BUG的诊断方法：
1.
输出结果与预期不符，
这种
BUG一般都是由于代码逻辑错误造成的，如果能在开发环境重现，最好解决方法就是单步调试，设定每一步代码的预期结果，然后跟踪判断实际结果是否与预期结果一致
。
2. 系统异常报错，
这种情况下需要提取日志，找出错误堆栈信息，这时候最重要的事情是要把堆栈信息看懂、看完整
，
而且往往堆栈信息是一个套一个输出的。
3. 系统Crash，
这个问题常见的原因是负载过高、并发过高、或者配置错误。最常见的就是内存溢出。这时候要首先排除配置错误的原因，主要靠查看
Crash Log来分析原因，
再
排查硬件、内存、网络等方面的设置，看是否有配置错误的地方。再找不到就在测试环境用开发模式进行压测和调试。
4. 系统响应缓慢
，这种问题一般是存在资源竞争或者系统资源不足的情况，先检查服务器内容、
CPU、网络情况，如果服务器压力过大，排查应用系统负载情况是否异常，如果这些数据都正常，就需要排查代码中的性能瓶颈。特别需要留意依赖第三方接口的情况，比如同步的方式发送邮件、发送短信、写文件等。
总结：
bug千奇百怪，不是每个bug都需要经历所有流程的。每个步骤都有它的难点。
有些
bug难在事发点的定位，比如多线程，异步逻辑中的bug；
有些
bug难在原因很难分析，多数是你看不懂代码；
有些
bug难在你不敢改，那是你的修改方案没有做好充分的分析。
