Configuration 配置文件在什么时候成为编程语言？

我一直在思考配置文件以及它们与代码的关系，现在我的观点似乎在改变，这取决于天气和风向。尽管我不断回到学习Lisp时的第一个认识：数据和代码之间几乎没有区别。对于配置文件来说，这似乎是双重事实。从正确的角度来看，Perl脚本只不过是Perl的配置文件。这往往会对QA等任务和分工（如谁应该负责更改配置文件）产生相当严重的后果

从配置文件到完全成熟的语言的爬行通常是缓慢的，并且似乎是由对通用系统的渴望驱动的。大多数项目似乎一开始都很小，只有一些配置项，比如在哪里写日志、在哪里查找数据、用户名和密码等。但随后它们开始增长：功能开始能够打开或关闭，操作的时间和顺序开始得到控制，并且不可避免地，有人希望开始向其中添加逻辑（例如，如果机器是X，则使用10；如果机器是Y，则使用15）。在某一点上，配置文件会变成一种特定于域的语言，并且编写得很糟糕

现在，我已经漫无边际地准备好了舞台，下面是我的问题：

配置的真正目的是什么 档案

是否应尝试保持 配置文件简单吗

谁应该负责制作 对它们的更改（开发人员、用户、， 管理员等）

它们应该受到源头控制吗 （见问题3）

正如我之前所说，我对这些问题的回答不断变化，但现在我在想：

允许非程序员更改 大量的行为迅速发生

是的，任何不粗俗的东西 应该是在代码中

用户应负责 配置文件和程序员应该 负责配置 配置文件和代码之间的层 这提供了更细粒度的控制 应用程序的

没有，但更细粒度的中间层应该是

以下是我的想法：

允许轻松修改应用程序的运行时行为。这可以由程序员或非程序员根据需要进行修改。这可以在开发过程中进行，但我经常将配置文件视为帮助使程序在任何时候都更灵活的一种方法

是的。我认为配置文件应该尽可能简单，因为您可能需要各种选项来控制运行时的不同行为。我更喜欢分组配置设置，并尽可能简化它们

取决于所做更改的内容和原因。如果用户要更改它，则应制作前端以将其隐藏在细节中。一般来说，非开发人员也是如此

我经常对“默认”配置进行源代码控制，但有一种方法可以在实际运行时覆盖每个系统

---

至于向配置文件添加逻辑，我会避免这种情况。我认为最好是让配置文件在应用程序中打开逻辑。根据我的经验，配置文件中的行为会导致缺乏可维护性和理解性。我强烈希望配置文件尽可能简单。

非常有趣问题

我倾向于将配置文件限制为非常简单的“key=value”格式，因为我完全同意您的观点，配置文件可以很快成为成熟的程序。例如，任何试图“配置”OpenSER的人都知道您所说的感觉：这不是配置，而是（痛苦的）编程

当你需要你的应用程序以你现在无法想象的方式非常“可配置”时，那么你真正需要的是一个插件系统。你需要以一种其他人可以编写新插件并在将来将其挂接到你的应用程序的方式来开发你的应用程序

因此，要回答您的问题：

配置文件的真正用途是什么

我想说的是，让安装您的应用程序的人员能够查看一些与部署相关的参数，例如主机名、线程数、您需要的插件名称以及这些插件的部署参数（查看FreeRadius的配置以了解此原则的示例）等等，绝对不是表达业务逻辑的地方

是否应尝试使配置文件保持简单

当然。正如你所建议的，配置文件中的“编程”很可怕。我认为应该避免

谁应该负责对其进行更改（开发人员、用户、管理员等）

一般来说，我要说的是部署应用程序的管理员

是否应进行源头控制（见问题3）

我通常不会对配置文件本身进行源代码控制，但我会对模板配置文件进行源代码控制，其中包含所有参数及其默认值，以及描述其功能的注释。例如，如果配置文件名为

database.conf

，我通常会对名为

database.conf.tem的文件进行源代码控制plate

。现在我当然要谈谈我作为开发人员所做的工作。作为管理员，我可能希望对我为每次安装选择的实际设置进行源代码管理。例如，我们远程管理数百台服务器，我们需要跟踪它们的配置：我们选择使用源代码管理

---

编辑：虽然我认为上述情况适用于大多数应用程序，但当然也有例外。例如，您的应用程序可能允许其用户动态配置复杂的规则。大多数电子邮件客户端允许用户定义管理其电子邮件的规则（例如，“所有电子邮件都是

key = val
key2 = val
name = `hostname`

#!/usr/bin/perl if ( -x /bin/foo ) { print <<EOF; foo=me bar=you EOF } else { print <<EOF; foo=bar bar=foo EOF }

num_threads = 13
hostname = 'myhost'