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

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 的文件进行源代码管理。 当然，现在我正在谈论我作为开发人员所做的事情。 作为管理员，我可能希望对我为每次安装选择的实际设置进行源代码控制。 例如，我们远程管理数百台服务器，我们需要跟踪它们的配置：我们选择通过源代码控制来做到这一点。

---

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

Answer 2

好的。 您将有一些用户想要一个非常简单的配置，您应该将其提供给他们。 同时，您会不断收到“您可以添加这个吗？我在配置文件中该怎么做？”的请求，我不明白为什么您不能支持这两个组。

我目前正在做的项目使用Lua作为其配置文件。 Lua是一种脚本语言，在这种情况下效果很好。 我们提供了默认配置的示例。

你会注意到它主要是 key=value 语句，其中 value 可以是 Lua 的任何内置类型。 最复杂的东西是列表，它们实际上并不复杂（这只是语法问题）。

现在我只是在等待有人询问如何在每次启动时将服务器的端口设置为随机值......

Answer 3

最近，我正在开发一个项目，我意识到我想在我的配置文件中包含条件 - 以前只是一个非常简单的形式：

key = val
key2 = val
name = `hostname`

我不想编写一种迷你语言，因为除非我这样做非常小心地我不能允许有用的灵活性。

相反，我决定采用两种形式：

1. 如果文件以“#!”开头 并且是可执行的，我会解析运行它的结果。

2. 否则我会按原样读取它

这意味着我现在可以允许人们编写如下所示的“配置文件”：

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

这样，如果用户想要使用动态配置文件，我就可以获得动态配置文件的强大功能，并且无需编写自己的迷你语言，也很简单。

Answer 4

每个（足够长的）配置文件模式最终都会成为一种编程语言。 由于您所描述的所有含义，配置文件设计者明智地意识到她正在编写一种编程语言并相应地进行计划，以免给未来的用户带来不良遗产的负担。

Answer 5

我对配置文件有不同的看法。 有关应用程序应如何运行的数据仍然是数据，因此属于数据存储，而不是代码（IMO 中的配置文件是代码）。 如果最终用户需要能够更改数据，那么应用程序应该提供一个接口来执行此操作。

我只使用配置文件来指向数据存储。

Answer 6

您可以求助于计算理论来定义什么才是编程语言。 如果您的配置文件格式是图灵完备，那么它就可以合理地算作一种编程语言。 根据这个定义，描述 Sokoban 级别的文件格式算作一种编程语言（请参阅< a href="http://web.cs.ualberta.ca/~joe/Preprints/Sokoban/index.html" rel="nofollow noreferrer">此处）。 图灵完备以下的其他复杂程度也可能算在内，例如 正则语法 和 < a href="http://en.wikipedia.org/wiki/Pushdown_automaton" rel="nofollow noreferrer">下推自动机。

另一种看待它的方式是，许多配置文件只能进行数据标记，而正确的编程语言必须能够实现 算法。 例如，JSON 是一种配置文件格式，而 ECMA Script 是一种编程语言。

Answer 7

这是我的想法：

1. 允许轻松修改应用程序的运行时行为。 这可以由程序员或非程序员完成，具体取决于需要。 这可以在开发过程中进行，但我经常将配置文件视为帮助程序在任何时候变得更加灵活的一种方式。

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

3. 取决于进行更改的内容和原因。 如果用户要更改它，应该创建一个前端来隐藏他们的细节。 对于一般非开发人员来说也是如此。

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

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

Answer 8

我倾向于同意这个问题的前提。 我通过尽早预测这将会发生来避免给自己带来麻烦，因此从不推出我自己的配置系统。

• 我要么使用操作系统的配置工具（例如 plist、gconf 或任何合适的东西），
• 要么使用简单的平面文件，可以由现成的 INI 解析器之类的东西处理。
• 硬着头皮将一个轻量级语言解析器（通常是 lua，有时是 tcl）插入到应用程序中，
• 或者将数据存储在 SQLite 或类似的关系数据库中。

