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

[mitiskysean]

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

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

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

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

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

[kayv]

我是靠单测+log 。写代码之前先想清楚，service/logic 的函数基本都有单测，要调试就加日志运行单测。

[zhuangzhuang1988]

@wuhx
相对的 windows 内核 从开始就支持 debuger
基本 windbg 和 nt 内核时同步进行的.

[ifsclimbing]

本地开发环境还可以断点，Prod 就难了，还是日志方便

[guyeu]

@also24 #33 我回顾了一下我的措辞，我觉得还是比较准确和中肯的。

楼主原话是`改 bug 的方式`，已经发现了有 bug，甚至开始尝试定位，这种情况下断点调试的效率很高。

我从没有说断点调试是优于日志的 debug 方式，只是在改 bug 的时候效率更高。

楼上有很多人认为日志有助于提高系统的可维护性，很大程度上日志有变量监视器和注释的作用，我也并没有否认，我只是说，放弃使用调试器，想要单凭日志来 debug，甚至追求那些所谓的`额外收益`，是一件南辕北辙的事情。

我看到有位仁兄 @ybw 觉得调试要一行一行看，觉得很难定位到一个问题存在的范围，可能代表了某些人的想法。可是能知道在那个地方添加日志，怎么就想不起来在那个地方下断点呢？断点相当于一个运行期间可以随时修改，完整打印所有变量内容甚至堆栈细节的日志，所以说 debugger 的效率比查日志高。

而你所说的，基本上是废话，每个人都知道日志不可或缺，甚至在有些场景是唯一的方案。对代码熟悉的人，可以更精确的下断点，但只看日志就确定问题的人，一定熟悉代码。

查 bug 的常规思路，知道某个地方有 bug，然后开始浏览日志试图定位问题，可能 40%的 bug 就能看出来了。看不到问题，开始复现 bug，剩余 90%以上的 bug 都是可以复现的，对可以复现的 bug 而言，断点调试是效率最高的调试方式了，剩下的 bug，属于疑难杂症，需要结合各种手段。

而你所谓`日志为主的处理思路`，对真正的疑难杂症毫无作用，所谓的`整体性`，是以程序运行的效率为代价的，`更多额外的收益`只是臆想，任何应用广泛的软件设施，对日志的使用都是很克制的。

[hantsy]

几乎没用过 Debug 。
1，实在不会用 IDE 的 Debug 功能
2，一般项目都要求写测试，一般的问题都是可以在测试中消除。
3，必要的跟踪日志不可缺少，项目一开始就会有要求

[p1gd0g]

debug 是啥，单元测试吗？
俺司都是用日志来查问题，为了方便，昨天俺刚把 pkg/errors 塞进项目里。

[NeinChn]

加日志只能解决一小部分问题
如果你用了别人的库，你还能加日志？中间过程就不 debug 了么，只看输入和输出有时候又解决不了问题
要是只会做黑盒调用那出问题就。。。

[crayygy]

offline 的情况下，log 是唯一的 debug 工具

[learnshare]

日志比较方便，也很直观，但要求有代码，而且对代码十分了解
Debug 一般针对摸不透的问题，逐步查找分析

[wangxiaoaer]

Bug 分很多种，业务逻辑的通过日志排查是个好办法，但如果是计算问题，难道还很有对象都重写 tostring 输出吗？这种情况明显 debug 更直观

[zhuangzhuang1988]

现在流行，反智么

[yingo]

那调试日志程序的 bug,该怎么办....

[souths]

并不冲突

[liprais]

不打日志有 bug 都发现不了

[nicebird]

做后端分布式系统的，没见过靠调试能定位好问题的。

[laminux29]

所以那个人到了 40+也只能呆在跳动字节的一线而已，因为他根本没考虑以下问题：

1.如果程序崩溃时，连日志组件也没能记录下，怎么办？

2.如果需要行级别的日志，才能找到问题，那前期开发时，如何进行日志输出？每一行代码就写个 Log()？

3.如果需要进行调试的地方，数据量极大，导致如果全部日志，会成为性能瓶颈。如果不全部日志，输出粒度又会造成关键信息不足，那怎么办？


真正的高手，会根据情况，来判断到底如何调试，通常是日志与调试进行两者结合。而不是拍脑袋觉得某种一定更好。

[yunlzheng]

个人习惯是如果线上有问题，会尽量通过单元测试的方式在本地复现。 既可以保证本地效率，写好的测试还可以避免问题的出现。

[hoyixi]

这是常识。

某些系统架构下，或者产品自身特点，很多 bug 是客户那里操作运行产生，比如客户跨国、客户自己部署你的产品，你作为开发，怎么 debug ？标准方式就是除了详细描述 bug，还要让客户把运行日志发给你分析。

为啥很多软件开发基本流程和基本常识，现在的从业者都不知道？ 因为自从互联网泡沫以来，很多 IT 从业者，说好听点，在互联网公司上班，实质都在软件作坊里干活罢了。 没流程，烂管理，全靠加班。

[zhuangzhuang1988]

@hoyixi c++, c#的话
windows 上的 dump 文件了解下
可以记录 进程里的各种 dll,
当前系统各种信息, 堆栈信息, 日志文件只能看到 when, 不能知道 why.
而且 在复杂的客户环境下 exe 被各种注入了.

[hoyixi]

@zhuangzhuang1988 #59
我知道可以利用 dump 来 debug，但是并不是一定会 dump，定位逻辑错误还是日志更便捷。