大规模视频网站的计费与流量管理
本次分享将会就大规模视频网站的计费与流量管理这个话题，从操作层面细细进行讲解和分析，为系统工程师们揭示平日里我们没有关心的另一些内容。同时也希望本次分享能揭示行业中的一些“潜规则”，让互联网行业的流量与带宽管理更为开放与简洁。
本次演讲视频录制于QCon杭州2011。
新闻
该内容已经被标记书签！
标记书签错误，请重试！
把代码储存到可查询数据结构中？
作者 Sadek Drobi 译者 王丽娟 发布于 2008年6月27日
目前使用平面文件这一主流是否就是表示代码的最佳方法呢？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?
译者 王丽娟 王丽娟，04年大学毕业后持续从事Java EE中间件产品的开发，现在主要关注Java技术及中间件产品在云计算环境中的发展趋势和应用。
回复
发表人
郭 东
发表于
想法很好
发表人
Wu Junyin
发表于
LEO 可算是这样的 IDE
发表人
Super Lynx
发表于
3 条回复
关注此讨论 回复