并接受我所做的任何决定，或者如果我不能，重构以使用上述更适合应用程序的选择之一。

重点是，实际上没有任何理由使用本土的配置解决方案。 一方面，您的用户更难学习新的、特定于应用程序的配置格式。 另一方面，使用现成的解决方案时，您可以从免费的所有错误修复和更新中受益。 最后，功能蠕变被搁置了，因为，好吧，你实际上不能在没有真正进行重大修改的情况下添加一个功能，因为配置系统一开始并不真正掌握在你的手中。

Answer 9

这取决于您与团队中其他开发人员的共识。 您是像配置文件一样使用配置文件还是正在创建模型驱动应用程序。

配置文件成为编程语言的症状：

• 名称=值对开始相互依赖
• 您觉得需要进行流控制（例如if（this）比那个）
• 配置文件的文档变得至关重要 进行进一步的开发（而不仅仅是使用应用程序），它需要有一些上下文（即值取决于配置文件本身外部的东西）
• 为了在读取配置中的值之前

Answer 10

配置文件总是慢慢地变得丑陋、不合逻辑的“成熟的编程语言”。 设计好的编程语言需要艺术和技巧，而配置语言变成的编程语言往往是可怕的。

一个好的方法是使用设计良好的语言，例如 python 或 ruby​​，并使用它来创建 DSL 适合您的配置。 这样，您的配置语言表面上可以保持简单，但实际上是成熟的编程语言。

Answer 11

我相信考虑到向“流畅的界面”的转变，你的问题非常相关。 许多开发人员已经“看到了 XML 配置应用程序的曙光”。 使用 XML 可能非常冗长并且难以正确编辑（特别是在未提供架构的情况下）。 拥有流畅的界面允许开发人员借助纯文本配置文件（或者可能是命令行参数）中的一些键值对的帮助，以特定于域的语言配置应用程序。 它还使得设置和配置应用程序的新实例以进行测试或其他操作变得非常容易。

以下是我对您问题的回答：

• 配置的真正目的是什么
  文件？

配置文件是一种允许用户在运行时自定义程序行为的方法。

• 是否应尝试保留
  配置文件简单吗？

理想情况下，我认为配置文件至少应该辅以流畅的界面来配置程序（这在很多方面都很有用）。 如果您确实需要配置文件，那么它应该保持非常简单，只不过是键值对。

• 谁应该负责制作
  对他们的改变（开发者、用户、
  管理员等）？

我认为这个问题的答案取决于您的组织。 部署软件的人员有责任确保其配置正确。

• 它们是否应该受到源代码控制（请参阅
  问题3）？

我将从其他人那里窃取这个答案:) 我喜欢在源代码管理中存储模板配置并根据每个本地用户的需求修改它的想法。 一个开发人员的配置文件很可能是另一个开发人员的噩梦，因此最好将因用户而异的内容置于源代码控制之外。 拥有模板也是让部署应用程序的人员（或其他开发人员）准确了解配置文件有效值的好方法。

Answer 12

我见过 python 程序，其中配置文件是代码。 如果您不需要做任何特殊的事情（条件等），它看起来与其他配置样式没有太大不同。 例如，我可以创建一个文件 config.py ，其中包含以下内容：

num_threads = 13
hostname = 'myhost'

与（例如）INI 文件相比，用户的唯一负担是它们需要在字符串周围放置 '' 。 毫无疑问，您可以用其他解释语言做同样的事情。 它使您可以在必要时无限地使配置文件复杂化，但可能会吓到用户。

Answer 13

是的，配置文件应该很简单。 它们本身不应该包含“逻辑”——将它们视为 if 语句中的表达式列表，而不是整个条件语句。

它们允许用户决定应该使用应用程序中编码的哪些选项，所以不要试图使它们复杂化，这最终会弄巧成拙 - 您最终可能会编写简单的配置文件控制原始配置文件的配置方式！

Answer 14

Microsoft 的“奥斯陆”工作的目的之一是允许（但不要求）解决此问题。

