配置、脚本和编程语言

配置、脚本和编程语言，看似很不相同，其实本质上是一样的东西。这点从Ant脚本可以看出来，它基于的XML是配置所采用的流行格式。同时Ant脚本里有量，有函数，能循环和逻辑判断，已经具备编程语言的基本要素了。

程序像一个水桶，边界条件的约束就像桶边，有了边才能盛水。编程就像箍桶。但通常我们不把桶做成三维密封的圆柱体，顶上留口，以便水进出。编程也一样，为灵活性考虑，我们通常会让某些条件开放着，留待部署时配置。我们通常对这种灵活性认识深刻。

程序又可被看作是一个数学命题。命题通常先题设，再推断。程序也有像题设一样的“边界条件”，比如用什么算法，内存组织，持久化策略，具体到数据库的url。编程就是用配置、脚本或语言，为所有条件给出具体约束，最后程序才能工作。所以这三者或都可以定义为定义程序边界条件的语法集合，区别只在简单复杂而已。这说明，这三者之间并非不可逾越。它们是什么，不在于组织形式—并非XML文件就一定是配置文件，而在于语法集合本身—如果希望用配置定义像算法内部实现一样复杂的流程，那么配置就会变成复杂的编程语言，即便它以XML的形式组织。

所以在实践中，有必要时时保持警惕，避免把配置定义得过于复杂。我曾经有两次开发经历，有把配置脚本化的倾向，最终还是抵挡住了这种诱惑。

不过于复杂的原因，我还是从成本来考虑的。

	实现成本	学习使用成本
配置	配置导入模块	低。有限的参数，可以手工配置。
脚本	脚本解析器	高。复杂的语法集合，需要有界面辅助配置
语言	编译器	高。全集，需要有IDE

 

当然，我们也许会觉得这世上脚本和语言多得是，而且不乏人开发，多我一个也不多啊！还是用数学命题打比方吧。命题有公理、定理和推论等。世上发明公理定理的牛人是不辈出的。大多数人不过是拿着推论搞应用。我见过朴实的农民拿着厚厚的稿子来大学找教授的，但绝大多数是初中生证明哥德巴赫猜想似的例子。所以像你我这样的普通程序员，如果碰到了发明自己的脚本甚至语言的机会，提醒一下自己是不是幻觉，还是有现实意义的。当然配置脚本化这样极端的情况不会经常发生的，但基于此，处处提醒自己不要让配置太复杂，也有好处。

最后谈谈关于咋做的一些经验之谈。要避免让程序配置长得太过复杂，首先每次往文件里塞一条新的配置之前，都要先问问自己：这样做有必要吗？或者当配置复杂到将要超出自己控制的时候，就要选择“立定，向后转”，失控的标志通常就是配置需要定义流程控制，循环等。

对于模块和规模不大的程序而言，简单的配置+接口回调，可以用来抵挡配置脚本化的趋势。简单的边界条件用配置，复杂的则仍然在接口实现里用代码定义。这样对于使用者而言，学习配置格式的代价有限，而写接口实现代码的语言则应该是早为他们所熟悉的C/C++或Java等。