大家平时都是怎么找一些很抽象的 bug 的

[billbur]

我一般靠日志和 debug 都能解决大部分 bug ，这些都没什么好说的，但是遇到一些非常规手段就能找到问题原因的 bug 就纯靠经验然后做假设再验证了。比方说之前遇到过一次数据库表的统计信息不准确导致 sql 不去走索引，后面又走索引了搞的我们查问题查的要死。 想听听大家的经验之谈，在可以分享的范围内细说，学习学习

[SuperManNoPain]

无他，唯手熟尔

[imboring]

有些 bug 就是没什么道理的，我甚至用过二分法查找 bug...

[key0323]

熟悉底层知识 杜绝玄学编程

[opengps]

连续一段时间解决不了，就先放一放回头再分析

[hejiangyuan]

只要问题能重现，bug 都好处理。所以有时为了重现问题用各种暴力方法，比如用脚本频繁触发某一个操作。或模拟多个用户同时做相同的操作。之前还遇到过用户鼠标有问题，经常单击变双击导致接口调用 2 次的问题(当然也是代码没有控制好，但普通测试不容易发现)

[darksword21]

排除法，首先不是自行车

[monkeyk]

bug 哪有抽象的，bug 都是眼睛看出来的

[snipking]

你这个场景上一套 APM 就可解啊，从接口开始一直可以跟踪到 SQL 查询，排个序就能看出哪些接口在哪些参数条件下执行哪个数据库查询时间特别长

[EastLord]

搞 APM 挺好，但是很多公司不注重这个

[povsister]

良好设计+熟悉架构+清晰的底层逻辑理解
外加无它唯手熟尔

多锻炼自己不依赖调试器定位问题的能力，当你能把 bug 锁定在某个模块内部的时候，一般目视检查就可以发现问题。

[billbur]

@snipking 正常系统慢 sql 一查就知道了，为什么慢你 explain 一下还不一定看出来，如果现场一旦丢失了的话，复现纯靠猜测，我们领导都是做技术的，第一时间来问你回答不出来真的焦头烂额

[guguji5]

让我查了 N 多小时的 bug ，原因却不复杂

http://xhslink.com/BQgTwN

[hhhh115]

全靠同事、领导

[noErr]

多斗争几次，拒绝多线程编程，解决大部分玄幻问题

[NessajCN]

bug 指代码里的问题。bug 抽不抽象取决于你的代码写得抽不抽象。所以如果遇到的代码很抽象说明自己的代码写得很抽象。代码写得抽象说明菜。
菜就多练

[darkengine]

处理用户反馈的各种非必现的奇葩问题才难受

[cencoroll]

程序使用了多数据源，开头还好，现在不知道为什么一启动就报错，druid 初始化时弹出来个不支持 hsqldb 的错误，我猜测是哪个包使用了 hsqldb 来作为内存缓存，但是根本解决不了，烦死

[wonderfulcxm]

靠运气加上执着

[fugu37]

@imboring ＃ 2

这是很常规 debug 方法

[seeyourface]

@hejiangyuan 罗技：那必须是我了😀