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?

回复 发表人 东 郭 发表于 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 文件里, 支持导出和导入平面文件

深度内容

和Google互补的搜索引擎Wolfram|Alpha

Wolfram|Alpha与Google究竟是什么关系,Wolfram|Alpha自己是如何定位的?Wolfram|Alaph在多大程度上是语义网搜索呢?InfoQ中文站就等等这些问题采访了Wolfram研究公司中国区商务经理王翔。

SOA契约成熟度模型

本文说明了所推荐的契约版本管理设计策略是如何与SOA成熟度模型发生联系的。文章目的是为实现版本管理和可组合性提供一个路线图。

数据服务简介

Vijay Narayanan在这篇文章中对数据服务的几个方面进行了介绍,它们都是SOA实践者和数据架构师感兴趣的内容。本文对数据服务的几个方面进行了介绍,包括需求定义,基本原理和好处、范围、开发以及消费模式。

分块云计算

在本文中,Jimmy Nilsson描述了一种他在过去数年间观察到的一种正在缓慢成长的架构风格,他把这种风格称为“分块云计算”。

豆瓣网技术架构变迁

罗马不是一天建成的,豆瓣的技术架构也是随着用户规模的增长一直在持续变化中。在本次演讲中,豆瓣的首席架构师洪强宁将与大家一起分享从上线时的单台服务器架构开始一直到现在的豆瓣架构变迁历程。

融合思想:深入探索S#arp架构

Billy McCafferty展示了S#arp架构,它在ASP.NET MVC框架的基础上,荟萃了当今的最佳实践,应用在ASP.NET Web应用程序的架构设计中。

王雷谈开源以及新兴市场计划

中国作为新兴市场中的新兴市场,是Sun在美国之外实施SSE(SUN Startup Essentials)项目重点关注的地区。在QCon Beijing 2009期间,InfoQ中文站有幸对此项目的负责人王雷先生进行了采访,探讨了关于开源、新兴市场、SSE等话题。

使用HTML5构建下一代的Web Form

HTML5 是由 WHATWG发起的,最开始的名称叫做Web Application 1.0,而后这个标准吸纳了Web Forms 2.0的标准,并一同被W3C组织所采用,合并成为下一代的HTML5标准。