Hang

少有人用的 debugger

2019-05-06

不知道别人是怎么认为的,我之前一直认为,Debugger 应该是一个正统的解决软件问题的方式。我们应该尽力地去多用这种方式,通过各种其他的 print 等方式是一种原始的,偷懒的,笨拙的方法。

我也总是去尝试学习各种 debugger 以及在工作中去使用它们,但都是很难进行下去。真实的工作场景中也鲜有人用 debugger。是大家都在逃避问题,投机取巧吗?

今天看的几篇文章让我明白了,debugger 并不是什么正统,而是一种适用范围非常狭窄,应该尽量少用的方式。用 print 之类的笨办法是应该的,值得推荐的。

Linux 在邮件列表里表达的对于在内核开发中使用 debugger 的看法也很适用于通用软件的场景:

It's partly "source vs binary", but it's more than that. It's not that you
have to look at the sources (of course you have to - and any good debugger
will make that _easy_). It's that you have to look at the level _above_
sources. At the meaning of things. Without a debugger, you basically have
to go the next step: understand what the program does. Not just that
particular line.

相对来说,debugger 本身更像是对问题的逃避,我们放弃对于问题以及代码更为细致的观察与思索,直接交给程序来一行一行校验代码的正确性。而在没有 debugger 的场景下,我们需要花费更多的时间来思考整个程序的设计,自上而下地考量整个问题以及解决的方式对不对,最终的困惑可以通过 print/system tools 等工具结合起来去校验。通过这种方式,最终对问题的解决可能并不是对于现有某些代码的修改,而是对于代码整体的重构与调整。

从开发的趋势来看,软件会变得越来越复杂,多线程、多核,分布式、微服务等等架构会越来越占据主流。这些新的软件架构在出现问题时所要求的 debug 工具是多种多样的,从最基本的代码加 print,利用监控系统, 生成火焰图等等。我们需要的是一种福尔摩斯式的纯思维逻辑的推理: 问题在哪?有哪些可能的地方引起的? 怎么去验证每一个可能?用什么工具最合适?在解决完错误之后,我们需要额外地去思考: 软件的设计是否合理?是否需要加更多的 trace 信息? 日志够不够?等等。而 debugger 在这其中扮演的角色只会越来越狭窄, 因为它在这些方面几乎没有可扩展性。

另一个问题在于语言本身。对于 C/CPP 社区来说,有 GDB 这样强大的工具可用。而对于像 Python/Golang 以及其他新兴的语言来说,并没有如此强大的 debugger。即使已经开发出了不少新的替代品,但他们无法在程序员心中有同样的地位。任何功能的缺失都无法让开发者信任这样的软件。

对于开发者来说,我觉得可以忘掉有 debugger 这个东西存在,除了本身的逻辑思维能力以及经验累积等方面的提升之外,我觉得可以关注以下的工具:

  1. service mesh
  2. 监控系统
  3. 日志系统
  4. 系统工具的组合利用
  5. 火焰图
  6. opentrace

Links#

  1. I do not use a debugger
  2. Debuggers are a wasteful Timesink
  3. Linux talk about debuggers
Tags: 架构