专访 Coding Bubbles 创始人 Andrew Bragdon

最近 Coding Bubbles 项目悄然出现。一种新的 IDE 交互模式的理念引起了软件开发社区的关注。InfoQ 最近采访了其创始人 Andrew Bragdon 以了解项目的更多细节。

InfoQ: 在短短几天内成为开发人员关注的焦点感觉如何？比较明显的反应是什么？

哈哈，是的，该项目引起的兴奋度让人有点吃惊——我猜你也没有预料到。不过，这样的关注让我们深感欣慰，因为在过去一年半里我们付出了艰辛的劳动并在 2009 年底提交了相应的论文。

我收到了潮水般的电子邮件——事实上，还没有机会通读所有邮件（向正在等待回复的朋友表示歉意——我一定会回信的！）可能最意想不到的是我收到的各种工作邀请！很多人在等待着 beta 版，大量邮件询问 beta 版发布的时间，人们咨询是否可以提前试用一下。另外一个常见的问题是我们是否会增加对其他语言（Python 和 C/C++ 似乎格外受欢迎）的支持。

InfoQ: 您在网站上提到了气泡隐喻（bubbles metaphor），这是否意味着最初的想法来源于此？

Code Bubbles 项目最初可以回溯到 2008 年 1 月，当时我正在尝试各种想法——用笔通过桌子上的小屏幕（平板电脑）随意地注解和操作源代码。其中一个实现的想法是能够用笔圈住函数然后移动到一个浮动的气泡中。这帮助用户从代码库的不同位置抓取气泡，能够一次性查看所有需要的函数。当我完成这个功能时，我清楚地认识到代码片段的整合将有利于广泛的编码任务，从阅读和编辑到注解和协作，到调试。当时，这件事令人兴奋，因为虽然我察觉到了其潜力，但是还需要完成大量的设计和实现工作才能使功能灵活可用。

除此之外，还可以借鉴多年来的类似成果。事实上，我必须指出整合代码片段的想法不是我们的原创。最初的成果来自于 Smalltalk 环境，随后是 Squeak 环境——允许用户在浮动子窗口中打开单个函数。

从那时起，现代 IDE 软件似乎开始远离代码片段思想，更关注于基于文件的编辑。其中的原因难以说清楚，但是我认为最初的方法存在很多扩展性问题，不适合 Java。Java 代码往往语句长，难以在紧凑的空间中容纳一个函数。此外，子窗口的一个问题是需要用户管理哪个窗口在最上面，这非常繁琐，通过子窗口作为外部 UI 容易分散注意力。最后，如果屏幕布满了窗口，那么你的“空间耗尽了”。

基于前人成果基础上的 Code Bubbles 尝试解决一些扩展性问题。为了处理代码行较长的函数，我们采用开发人员认可的语法识别的断行方式实时分解长代码行。为了处理长函数，我们通过垂直省略，缺省隐藏较大的语句块。为了减少对最上方窗口的管理，我们不允许气泡重叠——相反，通过一种递归算法自动以不重叠其他气泡的方式移动气泡，确保所需的移动最小。我们也尽可能地消除气泡的黄色边沿以减少视觉混乱。最后，气泡存在于一个不断扩张的 2D 虚拟工作区，这样，如果你用完了屏幕空间，可以简单地扩展出去获得更多空间，或者移动到空间的未使用部分开始新任务。我们同时增加了很多其他功能，例如短暂缩放功能、轻量级分组和有助于扩展性的工作区任务。

InfoQ: 关于 demo 印象深刻的一件事情是你采用了气泡这个理念，并将其不仅应用方法级别的编辑工作中，还扩展到调试、代码补全、引用搜索等等。您能详细说说过程吗？

当然可以，气泡隐喻的好处之一在于它可以应用到阅读和编辑代码之外的地方。我们把屏幕上的一组气泡称为一个工作集，工作集非常利于那些经常输出多个方法或者代码位置的编程工具。例如，调试人员经常涉及分步执行跟踪，所以我们利用气泡显示跟踪屏幕，随着用户跳入、跳出各个函数的同时展示相关的内容。

