配置文件在什么时候成为编程语言？ [英] At what point does a config file become a programming language?

问题描述

我一直在研究配置文件和他们的代码关系一段时间，根据风的日子和方向我的意见似乎改变。越来越多的，虽然我不断回到我第一次学习Lisp时的实现：数据和代码之间没有什么区别。这似乎对配置文件是真的。当在正确的光线下看时，Perl脚本只是perl的一个配置文件。这往往对诸如QA和分工等任务有相当严重的后果，例如谁应该负责更改配置文件。

从配置文件蠕变到完整的语言通常是缓慢的，并且似乎是由具有通用系统的愿望驱动的。大多数项目似乎从一个小的配置项目，如在哪里写日志，在哪里寻找数据，用户名和密码等。但随后他们开始增长：功能开始能够打开或关闭，操作的时间和顺序开始被控制，并且不可避免地，有人想要开始添加逻辑（例如，如果机器是X则使用10，如果机器是Y，则使用15）。在某一点，配置文件成为一个域特定的语言，并在那个写得不好。

现在我已经漫游到设置舞台，这里是我的问题：

1. config
   文件的真正目的是什么？


2. 尝试保持
   配置文件简单？


3. 谁应该负责对他们（开发人员，用户，
   管理员等）进行
   更改。）


4. 
   
5. 是否为源代码管理的
   （参见问题3）？

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

1. 允许非程序员改变
   行为的大块


2. 是的，不粗糙的
   粒度应该在代码


3. 负责
   配置文件和程序员应该
   负责配置
   层在配置文件和代码
   之间给出更细粒度的控制
   应用程序
4. 
   
5. 否，但是更细粒度的中间层应该是

解决方案

p>非常有趣的问题！

我倾向于将我的配置文件限制为一个非常简单的key = value格式，因为我完全同意你的配置文件可以非常迅速成为全面的节目。例如，任何曾试图配置OpenSER的人都知道你在说什么感觉：它不是配置，而是（痛苦的）编程。

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

因此，回答您的问题： / p>

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

   
   
   

   会说，允许安装您的应用程序的人能够调整一些部署相关的参数，如主机名，线程数，您需要的插件的名称和这些插件的部署参数（签出




2. 如果尝试保持配置文件简单？

   
   
   

   当然。正如你所建议的，配置文件中的编程是可怕的。




3. 谁应该负责对他们（开发人员，用户，管理员等）进行更改？

   $




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





我通常不对源配置文件本身进行源代码控制，而是对源模板配置文件进行源代码控制，参数和它们的默认值，以及描述它们做什么的注释。例如，如果一个配置文件命名为 database.conf ，我通常源代码控制一个名为 database.conf.template的文件。当然，我现在在说的是我作为开发人员的工作。 作为管理员，我可能希望源控制我为每次安装选择的实际设置。例如，我们远程管理了几百台服务器，我们需要跟踪其配置：我们选择使用源代码控制。

---

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

I have been mulling over config files and their relationship to code for a while now and depending on the day and direction of the wind my opinions seem to change. More and more though I keep coming back to the realization I first had while learning Lisp: there is little difference between data and code. This seems doubly true for config files. When looked at in the right light a Perl script is little more than a config file for perl. This tends to have fairly heavy consequences for tasks such as QA and divisions of labor like who should be responsible for changing config files.

The creep from config file to full fledged language is generally slow and seems to be driven by the desire to have a generic system. Most projects seem to start out small with a few config items like where to write logs, where to look for data, user names and passwords, etc. But then they start to grow: features start to be able to be turned on or off, the timings and order of operations start to be controlled, and, inevitably, someone wants to start adding logic to it (e.g. use 10 if the machine is X and 15 if the machine is Y). At a certain point the config file becomes a domain specific language, and a poorly written one at that.

Now that I have rambled on to set the stage, here are my questions:

1. What is the true purpose of a config file?
2. Should an attempt be made to keep config files simple?
3. Who should be responsible for making changes to them (developers, users, admins, etc.)?
4. Should they be source controlled (see question 3)?

As I said earlier my answers to these questions shift constantly, but right now I am thinking:

1. to allow a non-programmers to change large chunks of behaviour quickly
2. yes, anything that is not coarsely grained should be in code
3. users should be responsible for config files and programmers should be responsible for a configuration layer between config files and code that gives more fine grained control of the application
4. no, but the finer grained middle layer should be

解决方案

Very interesting questions!

I tend to limit my config files to a very simple "key=value" format, because I fully agree with you that config files can very quickly become full-blown programs. For example, anyone who has ever tried to "configure" OpenSER knows the feeling you are talking about: it's not configuration, it's (painful) programming.

When you need your application to be very "configurable" in ways that you cannot imagine today, then what you really need is a plugins system. You need to develop your application in a way that someone else can code a new plugin and hook it into your application in the future.

So, to answer your questions:

1. What is the true purpose of a config file?

   I would say, to allow the people who will install your application to be able to tweek some deployment-related parameters, such as host name, number of threads, names of the plugins you need, and the deployment-parameters for those plugins (check out FreeRadius's configuration for an example of this principle), etc.. Definitely not the place to express business logic.

2. Should an attempt be made to keep config files simple?

   Definitely. As you suggested, "programming" in a config file is horrible. I believe it should be avoided.

3. Who should be responsible for making changes to them (developers, users, admins, etc.)?

   In general, I would say admins, who deploy the application.

4. Should they be source controlled (see question 3)?

   I usually don't source-control the configuration files themselves, but I do source-control a template configuration file, with all the parameters and their default values, and comments describing what they do. For example, if a configuration file is named database.conf, I usually source-control a file named database.conf.template. Now of course I am talking about what I do as a developer. As an admin, I may want to source-control the actual settings that I chose for each installation. For example, we manage a few hundred servers remotely, and we need to keep track of their configurations: we chose to do this with source-control.

---

Edit: Although I believe the above to be true for most applications, there are always exceptions, of course. Your application may allow its users to dynamically configure complex rules, for example. Most email clients allow the users to define rules for the management of their emails (for example, "all emails coming from 'john doe' and not having me in the To: field should be discarded"). Another example is an application that allows the user to define a new complex commercial offer. You may also think about applications like Cognos which allow their users to build complex database reports. The email client will probably offer the user a simple interface to define the rules, and this will generate a complex configuration file (or even perhaps a bit of code). On the other hand, the user-defined configuration for the commercial offers might be saved in a database, in a structured way (neither a simple key=value structure nor a portion of code). And some other applications might even allow the user to code in python or VB, or some other automation-capable language. In other words... your mileage may vary.

这篇关于配置文件在什么时候成为编程语言？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！