大规模视频网站的计费与流量管理
本次分享将会就大规模视频网站的计费与流量管理这个话题，从操作层面细细进行讲解和分析，为系统工程师们揭示平日里我们没有关心的另一些内容。同时也希望本次分享能揭示行业中的一些“潜规则”，让互联网行业的流量与带宽管理更为开放与简洁。
本次演讲视频录制于QCon杭州2011。
文章
该内容已经被标记书签！
标记书签错误，请重试！
领域专用语言(DSL)迷思
作者 徐昊 发布于 2008年6月10日
所谓领域专用语言（Domain Specific Language/DSL），其基本思想是“求专不求全”，不像通用目的语言那样目标范围涵盖一切软件问题，而是专门针对某一特定问题的计算机语言。DSL之于程序员正如伽南地之于以色列人，是最初也是最终的梦想。几乎自计算机发明伊始，人们就开始谈论DSL使用DSL了。而前几年随着被誉为“Web开发领域专用语言”的Ruby on Rails迅速走红，DSL又一次成为人们讨论的热点话题。很多人都认为，DSL将会是软件业的“next big thing”。然而随着DSL的日益流行，围绕着DSL出现了很多质疑和误解，比如下面这几个：
相关厂商内容
DSL的目标受众是非程序员，业务员或者最终用户
在很多人的心中，DSL等同于“非程序员的编程语言”(programminglanguage for non-programmers)，因此DSL的最终受众应该是非程序员，一切不直接被最终用户使用的DSL都不是真正的DSL，仅仅是另一种使代码看起来不像代码的无聊技巧。
这是一个很有趣的观点，事实上在计算编程语言发展的历史上，的的确确出现过“非程序员的编程语言”，而且还非常有名，它们就是FORTRAN、COBOL等这些第一代高级语言。在当时的那个时代，计算机的主要目的是科学计算，而程序员则是专指那些摆弄开关、继电器、纸带以及汇编语言的geek们。而计算机的主要非程序员受益者——也就是那些学者和研究员——不得不委托这些人帮助它们完成从数学公式到机器指令的转换。于是第一代高级语言的主要目的是缩短计算公式和可执行的代码之间的差距（比如Fortran），或者是简化信息管理员的日常工作（比如COBOL）。有趣的是，恰恰是这些当年的“非程序员”把软件开发发展成了一门正当且颇为体面的职业。
其实当年的“非程序员的编程语言”与今日的DSL境况颇为相似，所不同的是，当代企业级信息系统更为复杂，所关注的焦点逐渐从计算转移到数据上，业务领域和计算机的物理过程也不再具有简单直接的对应关系了。而且随着社会分工细化，就算是通过DSL，我们仍然不太可能把那些衣冠楚楚的HR们、销售们和部门经理们统统拉下水变成新新程序员。
我仍然要承认，以最终用户为目标受众的DSL是一个很引人侧目且很有意思的主意，但是在相当长的一段时间内都是不太现实的。或许我们需要新的方法（比如精益）来协调IT部门和业务部门，或许我们需要全新的软件工程理论，或者某些非常具有独创性的工作方式。谁知道呢，预言未来总是吃力而不讨好的，但我觉得在目前情况下，简单把DSL的受众限制在非程序员，业务员或最终用户上，是值得商榷的。
DSL = 整洁的代码
这种观点与前面的观点正好相反，把DSL完全当作程序员的游戏，把一切能将代码写得整齐好看的技巧都归结为DSL。
虽然从形式上看DSL和“整洁的代码”都具有简洁清晰的特征，但并不能因此将简单将两者草率地归为等同。从概念上说，程序的编写过程就是把业务领域中的问题通过代码或者程序模型表达出来：
由于计算机的程序模型较为单一（归根结底都是运算和存储），就算是在面向对象技术成为主流的今天，通常情况下，计算机程序不太可能做到与业务领域中的概念一致，或者具有某些直觉的对应。也这正是因为这样，软件的修改和可维护性并没有想象中的容易。我们必须不断地将业务领域中的概念转换成相应的代码模型，然后再进行修改。这种间接性直接造成了软件的复杂度。
而DSL的主要目的就是要消除这样的复杂度（或者说，以构造DSL的复杂度代替这种复杂度），DSL就要是要以贴近业务领域的方式来构造软件。因此，DSL的简洁性往往是一种思维上的简洁性，使我们不用费太多的气力就能看懂代码所对应的业务含义。
从这里我们可以看出DSL和“整洁的代码”的根本不同，“整洁的代码”只是泛泛地要求代码简洁易懂，而不太在意是否贴近业务领域。比如对于一个J2EE开发者来说，DAO、DTO、FormBean和Action已经足够清晰了，但是这却跟DSL沾不上一丝的关联。DSL更注重强调使用业务词汇，尽可能贴近业务模型来编写代码，使业务模型和程序模型之间具有简洁的对应关系。
因此我们不能将DSL等同于“整洁的代码”，只能说DSL是一种“整洁的代码”而已。
DSL必须以文本代码的形式出现
Domain Specified Language，顾名思义，是一种语言，因此DSL一定是文本代码形式出现的，不是通过文本代码描述的就不是DSL。
我们之所以偏爱使用文本代码，主要是由于文本代码易于修改且修改效率极高。多年来软件工程实践表明文本代码是最有效率的编辑形式。但是对于DSL，问题则有些不同。
正如我们前文所说过的，DSL首要的目的，是使程序尽可能地接近业务领域中的问题，从而消除不必要的间接性和复杂性。对于大多数业务领域而言，文本代码的形式一经足够好了，我们可以很容易通过特定格式的文本，描述业务领域中的问题。然后也确实存在着一些较为特殊的领域，在这些领域中，文本代码并不是最佳的表现形式。为了更好的贴近业务领域中的概念，我们可能会选择使用一些图形化的DSL。比如时下颇为流行的一个DSM（Domain Specific Modeling）工具GEMS（Generic Eclipse Modeling System）中就大量地使用了不同的图形化的DSL来表述系统的各个不同侧面。所以我们并不能简单的把DSL局限在文本形式上面。
DSL的语法应该尽可能地接近英语或者其他自然语言
由于大多数DSL是描述性的，因此我们应该尽可能地让DSL接近日常使用的英语或者其他自然语言，这样可以增强DSL的表现能力。
业务自然语言（Business Nature Language）是DSL的一个重要分支。它的产生是基于这样的一些事实：对于大多数企业应用而言，使用一些类似自然语言的语法和结构构造DSL是不错的选择；通过业务自然语言，可以推动和促进业务人员和程序员之间的沟通；类自然语言的DSL相较其他形式的DSL重用起来较为容易。正是由于上述这些特点，BNL类DSL在DSL的实践中是最流行的。我个人就曾在三个不同的项目里实现了针对不同领域的BNL类DSL，我甚至在Smalltalk语法的基础上修改提炼，得到了一种具有通用语法表达的脚本语言。利用它可以方便地构造DSL。
虽然BNL是我实践得最多也是最为喜爱的一种DSL形式，通过前文的分析，我们仍然不能把它当作唯一的DSL形式。我们必须时刻谨记，DSL的首要目的，是使程序尽可能地接近业务领域中的问题，从而消除不必要的间接性和复杂性。合理且恰当地选择语法形式永远是构造DSL的重中之重。
作者简介：徐昊，ThoughtWorks咨询师和敏捷过程教练；BJUG（Beijing Java User Group）和AgileChina主要创始人之一；RSSer（Ruby，Smalltalk & Scheme）。目前主要致力于研究编译理论和推广DSL（Domain Specified Language）在实际项目中的应用。他的博客地址是：http://www.blogjava.net/raimundox。
好文章。
发表人
kjm jessica
发表于
一个漏洞：什么是程序编写过程（problem is not solution）
发表人
Zhang Charlie
发表于
Re: 一个漏洞：什么是程序编写过程（problem is not solution）
发表人
王 辉
发表于
Re: 一个漏洞：什么是程序编写过程（problem is not solution）
发表人
gz husthxd
发表于
内容空洞
发表人
King George
发表于
Re: 内容空洞
发表人
holin he
发表于
Re: 内容空洞
发表人
霍 泰稳
发表于
Re: 内容空洞
发表人
周 志鹏
发表于
不要停留在概念上，作者是否可以再深入的探讨一下使用情况
发表人
Lee Lawrence
发表于
Re: 不要停留在概念上，作者是否可以再深入的探讨一下使用情况
发表人
霍 泰稳
发表于
Re: 不要停留在概念上，作者是否可以再深入的探讨一下使用情况
发表人
liu ozzzzzz
发表于
-
凌晨四点发帖，强。
-
徐昊 发布于 2008年6月10日 上午4时22分
从概念上说，程序的编写过程就是把业务领域中的问题通过代码或者程序模型表达出来
只说对了一半。
Problem is not Solution.
把问题表达出来只能说是问题陈述、需求描述，而程序员还必须给出问题的 solution，有的时候还是一堆 solution，这是他们的价值所在。代码或程序模型其实都只是 solution 或 solution 的一部分，而不是问题本身。
把计算机程序编写与业务领域的问题表达，Problem 与 Solution 混为一谈，是有害的。作者在这里似乎犯了一个概念性的逻辑错误。
需求分析专家 张恂
www.zhangxun.com -
一直对DSL很感兴趣，但是一直都没有发现特别有用的信息。看来这个标题，以为会有很多信息。结果发现很空洞。失望！
-
同感
-
关于领域特定语言的一些深入报道和分析，楼上的两位可以看看InfoQ中文站上的DSL专题，呵呵。
-
我认为DSL的关键在于，降低了开发人员和SD,最终客户之间的沟通成本。使用同一种描述性语言来对同一个事物或需求进行描述，可以最大限度的做到对需求的“保真”。
-
同感
-
我认为DSL的关键在于，降低了开发人员和SD,最终客户之间的沟通成本。使用同一种描述性语言来对同一个事物或需求进行描述，可以最大限度的做到对需求的“保真”。
这次作者徐昊在下周六（6月21日）举行的敏捷中国大会上和Martin Fowler大叔一起做一个关于领域专用语言的演讲，不知道会不会讨论一些比较深入的使用情况，感兴趣的XDJM可以前去瞅瞅。 -
见误解之一和四。
-
同意，整个开发过程都是不断的描述问题解决问题的过程。
-
solution!
11 条回复
关注此讨论 回复