你会使用Code Bubbles吗?

时间:2010-03-15 03:40:36

标签: ide developer-tools

我看过this question提及Code Bubbles,我看了他们的视频演示。

视频令人印象深刻,看起来确实有点未来感,但显然它有点真实。

但这让我一直在想......开发人员真的会使用这样的工具吗?

作为开发人员,我们习惯于处理代码文件,以某种方式在目录中组织它们,一些常见的IDE(对于那些拥有它们的语言)。

使用像Code Bubbles这样的东西将是一个很大的飞跃,正如他们所建议的那样。

我个人而言,我不确定我是否可以在这样的环境中工作......虽然我认为我只需要一些调整......但我真的没有看到我的想法解决它的问题。

您对此有何看法?

16 个答案:

答案 0 :(得分:27)

我会在心跳中使用它。无论如何,我总是希望以这种方式工作。

在我第一次创建目录时,我只考虑目录结构的事情:之后我总是想通过思路而不是文件来工作。

答案 1 :(得分:17)

对于像C#和Java这样的语言,其中代码文件和块(方法等)的实际组织相当严格(在Java中比C#更是如此),那么提供代码的新“视图”的东西可能会起作用。您可以允许该工具组织您的代码,每个文件包含一个类,按可见性排序的方法,或您想要的任何编码标准,并且该工具可以以某种方式处理它,以至于有人仍然可以看到“原始” “文件并理解这一切。

对于像C ++这样的语言,你基本上可以做任何你喜欢的事情,这将是一个问题......

答案 2 :(得分:6)

以这种方式思考......更容易:

(1。)要有代码气泡,您可以在同一视图中查看彼此调用的一系列函数

-OR -

(2。)在这些函数之间不断地来回切换,分布在6个或7个源代码文件中,在一个文本编辑器中?

我会使用代码泡泡吗?如果MS在未来几年内没有推出VS等价物,我可能会突然对成为Java开发人员产生浓厚的兴趣。

答案 3 :(得分:5)

我认为这是一个令人印象深刻的创新概念,我迫不及待想要尝试一下!

除了从存储的文件中独立查看代码的绝妙想法之外,我发现最有趣的是“迷你地图”式条形图,它显示了您的气泡布局的缩影,让您立即滚动或定位您在特定区域的“桌面”。

这是在操作系统级别实现虚拟桌面的方式!

答案 4 :(得分:3)

真正的程序员使用文本编辑器。 :)

不用说,我喜欢Code Bubbles,但是切换它需要的不仅仅是一个新的GUI。

将代码气泡链接在一起并将它们作为一个组移动的想法似乎有点愚蠢,在大多数实际情况下可能没用。

我认为所有程序员都可以通过图形方式看到他们的应用程序在屏幕上占用空间,而不是占用(不太可见)空间作为文件中的行。仅此而言,我认为它作为演示工具非常有用,如果不是作为编程环境。

答案 5 :(得分:3)

对于那些感兴趣的人,Microsoft Research也在为Visual Studio做类似的事情。它被称为Code Canvas。

您可以在此处了解详情并观看视频:http://blogs.msdn.com/b/kaelr/archive/2009/03/26/code-canvas.aspx

关于原始问题,我在发现Code Bubbles后立即注册了测试版。我认为它有一些非常好的想法,并想尝试一下。即使事实证明它不像他们声称的那样有用,但我确信其中一些概念将演变为许多程序员使用。

答案 6 :(得分:2)

我肯定会下载并尝试在可用时使用它。它看起来像一个简洁的想法,可以加快调试,代码审查和某些类型的开发。此外,代码气泡常见问题解答表示他们支持将整个文件视为大型可滚动气泡 - 因此,如果需要时可以分辨出气泡隐喻。

可能最重要的问题是我不认为除了Java之外什么都不支持。我把大部分时间花在了C上,如果他们希望这个想法真正起飞,那么多语言支持是至关重要的。

答案 7 :(得分:1)

绝对!文件结构不会影响气泡视图,因此您可以在技术上使用传统方法来组织项目源文件。这真正有用的是导航已经根深蒂固的代码。学习别人代码的必备条件。它还非常适合保持代码清洁 - 许多小而简洁的对象和函数。

答案 8 :(得分:1)

我认为它看起来不错,但对我来说,在调试/单步执行代码时看起来会更有用。没有IDE打开整个代码文件只是创建一个小代码泡沫是很酷的。

答案 9 :(得分:1)

我认为Code Bubbles打开了整个GUI桌面隐喻的想法,而不仅仅是编程。

我们所做的大部分工作都是等级制的。想象一下编写项目文档。它有标题吗?副标题?想象一下构建目录(ToC),然后单击每个标题/子标题以获得放置内容的单独窗口。您可以在不同的气泡中同时打开多个子部分。你总是可以拆分屏幕现代文字处理器来完成同样的事情,但我希望能够将这些部件移到单独的窗口,这样我就可以按照我想要的方式安排它们,而不是仅依靠应用程序来“瓦”为我的子窗口。 Code-Bubbles-as-desktop允许这样做。

