configuration - 配置文件什么时候成为一种编程语言？

Question

我已经考虑配置文件及其与代码的关系有一段时间了，根据日期和风向，我的观点似乎会发生变化。但我越来越回想起我在学习 Lisp 时最初的认识:数据和代码之间几乎没有什么区别。对于配置文件来说，这似乎更加正确。从正确的角度来看，Perl 脚本只不过是 Perl 的配置文件。这往往会对 QA 和劳动分工(例如谁应该负责更改配置文件)等任务产生相当严重的后果。

从配置文件到成熟语言的转变通常很慢，并且似乎是由拥有通用系统的愿望驱动的。大多数项目似乎都是从小规模开始的，只有一些配置项，例如在哪里写入日志、在哪里查找数据、用户名和密码等。但随后它们开始增长:功能开始能够打开或关闭，操作的时间和顺序开始受到控制，不可避免地，有人想要开始向其添加逻辑(例如，如果机器是 X，则使用 10；如果机器是 Y，则使用 15)。在某个时刻，配置文件变成了一种特定于域的语言，而且是一种写得很糟糕的语言。

现在我已经漫无目的地准备好了，以下是我的问题:

1. 配置的真正目的是什么 文件？
2. 是否应该尝试保留 配置文件简单吗？
3. 谁应该负责制定 对他们的改变(开发者、用户、 管理员等)？
4. 它们是否应该受到源代码控制 (见问题3)？

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

1. 允许非程序员进行更改 快速进行大量行为
2. 是的，任何不粗俗的东西 粒度应该在代码中
3. 用户应负责 配置文件和程序员应该 负责配置 配置文件和代码之间的层 提供更细粒度的控制 应用程序
4. 不，但是更细粒度的中间层应该是

Answer 1

非常有趣的问题!

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

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

那么，回答你的问题:

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

   我想说的是，允许安装您的应用程序的人能够调整一些与部署相关的参数，例如主机名、线程数、您需要的插件的名称以及这些插件的部署参数插件(查看 FreeRadius 的配置以获取此原理的示例)等。绝对不是表达业务逻辑的地方。

2. 是否应该尝试保持配置文件简单？

   当然。正如您所建议的，配置文件中的“编程”是可怕的。我认为应该避免这种情况。

3. 谁应该负责对它们进行更改(开发人员、用户、管理员等)？

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

4. 它们是否应该受到源代码控制(参见问题 3)？

   我通常不对配置文件本身进行源代码控制，但我对模板配置文件进行源代码控制，其中包含所有参数及其默认值以及描述其功能的注释。例如，如果配置文件名为 database.conf，我通常会对名为 database.conf.template 的文件进行源代码管理。当然，现在我正在谈论我作为开发人员所做的事情。 作为管理员，我可能希望对我为每次安装选择的实际设置进行源代码控制。例如，我们远程管理数百台服务器，我们需要跟踪它们的配置:我们选择通过源代码控制来做到这一点。

<小时/>

编辑:虽然我相信上述内容对于大多数应用程序都是正确的，但当然总有异常(exception)。例如，您的应用程序可能允许其用户动态配置复杂的规则。大多数电子邮件客户端允许用户定义电子邮件管理规则(例如，“所有来自‘john doe’并且“收件人:”字段中没有我的电子邮件都应被丢弃”)。另一个示例是允许用户定义新的复杂商业报价的应用程序。您还可以考虑像 Cognos 这样的应用程序，它允许用户构建复杂的数据库报告。电子邮件客户端可能会为用户提供一个简单的界面来定义规则，这将生成一个复杂的配置文件(甚至可能是一些代码)。另一方面，商业报价的用户定义配置可以以结构化方式保存在数据库中(既不是简单的键=值结构，也不是代码的一部分)。一些其他应用程序甚至可能允许用户使用 python 或 VB 或其他一些支持自动化的语言进行编码。换句话说...您的里程可能会有所不同。