1. 应用程序将附带其包含的任何新组件的模型。 它还将使用现有模型。 例如，它可能包含 Web 服务，因此它可以重用 Web 服务的系统模型。
2. 这些模型将包括描述它们的元数据，包括足够的信息供工具以文本或图形方式访问它们。
3. 模型的某些部分将对应于“配置”，

这意味着相当于当今的配置文件可能足够丰富以支持其配置的文本和图形编辑。 图形工具将随“Oslo”（代号“Quadrant”）一起提供。

Answer 15

我会持相反观点，认为它只是一种语言，因为它所体现的内容超出了 XML 所能表示的范围。 或者当 XML 被认为是一种语言时。

或者，大多数配置文件可以被视为类，但只有属性而没有方法。 如果没有方法，我不认为它是一种语言。

归根结底，“语言”是一个模糊的抽象概念，但是，边缘是模糊的。

Answer 16

我们的应用程序的代码变得不那么重要了......有脚本，有各种定义类、方法、方法参数和属性的行为的属性。 用户可以定义数据库触发器和数据库约束。 可能有非常复杂的配置文件。 有时，用户可以定义 XSLT 样式表来操作输入和输出，因为我们的系统需要开放（SOA）。 还有像 BizzTalk 这样的东西也需要复杂的配置。 用户可以定义复杂的工作流程。

我们必须编写更好的代码来应对这种复杂的环境，因此我们应用程序的代码变得更加重要......

Answer 17

我非常喜欢使用 python 程序作为配置文件，尤其是守护进程。 我喜欢采取的策略是让守护进程完全没有配置，除了“配置端口”之外。 然后，Python 程序连接到守护进程，并继续在守护进程中创建对象，并将它们连接在一起以创建所需的配置。 一旦一切设置完毕，守护进程就可以自行运行。 当然，这样做的好处是，您可以获得一种成熟的编程语言来编写配置文件，并且由于您已经有一种方法可以从另一个程序与守护进程对话，因此您可以使用它来调试和获取统计信息。 主要缺点是必须处理随时来自另一个程序的消息。

Answer 18

配置文件：“我的目的是什么？”
你：“配置黄油。”
配置文件：“好的...”
配置文件：“我的目的是什么？”
你：“你配置黄油。”
配置文件：“天哪。”
你：“是的，欢迎来到俱乐部。”

1. 配置文件没有“真正的目的”。 它对您的应用程序有意义。 一般来说，机器之间不同（或可能不同）并且在应用程序运行过程中不会改变的东西可能应该在配置文件中。 其他服务的默认值、端口和地址都是不错的选择。 密钥和秘密也是很好的选择，但出于安全原因应与正常配置分开处理。 我不同意配置文件的目的是允许快速更改。 目的应该是允许应用程序设置的灵活性。 如果配置文件是一种快速简单的方法来实现这种灵活性，那就更好了 - 但您不应该希望您的配置文件经常更改。

2. 是和否。 您是否应该尝试使应用程序的代码变得简单？ 是的。 您应该尝试使您所写的所有内容简单明了。 不需要比需要的更复杂。 您的配置也是如此。 然而，这是非常特定于应用的。 对配置中应包含的内容进行硬编码是糟糕的设计，因为这会使您的配置“过于复杂”。 事实上，试图“让事情变得简单”就是配置文件最终变得一团糟的原因。 有时，最简单的举措就是模块化。 这就是为什么你的配置文件应该用众所周知的通用编程语言编写 - 而不是一些糟糕的配置语言（阅读：所有“配置语言”都很糟糕）。

3. 同样，谁应该修改配置文件完全取决于应用程序。 但我同意 miniquark 的观点，无论谁部署应用程序都应该负责配置。

4. 尽你所能控制源代码。 源头控制很棒。 您可以非常轻松地回滚内容，并且您拥有所做更改的完整历史记录以及进行这些更改的人员的记录。 那么为什么不呢？

Answer 19

将条件逻辑保留在程序中，并将数据/参数保留在配置文件中。 简单的人！