程序员如何快速高效的改 bug？改bug都有哪些技巧？

1. 这个BUG偶尔才能出现，或者只在特定的环境里面出现。
2. 不知道BUG是什么问题造成。
3. 不知道BUG该怎么下手解决。

如果遇到这样的问题可能好几天都不得其解，搞得人焦头烂额，这时候就不要左改一下，右改一下了，而是要冷静下来，先理理头绪。

先根据情况试一下下面的步骤：

1. 换个环境试试
2. 换个用户试试
3. 换个操作方式试试
4. 换一下数据试试
5. 换个浏览器试试
6. 换个版本试试

根据上的情况搞清楚下面这几个问题：

1. 这个BUG什么情况下出现？什么情况下不出现？两种情况的区别在哪里？
2. 这个BUG之前没有，现在出现了，中间都动了什么？
3. 这个BUG生产环境出现测试环境不出现，两个环境区别是什么？
4. 同样的功能，这样操作没有BUG，那样有BUG，两个操作的区别是什么？

这些问题搞清楚了，先尝试采用代码回退、配置调整、环境替换等方式验证BUG是否会消失，然后再找其中的原因。

下面列出一些常见的疑难BUG类型以及每种BUG的诊断方法：

1. 输出结果与预期不符，这种BUG一般都是由于代码逻辑错误造成的，如果能在开发环境重现，最好解决方法就是单步调试，设定每一步代码的预期结果，然后跟踪判断实际结果是否与预期结果一致，不一致的分析原因，如果在开发环境无法重现，无法单步调试的，可以采用添加输出日志的方式判断哪一步的问题。
2. 系统异常报错，这种情况下需要提取日志，找出错误堆栈信息，这时候最重要的事情是要把堆栈信息看懂、看完整。这是很多经验不足的程序员常见的问题，就知道报错了，报的什么错，这个错代表什么一概不知。而且往往堆栈信息是一个套一个输出的，比如Java里面表象上看是一个NullPointer Exception，但是如果你看到底，就会告诉你到底是什么错误引发了这个NullPointer。
3. 系统Crash，这个问题常见的原因是负载过高、并发过高、或者配置错误。最常见的就是内存溢出。这时候要首先排除配置错误的原因，主要靠查看Crash Log来分析原因，如果Crash Log没有有用的信息，就得排查硬件、内存、网络等方面的设置，看是否有配置错误的地方。再找不到就在测试环境用开发模式进行压测和调试。
4. 系统响应缓慢，这种问题一般是存在资源竞争或者系统资源不足的情况，先检查服务器内容、CPU、网络情况，如果服务器压力过大，排查应用系统负载情况是否异常，如果这些数据都正常，就需要排查代码中的性能瓶颈，可以采用profile工具或者直接输出时间戳的方式查看哪个操作占用时间最长。特别需要留意依赖第三方接口的情况，比如同步的方式发送邮件、发送短信、写文件等。

最后，如果你依然是毫无头绪，机谋用尽，那就得上我们的绝招“小黄鸭调试方法（Rubber Duck Debugging）”了。