讨论一下改 bug 的方式，日志输出为主代替 debug 工具为主的优缺点

[mitiskysean]

前段时间和一位字节跳动开发长者，估计 40+，是个真开发长者了。底层计算系统开发负责人，佩服的是依然一线主力开发。当时聊到日常开发时，长者表示他开发过程基本上很少 debug，逻辑异常都是通过运行日志来定位。

大致原因是，通过 debug 工具单步断点调试，是非常低效的开发行为。因为一次 debug 后只解决了当前的 bug，并没有让系统更易于维护，而每次通过完善日志来定位问题，问题定位会逐渐清晰且容易。而且断点对于复杂系统调试是非常麻烦的，首先定位问题出现大致范围就很耗时，完全没有通过日志来得清晰，当然具体细节通过断点 debug 是没有问题，毕竟日志输出是整体逻辑，没有输出太多细节信息，细节处问题还是需要通过 debug 工具。

当时听完蛮惊讶的，不过后来想一下，觉得好像是这么一回事。出现问题-->输出完善清晰的日志-->定位问题-->辅助 debug 工具-->解决问题，同时完善信息-->再次出现问题....的确好像会让整个系统更为清晰。最近试了一下，自觉效果不错，只是过程感觉有点不适，总是不自觉想直接开点 debug 去调。但是从结果上，由于被调试目的驱使，输出的运行信息的确更为高效且清晰，也的确同一模块问题定位因为日志逐渐完善会加速。

不过我觉得这个方法有个使用前提：开发水平较高，bug 多是结构逻辑上的。比方说事务漏提交导致后续的问，改动通过调用某模块方法来解决。而是某个方法细节出了问题，比如某个方法资源没释放，导致另外一处的问题，那这通过 bug 通过日志定位的话，估计输出一大堆信息吧。

老铁们怎么看这个问题，业界是否已有类似的开发模式啊？

[baoyexi]

最近也在想日志这个事情, mark 一下

[nightwitch]

大系统里面日志越早实现越好。Debugger 有很多局限性，有的地方断不下来，有的比较隐晦的 bug 可能根本不知道断到哪里。细粒度的日志可以比较快的定位到异常的地方。 而且有的时候 debugger 真的很慢。。

[optional]

debugger 基本不会用啊， 除非写一个 util 工具方法。

[wuhx]

这就是为什么 Linus 一直反对给内核加调试器
https://lkml.org/lkml/2000/9/6/65

[forestyuan]

对于多线程的程序，那些线程之间交互的部分很难 debug，恐怕只能用日志了

[402124773]

windows 有个内置日志系统叫做 ETW，做的比较好，比较好用。内核和应用都可以使用。并不开源。

[xsen]

一直都是通过日志的方式。当然，对于随便就出问题（一分钟内，百分百重现），会利用 debug 调试
日志系统完善起来，可以提高效率很多的

[secsilm]

偏向日志，有目标性，后续还能持续输出，出问题好定位。但是感觉控制好日志粒度不是容易的事。https://i.loli.net/2020/03/21/HNlO9WTFKgZGido.png

[mikicomo]

能用日志不用 debug

[hallDrawnel]

debugger 感觉在刷题的时候还有用，其他地方确实是日志很好用。尤其是现在各种操作都是异步或者并发的，靠断点都没法复现。

[littlewing]

必须是日志啊，debug 是在看完日志后仍然无法确定问题时就用

[guyeu]

断点调试是很效率很高的 debug 方式，相当于在每一行代码执行之后都打日志。

日志本身也并不能让系统更易于维护，大量的日志反而会拖慢系统的性能。在关键结点准确清晰地打出易于追踪的日志是难度很高的事情，到最后往往是一百行代码几十行日志。

[raphael008]

现在都习惯去 splunk 看发生了啥啊。。。

[qiyuey]

肯定是日志

[sleepm]

打日志是最简单的 debug

[ericgui]

好消息，因为我都不会用断点，学过好几次，感觉没什么卵用，也不好用

[ybw]

@guyeu 每一行都停下，也是缺点。

[Vegetable]

debugger 真的用的很少，局限性太大了，换句话说，debugger 能做的事情，日志其实都能做

[guyeu]

@ybw #17 可以自己决定在哪一行停下的。

[ybw]

@guyeu 事实是，你不能。因为你不知道问题出在哪一行，所以你要一行行去确定。