[解決済み] コンフィグファイルがプログラミング言語になるのはどの時点？

質問

私はしばらくの間、設定ファイルとそのコードとの関係について熟考しており、日や風向きによって私の意見は変わっているようです。 しかし、ますます多くの場合、私は Lisp を学んでいるときに最初に感じた、データとコードの間にはほとんど違いがないという認識に立ち戻るようになりました。 このことは、設定ファイルについても言えることです。 Perlスクリプトは、正しく見れば、Perlのための設定ファイルに過ぎないのです。 これは、QA のようなタスクや、誰が設定ファイルの変更に責任を持つべきかのような分業に、かなり重い結果をもたらす傾向があります。

設定ファイルから本格的な言語への移行は一般的に遅く、一般的なシステムを持ちたいという願望に駆られているようです。 ほとんどのプロジェクトは、ログを書き込む場所、データを探す場所、ユーザー名とパスワードなど、いくつかの設定項目から小さく始まります。 しかし、次第に大きくなっていきます。機能のオン・オフが可能になり、操作のタイミングや順序が制御され始め、必然的に誰かが論理を追加し始めます（例えば、マシンがXなら10を使い、Yなら15を使うなど）。 ある時点で、設定ファイルはドメイン固有の言語となり、しかもお粗末なものになります。

さて、私は舞台を設定するためにとりとめのない話をしましたが、ここからは私の質問です。

1. 設定ファイルの真の目的は何でしょうか。 ファイルの真の目的は何でしょうか。
2. 設定ファイルをシンプルに保つための試みは をシンプルに保つよう試みるべきでしょうか？
3. 設定ファイルの変更に責任を持つべき人 (開発者、ユーザー。 管理者など)?
4. ソース管理されるべきか (質問 3 を参照)?

先に述べたように、これらの質問に対する私の答えは常に変化しますが、今私は考えています。

1. プログラマーでない人が 動作の大きな塊をすばやく変更できるようにする
2. そう、粗い粒度でないものはすべて コードであるべきです。
3. ユーザは 設定ファイルに責任を持つべきで、プログラマは プログラマは設定ファイルに責任を持つべきです。 設定ファイルとコードの間のレイヤー よりきめ細かい制御を可能にする アプリケーションの
4. いいえ、しかし、より細かい中間層が必要です。

どのように解決するのですか？

とても興味深い質問ですね。

私は設定ファイルを非常に単純な "key=value" 形式に制限する傾向があります。なぜなら、設定ファイルは非常に迅速に完全なプログラムになり得るということに完全に同意するからです。 たとえば、OpenSER を "configure" したことがある人なら、あなたが話している感覚を理解しています。

アプリケーションが、今日では想像もつかないような方法で、非常に"configurable" であることが必要なとき、本当に必要なものは プラグインシステム . 将来、他の誰かが新しいプラグインをコーディングして、それをアプリケーションにフックできるような方法で、アプリケーションを開発する必要があるのです。

では、質問にお答えします。

1. 設定ファイルの真の目的は何ですか？

   私は、あなたのアプリケーションをインストールする人が、ホスト名、スレッドの数、必要なプラグインの名前、およびそれらのプラグインのためのデプロイメントパラメータ (この原則の例として FreeRadius の設定をチェックしてください) などのデプロイ関連のパラメータを微調整できるようにすること、だと言っています。 ビジネス ロジックを表現する場所でないことは明らかです。

2. 設定ファイルをシンプルに保つ試みはなされるべきでしょうか？

   間違いありません。 あなたが提案したように、設定ファイルでの "programming" は恐ろしいものです。 私は、それは避けるべきだと思います。

3. 誰が変更を加える責任を負うべきでしょうか (開発者、ユーザー、管理者など)。

   一般的には、アプリケーションをデプロイする管理者と言えるでしょう。

4. 彼らはソース管理されるべきでしょうか（質問3参照）？

   私は通常、設定ファイルそのものをソース管理しませんが を行います。 source-control テンプレート設定ファイルには、すべてのパラメータとそのデフォルト値、およびそれらが何を行うかを説明するコメントが含まれています。 例えば、設定ファイルの名前が database.conf という名前の場合、私は通常、次のような名前のファイルをソース管理します。 database.conf.template . もちろん、私がしていることについて話しているのです。 開発者として . 管理者として として、私は各インストールのために選択した実際の設定をソース管理したいと思うかもしれません。 たとえば、私たちは数百台のサーバーをリモートで管理しており、それらの設定を追跡する必要があります。

編集 上記のことはほとんどのアプリケーションに当てはまると思いますが、もちろん例外は常に存在します。 例えば、あなたのアプリケーションでは、ユーザーが複雑なルールを動的に設定することができるかもしれません。 ほとんどのメールクライアントでは、ユーザーが自分のメールを管理するためのルールを定義することができます（例えば、"「john doe」から来たメールで、To: フィールドに私が含まれていないものはすべて破棄する必要があります")。 他の例としては、ユーザーが新しい複雑なコマーシャルオファーを定義することができるアプリケーションです。 また、Cognosのように、ユーザーが複雑なデータベース・レポートを作成することができるアプリケーションについても考えてみましょう。 電子メールクライアントはおそらく、ルールを定義するための簡単なインターフェースをユーザーに提供し、これによって複雑な設定ファイル（あるいはちょっとしたコード）が生成されるでしょう。 一方、コマーシャルオファーのためにユーザーが定義した設定は、構造化された方法でデータベースに保存されるかもしれません（単純なキー=バリュー構造でもコードの一部でもありません）。 また、他のアプリケーションでは、ユーザーがpythonやVB、あるいは他の自動化可能な言語でコーディングすることができるかもしれません。 言い換えれば...あなたのマイレージは異なるかもしれません。