目前许多开发工具存在这种输出多个方法的功能。例如，如果考虑版本化和对比区别，一组气泡可以显示更改的方法。我也看到过把气泡应用到其他工具，如性能分析工具、自动化缺陷查找工具、单元测试结果等等。因此在这些情况下，开发工具为了输出而不是用户创建气泡，但是我认为好处是类似的：可以同时看到来自代码不同位置的许多函数，无需分别浏览。

气泡也可以由用户打开一个或多个用于工具的输入。例如，我们其中一个功能允许用户在两个打开的气泡之间划一道线，而后台会在两个方法之间执行一次静态调用线路搜索并确定最短调用路线。然后，我们会打开更多的气泡以描述这种调用路线。轻量级的分组功能允许用户查询“相关气泡”，也就是说，可能以前其他开发人员设置的与某方法一起组合的各个方法。因此，我认为利用气泡作为开发工具或者查询的输入也很有意义。

CodeBubbles 界面的一个自然属性是我刚才描述的输入和输出都可以连接到一起，例如，如果用户基于某个标识查询所有引用，气泡栈将把结果显示在右侧，然后用户可以打开栈中的某个相关方法并依次执行另一个所有引用的查询，同样会显示在右侧。 此时，用户能够同时查看交互的全部历史，更易于处理这种分支性质的查询。

InfoQ: 把气泡概念应用到上述领域时遇到过哪些失败，哪些思想不适合这种理念？

好问题！我采用了一种交互式设计过程，我们设计和实现功能原型，然后找到专业开发人员得到他们的反馈，进一步完善设计。因此，虽然我不敢说实现的东西都最终会在某种程度上得到使用，但是许多功能的确经过了多次设计修订。还有许多功能基于用户的要求。

其中最主要的要求是更多快捷键支持。许多开发人员习惯了键盘，所以需要更多键盘快捷方式。我们添加了很多类似快捷键的功能，如基于当前气泡的位置弹出搜索框以方便打开新函数，查找定义，等等。

另外，最初我们没有包含用于导航和重新安排气泡的暂时缩放功能。许多用户同时要求缩小和方法的功能，缩小可以重新布置工作区，扩大可以向同事更好地展示代码。

另一个用户需求强烈的功能是将屏幕输出为 PDF 文件。许多开发人员认为这有助于记录缺陷或者与团队其他成员讨论跨越代码的功能因为他们可以打开相关的工作集，注释，然后通过邮件分享或者上传到缺陷跟踪系统中。

InfoQ: 网站提到项目基于 Eclipse 构建。考虑过将项目开源给 Eclipse 基金会吗（我在网站上没有看到版权信息）？如果作为一个商业产品，如果进一步发展？

开源该项目是我们今年的愿望之一。我还想尽快加入插件架构以支持开发人员扩展应用并更好地满足他们的需求。

目前的计划是让它成为一个免费、非营利性的系统，你可以随意下载并在已有的 Eclipse 中使用。我们当然非常希望能够与 Eclipse 团队同步合作。

InfoQ: 既然是基于 Eclipse，Bubbles 组件会支持其他语言如 Ruby/Groovy（Eclipse 支持）吗？

当然！从理论上讲，Eclipse 支持的所有语言，我们都能支持。虽然添加一项语言需要付出努力。语法感知的长句断行基于语言的解析树（抽象语法树），其他功能需要各个语言的定制。

但是我们会尽快实现！

InfoQ: 项目的下一步计划是什么？

下一步是发布 beta 版，以便开发人员能够在家里和办公室尝试使用，并提供反馈。如果 beta 版成功，那么我们将继续交互式设计过程——但是将更加灵活，我们可能推出一个新功能，然后立刻得到反馈。

目前的计划是在四月中旬发布一个部分功能的版本，然后在未来几个月随着我们添加更多功能并稳定系统来逐步扩大 beta 的范围。(顺便说一句, [厚着脸皮做广告喽], 你可以在 codebubbles.org 注册下载). 我们希望以后能够开放随意下载。

查看英文原文： An Interview with Coding Bubbles creator Andrew Bragdon