数据即代码:元驱动编程

<a target="_blank" href="http://www.coolshell.cn">coolshell.cn</a>

几个小伙伴在考虑下面这个各个语言都会遇到的问题：

问题：设计一个命令行参数解析api

一个好的命令行参数解析库一般涉及到这几个常见的方面：

1) 支持方便地生成帮助信息

2) 支持子命令，比如：git包含了push, pull, commit等多种子命令

3) 支持单字符选项、多字符选项、标志选项、参数选项等多种选项和位置参数

4) 支持选项默认值，比如：–port选项若未指定认为5037

5) 支持使用模式，比如：tar命令的-c和-x是互斥选项，属于不同的使用模式

经过一番考察，小伙伴们发现了这个几个有代表性的api设计：

1. getopt()：

getopt()的核心是一个类似printf的格式字符串的命令行参数描述串，如上面的”ac:d:”定义了”a”, “c”，”d”3个命令行参数，其中，a是一个标志符不需要参数，”c”和”d”需要跟参数。getopt()功能非常弱，只支持单个字符的标志选项和参数选项。如果按上面的5点来比对，基本上只能说是勉强支持第3点，其他几项只能靠程序自己来实现了，所以，想直接基于getopt()实现一个像git这样复杂的命令行参数是不可能的，只有自己来做很多的解析工作。小伙伴们看过getopt()之后一致的评价是:图样图森破。

2. google gflags

小伙伴们看了后不由得感叹“真心好用啊”！的确，gflags简单地通过几个宏就定义了命令行选项，基本上很好的支持了上面提到的1，3，4这几项，比起getopt()来强多了。对于类似cp这样的小命令，gflags应该是够用了，但要达到git这种级别就显得有些单薄了。

3. ruby commander

接下来小伙伴们又发现了ruby commander库：

commander库利用ruby酷炫的语法定义了一种描述命令行参数的内部dsl，看起来相当高端大气上档次。除了上面的第5项之外，其他几项都有很好的支持，可以说commander库的设计基本达到了git这种级别命令行参数解析的要求。只是，要搞懂ruby这么炫的语法和这个库的使用方法恐怕就不如getopt()和gflags容易了。有小伙伴当场表示想要学习ruby，但是也有小伙伴表示再看看其他库再说。

4. lisp cmdline库

这是神马浮云啊?括号套括号，看起来很厉害的样子，但又不是很明白。看到这样的设计，有的小伙伴连评价都懒得评价了，但也有的小伙伴对lisp越发崇拜，表示lisp就是所谓的终极语言了，没有哪门语言能写出这么不明觉历的代码来！小伙伴们正准备打完收工，突然…

5. node.js的lineparser库

天啊！？这是什么？我和小伙伴们彻底惊呆了！短短十几行代码就获得了上面5点的全面支持，重要的是小伙伴们居然一下子就看懂了，没有任何的遮遮掩掩和故弄玄虚。本来以为ruby和lisp很酷，小伙伴们都想马上去学ruby和lisp了，看到这个代码之后怎么感觉前面全是在装呢？有个小伙伴居然激动得哭着表示：我写代码多年，以为再也没有什么代码可以让我感动，没想到这段代码如此精妙，我不由得要赞叹了，实在是太漂亮了！

小伙伴们的故事讲完了，您看懂了吗？如果没有看懂的话，正题开始了：

设计思想和具体技术的区别在于前者往往可以在不同的环境中以不同的形式展现出来。比如，熟悉函数式编程的程序员在理解了纯函数的优点后即使是用c语言也会更倾向于写出无副作用的函数来，这就是函数式思想在命令式环境的应用。所以，理解lisp思想一定要能在非lisp环境应用，才算是融汇贯通。

如果真正理解了lisp的本质，那所谓的“数据即代码，代码即数据”一点儿也不神秘，这不就是我们每天打交道的配置文件吗！？如果你还不是很理解的话，我们通过下面几个问题慢慢分析：

1) 配置的本质是什么？为什么要在程序中使用配置文件？

不知道你是否意识到了，我们每天都在使用的各种各样的配置本质上是一种元数据也是一种dsl，这和lisp基于s表达式的“数据即代码，代码即数据”没有本质区别。在c++、java等程序中引入配置文件的目的正是用dsl弥补通用语言表达能力和灵活性的不足。我知道不少人喜欢从计算的角度来看到程序和语言，似乎只有图灵完备的语言如c++、java、python等才叫程序设计语言，而类似css和html这样的东西根本不能叫做程序设计语言。其实，在我看来这种观点过于狭隘，程序的本质是语义的表达，而语义表达不一定要是计算。

2) 配置是数据还是代码？

很明显，both!说配置是数据，因为它是声明式的描述，能方便地修改和传输；说配置是代码，因为它在表达逻辑，你的程序实际上就是配置的解释器。

3) 配置的格式是什么？

配置的格式是任意的，可以自己定义语法，只要配以相应的解释器就行。不过更简单通用的做法是基于xml、json、或s表达式等标准结构，在此之上进一步定义schema。甚至完全不必是文件，在我们的项目中配置经常是放到用关系数据库中的。另外，下面我们还会看到用语言的literal数据作为配置。

4) 业务逻辑都可以放到配置中吗？

这个问题的答案显然是：yes！我没有遇到过不可以放入配置的逻辑，只是问题在于这样做是否值得，能达到什么效果。对于需要灵活变化，重复出现，有复用价值的东西放入作为配置是明智的选择。这篇文章的主要目的就在于介绍把主要业务逻辑都放到配置中，再通过程序解释执行配置的设计方法，我称之为：元驱动编程(meta driven programming)。