InfoQ

新闻

把代码储存到可查询数据结构中?

作者 Sadek Drobi译者 王丽娟 发布于 2008年6月27日 上午12时42分

社区
Architecture
主题
代码分析
标签
视觉化,
IDE

目前使用平面文件这一主流是否就是表示代码的最佳方法呢?Rick Minerich的帖子提倡远离这个模式,Blogspace中已经对此有所反应、出现了一些讨论。

他指出,在平面文件中描述代码不允许用最恰当的方式组织代码。函数或类在文件中的顺序、程序的文件夹组织都依赖于程序员随意的选择,并反映出他们对代码组织和其含义表达的想法。但是,“没有两个程序员的想法是完全一样的”,而且源码一牵扯到多个作者,结构就会有被修改的风险,这样在所有的层次上,文件里的代码结构、程序的文件夹结构,以及两者之间的关系都可能失去一致性。

尽管有减少这些风险的解决办法——比如将内容分散到尽可能多的文件中、划分出代码边界——但Rick Minerich认为这些解决办法仅仅部分回答了他提出的问题,因为“平面文件是问题的根源。”

此外,在一些情况下,代码的组织依照“特定任务可以有不同的排序/含义[……]”,但为每个单独的任务重新组织由平面文件描述的代码却是难以想象的。

为了回答这些问题,Rick提倡用另一种办法来表示代码:

如果你能把代码的呈现方式看作一种抽象的数据结构,那你为什么不干脆把源码本身保存在一种类似抽象数据结构中呢?程序的结构不是更像图而非列表吗?

[……]

如果我们把代码保留在可查询的数据结构中,用我们选择的任意方式来设置环境会比较容易。[……]比如说,你可以显示一个方法和一切引用它的内容。代码可视化的可能性是无限的。

[……]

远离平面文件的真正方便之处在于,我们可以选择的任意方式可视化程序结构,我们将从中获得的效率和理解。

Rick的帖子引起了很多反应。Steve Hawley分享了他的观点,还提议使用LINQ来支持查询式的代码组织方式

【在这样的组织方式下,】在编译一行代码时,断定正在处理哪些变量的过程实际上是一种数据库查询,这一点给我留下了深刻的印象。作用域及其语义都是查询(以及数据库结构)的一部分。

另外,完成编译的实际链接(无论该链接是在构建时还是在运行时完成的)又是一个查询。

编译的过程实际上就是构建一个数据库的过程。

但是,一些评论者提醒注意一个事实,即这种代码组织方式是已经存在的。比如Keith Braithwaite认为,“Rick Minerich所说的合理的结论应该是一种基于映像的(image-based)环境”,实际上在Smalltalk和Lisp中已经有这样的东西了。除了Smalltalk之外,另一位评论者给出了VisualAge Suite的例子,在VisualAge Suite中,“所有的代码都储存在一个代码数据库中[……],你可以用你需要的任何方式进行查询”。

然而,Steve Hawley和其他几个博客强调不应该否认使用平面文件的好处。平面文件有利于浏览代码,因为人类“很在意空白和事物的相对位置,平面文件能很好地满足这种要求”。人们能“建立起对布局的熟悉,下意识就能非常高效地导航到文件中正确的位置”。

在Reddit上的讨论中,有一则评论主张,一些Rick Minerich认为是平面文件缺陷的地方也可以被视为优点,比如任意的结构就有其好处,因为定义结构的过程中,可以利用其灵活性来表达意图

像运算符之间的空格数量这样的东西也有很好的用途,比如连续多行意义相似的代码,可以调整空格数量让它们对齐,以凸显它们之间的关系。可以调整函数的顺序来达到叙述的效果。人们在使用手头的工具来书写有表现力的代码方面非常有创造性。如果你打算换一种代码组织形式,我希望能有一个好的理由让我相信这种替代物能达到同样的效率。

Keith Braithwaite提醒大家注意这样一个事实,远离平面文件表示也意味着告别文本编辑器和版本控制工具,而且他认为程序员还不准备付出这种代价。另一位评论者JSJ认为基于映像的格式还会使更多工具无法使用,他强调“只需构建一套工具,就能在全部(或大部分)编程语言中使用”的能力“是平面文件的一项巨大优势”。

