寻找触发条件，正所谓百分之百复现的bug都是好bug，百年不遇的bug都是上帝的恩赐。修改bug之前首先要找到bug，与测试、客户沟通，现场试验、还原数据库，模拟运行环境等等动用一切力量，不惜一切代价找寻bug的触发条件，找到bug触发条件就说明修改bug已经成功一半了（PS：此处可能会有惊喜，没准不是你写的代码有问题，是运行环境、硬件设备等问题）。
在调试前还需要先收集对调试有利的信息，比如log日志等，这样就比较容易快速定位到bug位置，可以起到事半功倍的效果。接下来就开始调试代码，如果有log日志就可以直接定位到错误的代码行debug下，根据错误信息修改bug，如果没有log日志，那么就准备持久战吧。
首先可以利用二分查找法，这里多适用于多表联查sql语句中使用，当然代码也可以，也就注掉一部分代码或者几个关联表，慢慢找到有问题的代码块或数据库表，找到出问题的症结点。这个方法适用于不明确bug出现在哪里，效率颇高。
接下来就是断点调试了，debug的出现使程序员减少了很多负担，寻找bug效率大幅度提升，debug可以使我们思路清晰，步步为营，如果代码有问题，debug一定会捕捉到，正所谓不会debug的程序员不是好程序员。
当然还有种业务逻辑错误的，对于我们来说可以试试了解下业务逻辑，然后和代码对比，看看哪里不一样，还有高手们是可以直接在业务逻辑中发现错误的。
还有一部分比如历史遗留bug，我们是修改bug的，改的同时还要挖新的坑，补丁、版本都是上古时代的代码，这种千疮百孔的程序，我们在时间上允许的话可以重写。重写代码同样适用于逻辑不是很多、业务简单的程序中，往往重写比修改效果更好。
最后就是终极调试大法：小黄鸭调试法（又称橡皮鸭调试法，黄鸭除虫法，传说中的大师都是随身携带小黄鸭的，遇到bug就向小黄鸭解释每一行代码的用处，可能讲到一半就灵光乍现，bug灰飞烟灭。通常就是你遇到bug解决不掉就向同事倾诉，刚说到一半突然就发现问题出现在哪里了，回去修改bug留下一脸懵逼的同事在风中凌乱。但是在程序员中，同事是习惯了的，这就是小黄鸭的作用。
https://mp.weixin.qq.com/s/drCt3pNNMcLha-9HHyCYJg