想象一下,您正在协作地处理该文档。单击ToC中的子标题并开始处理它。其他人点击另一个并开始处理它。您可以使用传统锁定来避免让别人弄乱您正在做的事情,反之亦然。是的,我知道EtherPad。我用过它。它让我疯了。

我一直在考虑做一个基于wiki的文档/程序组合系统,在主系统文档中创建标题,每个标题都链接到这些标题的实际内容。不同的部分会出现在不同的窗口中,您可以根据需要进行安排。可以说,Code-Bubbles-as-desktop是一种更优雅的解决方案。

显然,这可以通过编程来完成,因为一个程序只不过是一个复杂的,非常精确的文档,并且具有非常挑剔的目标受众。程序通常是非常分层的。就目前而言,当我编程时,我正在使用Vim或Eclipse。它们都能够“折叠”我不看的代码部分,给我一个高级概述和实际代码的混合。通过使用一个气泡显示方法定义和包含方法内容的其他气泡,可以在Code Bubbles中完成相同的操作。在将它们提供给编译器之前,所有这些都将被“编织”回来。

此外,当我编程时,我通常通过在注释中放入高级伪代码来“充实”方法或函数,然后通过并填写实现每个伪代码的程序代码。那些伪代码注释可以提供ToC片段,它们会打开气泡来保存实际代码。系统需要将各个部分“编织”在主文档中。无论您使用何种编程语言,这都可以。

我对文学编程的兴趣是否足够明显?

让我们把它提升到一个新的水平。您正在使用平板电脑或上网本。您可以使用更少的屏幕空间。哦,哎呀,看看那个;气泡都比较小。使用顶部的“上下文栏”找到您正在寻找的气泡,气泡可以占据屏幕。现在,您可以使用一种方法来编写可在较小的,尺寸受限的设备上工作的文档(包括程序)。

这可能是一厢情愿的想法,但我认为这可能是一个重要的新范例,不仅仅是编程而是整个GUI。我当然会用它。

答案 10 :(得分:0)

我可以看到自己试图在这样的环境中工作,因为我始终使用我的IDE开发,我的桌面上的一些文件和一些不同的记事本/ vim打开的文件有不同的片段和不同部分的想法代码/软件。我不是说界面必须像Code Bubbles那样,但是有些东西可以实现。

...但我需要真正测试它,感受它。我认为以某种方式混合使用Bubbles和传统IDE是可行的方法。

事实是:看到人们发明尝试改进我们的开发工作方式(比如Zen Coding在Web开发中,只是为了举例)真的很有趣,即使这种方法失败了,也有一些想法可以借到其他项目。

说真的,我期待将来发生的事情是我将要使用键盘和响应式多点触控界面,在一个ide中拖动项目和代码段,同时使用设计和编程我用双手画在屏幕和键盘上:像iPad一样用于编程。

(关于YouTube上的Code Bubbles视频有一些非常好的评论,最好先查看一下)。

答案 11 :(得分:0)

我认为您工作流程的变化(以及之前的学习曲线)不会像最初出现的那样大:如果您正在使用Eclipse(正确),您已经使用Open Type(按名称)导航,打开调用层次结构,打开类型层次结构,打开声明等。折叠的代码块似乎也是代码泡沫的先驱。

我同意Codeka的看法,它可能只适用于像Java这样的“严格组织”的语言,而对于像Perl这样的东西则不太好,它为程序员提供了更多的自由,他们想要如何安排事情(牺牲了他可以期待的工具支持。)

答案 12 :(得分:0)

我会使用代码气泡有很多原因,但真正让我感到困惑的是调试。我喜欢这样的想法,当你进入一个函数时,它会为该函数打开一个新的泡泡,所以你可以查看调用函数的代码,同时看看它自己的函数,我认为这是很好的生产力。

加特

答案 13 :(得分:0)

我不能说我是否会长期坚持下去,但我当然希望在这种环境下工作几个月。

这里有一些非常有趣的GUI想法 - 这是一个鼓舞人心的视频。

答案 14 :(得分:0)

我对Code Bubbles的兴趣比一段时间以来的新概念更令我兴奋。几年来,我一直在等待代码社区开始考虑代码数据库,而不是代码文件。我认为文件隐喻已经削弱了我们的思维,并以错误的方式影响了我们的工具。

例如,为什么还有一个问题是单元测试是否应该与生产代码在同一个文件中?当然它们一起使用,但我们通常将它们分开,因为我们不希望将测试打包到.jar中。我们让构建工具迫使我们在这些被称为文件的人为工件之间反弹。 Code Bubbles是否是一个更好的比喻还有待观察,但任何让我们摆脱文件隐喻的东西都必须是一件好事。

我刚刚发现了Code Bubbles,并且发现测试版感到欣喜若狂。我迫不及待想为自己看这个。

答案 15 :(得分:0)

我对演示的印象是,我可以看到这种方法对大型程序有用。然而,在我为编程生活的14年里,我只编写了一个大型的程序(继承了更多)。

那是在我22岁的时候,我很遗憾在接下来的六年里让它变得如此单一,直到它退役。这是一个持续的维护问题,因为除了我之外没有人真正了解整个事情。