Rick Minerich自己也提出了工具化的问题,他认为平面文件仍被使用的其中一个原因就在于,所有工具都是为用平面文件来组织代码而设计的。比如说,几乎所有的编译器都要有完整的程序代码才能编译。他相信“对于将代码保存在抽象的数据结构中这一研究来说,一种与传统编译和链接无关的语言将是理想的研究基础”。他建议对于基于查询的代码组织方式,第一步的解决办法是:

良好的第一步应该是有一个IDE或编辑器,它能在数据库中管理所有的代码,并允许程序员动态地创建查询语句来构建视图、用不同的方式操作代码。然后该环境还可以生成平面文件,以达到与当前编译器兼容。

查看英文原文:Storing Code in Queryable Data Structures?

3 条回复

回复

回复 发表人 东 郭 发表于 2008年6月27日 上午3时58分
想法很好 发表人 Junyin Wu 发表于 2008年6月27日 下午10时44分
LEO 可算是这样的 IDE 发表人 Lynx Super 发表于 2008年7月8日 下午12时19分
  1. 返回顶部

    回复

    2008年6月27日 上午3时58分 发表人 东 郭

    论题很好
    还有一个问题是文件比较直接,假设是脚本文件,紧急时候很容易更改,而存放数据库的话,你必须保证工具能使用。这和log 不存放数据库类似

  2. 返回顶部

    想法很好

    2008年6月27日 下午10时44分 发表人 Junyin Wu

    只是不一定要考虑用数据库而已,可以考虑其他的构成方式,然后提供一个可以导入导出文本文件的工具,关注中……

  3. 返回顶部

    LEO 可算是这样的 IDE

    2008年7月8日 下午12时19分 发表人 Lynx Super

    LEO 这个“文学编程工具”自身将所有东西存储在 .leo XML 文件里,
    支持导出和导入平面文件

独家内容

剖析短迭代

敏捷教练Dave Nicolette提出:我们应该如何设定迭代长度?是要根据发布周期的时间么?使用短迭代又有哪些好处?

应用JSF、Ajax和Seam开发Portlets(1/3)

本文主要讲述了如何用JBoss Portlet Container 和JBoss Portlet Bridge创建新项目,怎样配置一个JSF应用去使用JBoss Portlet Bridge,以及JBoss Portlet Bridge所具备的功能。

AtomServer:数据分发的发布动力(第二部分)

在这篇文章里,Bryon Jacob和Chris Berry将和我们继续探讨AtomServer,它是基于Apache Abdera的完整Atom存储实现。作者还创建了几个Atompub规范扩展,其中包括自动标记、批处理和Feeds聚合。

架构师(试刊第二期)

InfoQ中文站的电子杂志《架构师》试刊第二期出版了!相比于上期,我们在内容的选择安排和版式上都根据读者的意见重新做了修正。“细节决定成败”,我们希望基于InfoQ中文站的专业内容,《架构师》能逐渐成为大家喜欢的电子刊物!

一种正规的性能调优方法:基于等待的调优

在本文中,Steven Haines探讨了Web应用性能调优问题。该领域过去更像是一门艺术而不是一门科学。他提出了一种称为基于等待调优的方法,使整个调优过程更加可度量,也因此更具科学性。

Java程序员ActionScript 3入门

通常来说,改变技术路线时最艰难的部分是辨别语言语法之间的不同。这篇文章就为Java开发者提供了一份如何转向Flex基础语言ActionScript的指南。

浅谈如何创建Rails应用

本视频主要以财帮子为例,介绍了如何创建一个PV为百万级的Rails应用。其中包括:Rails应用的服务器架构、Rails Cache的优化、负载均衡的处理、Web服务器的调试、分布式解决方案、Open API的设计等等。

Alexandru Popescu谈InfoQ.com网站架构

InfoQ首席架构师Alexandru Popescu在采访中谈论了InfoQ架构、Webwork与DWR、Hibernate与JCR、Hibernate可扩展性、最新的InfoQ视频流系统和InfoQ的未来规划。