Giles Bowkett 在《 Debugger Support Considered Harmful 》中写道:
问 Ruby 为什么没有很好的调试器支持,就像问海豚为什么没有鳃一样。Ruby 没有很好的调试器支持,是因为 Ruby 程序员不应该使用调试器。Ruby 比任何其他语言(可能除 Smalltalk 之外)都更好地支持 TDD 和 BDD。调试器支持是不能优雅地运行测试的语言才需要的。
注释:TDD 是指"测试驱动设计/开发(Test Driven Design/Development)",BDD 是指"行为驱动开发(Behaviour Driven Development)"。
这篇文章引起了很大的反响,其中有许多是来自 Smalltalk 社区。这点尤其相关,因为 Smalltalk 和 Ruby 是近亲。Cincom System 的 James Robertson ,甚至录了一段截屏视频(Sceencast),来说明 Smalltalk 调试器在进行 TDD 时的用处:
我写了一个测试,并运行它。测试失败了。我调试测试,让调试器替我创建漏掉的方法——于是我在调试器中给该方法编写代码,并再次运行它。调试器并不是一件不该过于依赖的工具:它把 TDD 提升了一个层次。
Avi Bryant——Smalltalk Seaside Web 框架的创建者,说:
Giles 忽略的一点是,你首先怎样去理解代码。要想理解代码——无论是你写的,还是其他人写的——没什么比得上调试器中逐步跟踪一遍。既然 Giles 曾经是一位剧作家,或许可以这样比喻:阅读代码就像阅读一部电影剧本。编写测试可能就像在描绘故事板(它们帮助你将最终的产品形象化)。而使用调试器就像实际观看这部电影。有了调节轮,你就可以一帧一帧慢慢看。
当你正好在试验一种新的框架,并想观察它是如何工作的时候,调试器在检测程序方面就非常棒。我喜欢一行行地跟踪。我在学习 Seaside 的时候就是这么做的,它比任何文档都更好。此外,看着漂亮的代码在你的调试器中展开,简直就像在阅读一本好书。在处理一些难看的代码时,调试器会给我展示出在我看代码时被眼睛所蒙骗了的一些东西。如果动物活着的时候就能观察各器官是如何工作的,我为什么要解剖它的尸体呢?
Ben Matasar 认为"调试器"这个名称可能是问题的根源:
我认为"调试器"这个名称让人们对它的作用产生了误解,至少在 Smalltalk 是这样。当我去年 12 月刚接触 Smalltalk 的时候,我尽力不用调试器,我的确认为它是一件不该过于依赖的工具。现在我时刻用它来作为研究代码的支撑点。事实上,我直接在调试器中编写相当多的代码,而让 Web 浏览器呆在后台,等待我发送响应。 我现在把它当作是一种方法上下文浏览器,在这里,你在调用堆栈的每一步中都有一个活动的 REPL。这样很好,因为你可以发送消息给对象,捅捅它们,然后观察它们如何对消息做出响应。
因此,传统的调试器工具允许你通过断点或者在任意时间中止执行,并允许你查看当前的状态。它与其他工具一起,帮助开发人员理解系统在运行时实际上是如何表现的——与只查看源代码相对照。同类的工具还包括覆盖工具(coverage tools)(如 rcov )、剖析器(profiler)、跟踪器(tracer)或者日志记录器(logger)。
虽然 Giles 的文章认为 Ruby 缺乏调试器支持,但我们不太确定他指的是什么。Ruby 拦截器具有调试器支持,既有用 Ruby 编写的较慢的版本,也有像 ruby-debug 这样的快速版本。JRuby 的情形也一样,快速版的方案( jruby-debug )目前正在开发当中。其他的 Ruby 实现,如 Rubinius 具有低开销的调试,也有的使用底层的 VM 调试支持。
当然,调试器实现只是一个方面——还必须有调试器的用户界面。但是这在 Ruby 领域中也不缺。所有主要的现代 Ruby IDE 都支持调试。 RDT(现在是 Aptana 的一部分)已具有调试支持多年了——最新的 NetBeans 的调试支持与RDT 源自相同的代码。Eclipse DLTK Ruby 具备调试支持,其他非 Java 的 IDE,如 Sapphire Steel 公司的 Ruby in Steel IDE 、 Komodo 等等也都一样支持调试。
你在调试 Ruby 方面又有什么经验呢?
查看英文原文: Debuggers considered Harmful?
评论