設定ファイルはどの時点でプログラミング言語になりますか？

https://stackoverflow.com/questions/648246

22-07-2019
|

質問

私はしばらくの間、設定ファイルとコードとの関係を熟考してきましたが、風の日と方向によって意見が変わるようです。 Lispを学んでいる間に私が最初に抱いた実現に戻ってきましたが、データとコードにはほとんど違いはありません。これは、設定ファイルに対して二重に当てはまるようです。右から見ると、Perlスクリプトはperlの設定ファイルにすぎません。これは、QAなどのタスクや、構成ファイルの変更を誰が担当すべきかなどの分業にかなり大きな影響を与える傾向があります。

設定ファイルから本格的な言語への移行は一般に遅く、一般的なシステムを持ちたいという欲求に駆られているようです。ほとんどのプロジェクトは、ログを書き込む場所、データを探す場所、ユーザー名とパスワードなどのいくつかの設定項目を使用して、小さなものから始めているように見えます。しかし、その後、それらは成長し始めます：機能がオンまたはオフになり始める、操作のタイミングと順序の制御が開始され、必然的に誰かがそれにロジックの追加を開始することを望みます（たとえば、マシンがXの場合は10、マシンがYの場合は15を使用します）。ある時点で、構成ファイルはドメイン固有の言語になり、その時点で記述が不十分な言語になります。

ステージを設定するためにとりあえず取り掛かりました。ここに私の質問があります：

構成の本当の目的は何ですかファイル？
キープしようとする必要があります構成ファイルは単純ですか？
誰が責任を負うべきかそれらへの変更（開発者、ユーザー、管理者など）？
ソース管理されるべきか（質問3を参照）？

前述したように、これらの質問に対する私の答えは絶えず変化しますが、今私は考えています：

非プログラマーが変更できるようにする大量の動作をすばやく
はい、粗くないものはすべて粒度はコードである必要があります
ユーザーは、構成ファイルとプログラマは構成を担当する構成ファイルとコードの間のレイヤーよりきめ細かな制御が可能アプリケーションの
いいえ。ただし、細かい粒子の中間層が必要です

解決

非常に興味深い質問！

設定ファイルを非常に単純な＆quot; key = value＆quot;に制限する傾向があります。なぜなら、設定ファイルはすぐに本格的なプログラムになる可能性があることに私は完全に同意するからです。たとえば、「設定」しようとしたことがある人は誰でもOpenSERはあなたが話している感覚を知っています。それは設定ではなく、（苦痛な）プログラミングです。

アプリケーションを非常に「構成可能」にする必要がある場合今日想像できないような方法で、本当に必要なのはプラグインシステムです。他の誰かが新しいプラグインをコーディングし、将来的にそれをアプリケーションにフックできるように、アプリケーションを開発する必要があります。

だから、あなたの質問に答えるために：

構成ファイルの本当の目的は何ですか？

アプリケーションをインストールするユーザーが、ホスト名、スレッド数、必要なプラグインの名前、およびそれらのデプロイメントパラメーターなど、いくつかのデプロイメント関連パラメーターを調整できるようにするためプラグイン（この原理の例については、FreeRadiusの構成を確認してください）など。ビジネスロジックを表現する場所ではありません。
構成ファイルをシンプルに保つための試みは必要ですか？

間違いなく。あなたが提案したように、「プログラミング」構成ファイル内の恐ろしいです。避けるべきだと思います。
変更（開発者、ユーザー、管理者など）を担当するのは誰ですか？

一般に、アプリケーションをデプロイする管理者と言います。
ソース管理する必要があります（質問3を参照）

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

編集：上記はほとんどのアプリケーションに当てはまると思いますが、もちろん例外は常にあります。たとえば、アプリケーションでは、ユーザーが複雑なルールを動的に構成できる場合があります。ほとんどのメールクライアントでは、ユーザーがメールの管理ルールを定義できます（たとえば、「「john doe」から送信され、To：フィールドに私がいないメールはすべて破棄する」など）。別の例は、ユーザーが新しい複雑な商業オファーを定義できるようにするアプリケーションです。また、ユーザーが複雑なデータベースレポートを作成できるCognosのようなアプリケーションについて考えることもできます。電子メールクライアントは、おそらくルールを定義するためのシンプルなインターフェイスをユーザーに提供します。これにより、複雑な構成ファイル（またはおそらく少しのコード）が生成されます。一方、商用オファーのユーザー定義構成は、構造化された方法でデータベースに保存される場合があります（単純なkey = value構造でもコードの一部でもありません）。また、他のアプリケーションによっては、ユーザーがpythonやVB、または他の自動化可能な言語でコードを作成できる場合もあります。つまり、走行距離は異なる場合があります。

他のヒント

わかりました。本当にシンプルな設定が必要なユーザーがいるので、それを提供する必要があります。同時に、＆quot;これを追加できますか？構成ファイルでどうすればよいですか？＆quot ;、両方のグループをサポートできない理由がわかりません。

現在取り組んでいるプロジェクトでは、構成ファイルにLuaを使用しています。 Luaはスクリプト言語であり、このシナリオでは非常にうまく機能します。デフォルト設定の例が利用可能です。

これは主にkey = valueステートメントであり、valueはLuaの組み込み型のいずれかであることに注意してください。最も複雑なのはリストであり、それらは実際には複雑ではありません（構文の問題です）。

今は、サーバーのポートを起動するたびにランダムな値に設定する方法を誰かが尋ねるのを待っています...

最近、私はプロジェクトに取り組んでいましたが、以前は非常に単純な形式であった構成ファイル内に条件を入れたいと思いました：


key = val
key2 = val
name = `hostname`

ミニ言語を作成したくありませんでした。非常に慎重に作成しない限り、有用な柔軟性を許可できなかったからです。

代わりに、2つのフォームを用意することにしました：

ファイルが＆quot;＃！＆quot;で始まった場合実行可能だったので、実行結果を解析しました。
それ以外の場合はそのまま読みます

これは、「構成ファイル」を作成できるようにすることを意味します。次のようになります：

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

この方法により、ユーザーがそれを使用したい場合に動的な構成ファイルの力を得ることができ、独自のミニ言語を記述する必要がないというシンプルさを実現できます。

すべての（十分に長寿命の）構成ファイルスキーマは、最終的にプログラミング言語になります。あなたが説明するすべての意味合いのために、設定ファイルの設計者がプログラミング言語をオーサリングし、それに応じて計画していることに気付き、将来のユーザーに悪い遺産を与えないようにするのが賢明です。

構成ファイルについては、別の哲学があります。アプリケーションの実行方法に関するデータは静止データであるため、コードではなくデータストアに属します（IMO構成ファイルはコードです）。エンドユーザーがデータを変更できるようにする必要がある場合、アプリケーションはそのためのインターフェイスを提供する必要があります。

データストアを指すのに設定ファイルのみを使用します。

計算理論に目を向けて、プログラミング言語として重要なものを定義できます。構成ファイルの形式が Turing Complete である場合、それは合理的にプログラミング言語としてカウントされます。この定義により、 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スクリプトはプログラミング言語です。

ここに私の考えがあります：

アプリケーションの実行時の動作を簡単に変更できるようにします。これは、必要に応じてプログラマーでも非プログラマーでも可能です。これは開発中であっても構いませんが、多くの場合、構成ファイルは、プログラムをより柔軟にするための方法と見なされます。
はい。ランタイムのさまざまな動作を制御するためにさまざまなオプションが必要になる可能性があるという制約を考えると、構成ファイルは可能な限り単純でなければなりません。構成設定をグループ化し、可能な限り単純化することを好みます。
変更の内容と理由によって異なります。ユーザーがこれを変更する場合は、フロントエンドを作成して詳細から非表示にする必要があります。一般に、開発者以外の人にも同じことがよくあります。
よく「デフォルト」をソース管理します;設定が、実際のランタイムのためにシステムごとにこれをオーバーライドする方法があります。

設定ファイルにロジックを追加する場合-これは避けたいです。構成ファイルでアプリケーションのロジックをオンにした方が良いと思います。私の経験では、構成ファイルの動作は保守性と理解の欠如につながります。構成ファイルをできるだけシンプルにすることを強くお勧めします。

この質問の前提に同意する傾向があります。これが起こることを早期に予測することでトラブルに巻き込まれないようにします。したがって、自分の構成システムを決して動かさないでください。

オペレーティングシステムの設定機能（plist、gconf、または適切なものなど）を使用している場合、
または市販のINIパーサーなどで処理できるシンプルなフラットファイル。
弾丸をかみ、軽量の言語パーサー、通常はlua、時にはtclをアプリケーションに差し込みます
または、SQLiteまたは同様のリレーショナルデータベースにデータを保存します。

そして、私が下した決定に応じて生き残るために辞任するか、できない場合は、アプリケーションに適した上記の選択肢のいずれかを使用するようにリファクタリングします。

ポイントは、自家製の構成ソリューションを使用する理由はまったくないということです。一つには、アプリケーション固有の新しい設定形式を学ぶ必要があるのはユーザーにとって難しいことです。もう1つは、市販のソリューションを使用するときに無料で提供される多くのバグ修正と更新の恩恵を受けることです。最後に、機能クリープは休息します。なぜなら、実際には、大規模なオーバーホールを行わずにもう1つの機能を追加することはできないからです。

チームの他の開発者に同意する内容によって異なります。構成ファイルを構成ファイルと同じように使用していますか、それともモデル駆動型アプリケーションを作成しています。

設定ファイルがプログラミング言語になる症状：

name = valueペアは互いに依存し始めます
フロー制御が必要だと感じている（例：それよりもif（this））
（アプリケーションを使用するだけでなく）さらなる開発を行うには、構成ファイルのドキュメントが不可欠になります
configの値を読み取る前に、何らかのコンテキストが必要です（つまり、値はconfigファイル自体の外部の何かに依存しています）

構成ファイルは常に、ugくて非論理的な「本格的なプログラミング言語」になります。優れたプログラミング言語を設計するには、芸術とスキルが必要です。また、プログラミング言語になった構成言語は恐ろしい傾向があります。

良い方法は、Pythonやrubyなどの適切に設計された言語を使用し、それを使用して DSL を設定します。そうすれば、構成言語は表面的にはシンプルなままですが、実際には本格的なプログラミング言語になります。

「流fluentなインターフェース」への移行を考えると、あなたの質問は非常に重要だと思います。多くの開発者が「光を見て」います。 XML構成済みアプリケーションに関して。 XMLの使用は非常に冗長であり、正しく編集することは困難です（特にスキーマが提供されていない場合）。流fluentなインターフェイスを使用すると、開発者はプレーンテキストの構成ファイル（またはコマンドラインパラメーター）のキーと値のペアを使用して、アプリケーションをドメイン固有の言語で構成できます。また、テスト用など、アプリケーションの新しいインスタンスのセットアップと構成が非常に簡単になります。

質問に対する私の答えは次のとおりです。

構成の本当の目的は何ですかファイル？

設定ファイルは、ユーザーが実行時にプログラムの動作をカスタマイズできるようにする方法です。

キープしようとする必要があります構成ファイルは単純ですか？

理想的には、設定ファイルは少なくともプログラムを設定するための流fluentなインターフェースで補完されるべきだと思います（これは多くの点で有用です）。構成ファイルが必要な場合は、キーと値のペア以外の非常に単純なものにしてください。

誰が責任を負うべきかそれらへの変更（開発者、ユーザー、管理者など）？

これに対する答えは組織によって異なると思います。ソフトウェアが適切に構成されていることを確認するのは、ソフトウェアを展開する人の責任である必要があります。

ソース管理する必要があります（参照質問3）？

この回答を他の誰かから盗みます:)ソース管理にテンプレート構成を保存し、各ローカルユーザーのニーズに合わせて変更するというアイデアが好きです。開発者の設定ファイルは別の開発者の悪夢である可能性があるため、ユーザーによって異なるものはソース管理から外すのが最善です。テンプレートを持つことは、アプリケーションをデプロイする人（または他の開発者）に、構成ファイルに有効な値を正確に確認させる良い方法でもあります。

設定ファイルがコードであるpythonプログラムを見ました。特別なこと（条件など）を行う必要がない場合は、他の設定スタイルとあまり変わりません。例えば次のようなもので config.py ファイルを作成できます：

num_threads = 13
hostname = 'myhost'

そして（たとえば）INIファイルと比較して、ユーザーの唯一の負担は、文字列を ''で囲む必要があることです。他のインタプリタ言語でも同じことができることは間違いありません。必要に応じて構成ファイルを複雑にする無制限の機能を提供します。ユーザーを怖がらせる可能性があります。

はい、構成ファイルは単純でなければなりません。それらには「ロジック」自体を含めるべきではありません-それらを条件文全体ではなく、if文の式のリストと考えてください。

これらは、ユーザーがアプリケーション内でコード化されたオプションのどれを使用するかを決定できるようにするためのものです。そのため、複雑にしようとしないでください。それ以外の場合、元の構成ファイルの構成方法を制御する単純な構成ファイル！

「オスロ」の目的の1つMicrosoftでの作業は、この問題の解決を許可することです（必須ではありません）。

アプリケーションには、含まれる新しいコンポーネントのモデルが付属しています。既存のモデルも使用します。たとえば、Webサービスが含まれている可能性があるため、Webサービスのシステムモデルを再利用できます。
モデルには、テキストまたはグラフィカルにアクセスするためのツールに十分な情報など、モデルを説明するメタデータが含まれます。
モデルの一部は「構成」に対応します

これは、今日の構成ファイルに相当するものが、構成のテキスト編集とグラフィック編集の両方をサポートするのに十分なほど豊富であることを意味します。グラフィカルツールには「Oslo」が付属します。（コード名＆quot; Quadrant＆quot;）。

私は反対派になり、XMLで表現できる以上のことを具体化するときは、それが唯一の言語であることを提出します。または、XMLが言語と見なされる場合。

別の方法として、ほとんどの設定ファイルはクラスと考えることができますが、プロパティのみでメソッドはありません。そして、メソッドがなければ、私はそれが言語だとは思いません。

最終的に、「言語」スクイーズ抽象ですが、はい、エッジはあいまいです。

アプリケーションのコードはそれほど重要ではありません...スクリプトがあり、クラス、メソッド、メソッド引数、およびプロパティの動作を定義するすべての種類の属性があります。ユーザーは、データベーストリガーとデータベース制約を定義できます。非常に複雑な設定ファイルが存在する場合があります。システムはオープン（SOA）である必要があるため、ユーザーはXSLTスタイルシートを定義して入出力を操作できる場合があります。また、BizzTalkのような複雑な設定が必要なものもあります。ユーザーは複雑なワークフローを定義できます。

この複雑な環境に対処するには、より良いコードを記述する必要があるため、アプリケーションのコードがより重要になります...

私はpythonプログラムを設定ファイルとして、特にデーモン用に使うのが大好きです。「構成ポート」を除いて、デーモンを構成から完全に空にすることに取り組んでいます。次に、pythonプログラムはデーモンに接続し、デーモン内にオブジェクトを作成し、それらを接続して目的の構成を作成します。すべての設定が完了したら、デーモンはそのままで実行できます。もちろん、利点は、設定ファイルを作成するための本格的なプログラミング言語を取得できることと、別のプログラムからデーモンと通信する方法がすでにあるため、デバッグと統計の取得に使用できることです。主な欠点は、いつでも入ってくる別のプログラムからのメッセージを処理しなければならないことです。

構成ファイル：＆quot;私の目的は何ですか？＆quot;
あなた：＆quot;バターを設定します。＆quot;
構成ファイル：＆quot; Ok ...＆quot;
構成ファイル：＆quot;私の目的は何ですか？＆quot;
あなた：＆quot;バターを設定します＆quot;
設定ファイル：＆quot; Oh my god。＆quot;

「真の目的」はありません。構成ファイルの。それはあなたのアプリケーションにとって理にかなっています。一般に、マシン間で異なる（または異なる可能性のある）もので、アプリケーションの実行中に変更されないものは、おそらく構成ファイルにあるはずです。他のサービスのデフォルト、ポート、アドレスはすべて素晴らしい候補です。キーとシークレットも優れた候補ですが、セキュリティ上の理由から通常の設定とは別に処理する必要があります。構成ファイルの目的は、迅速な変更を可能にすることであることに同意しません。目的は、アプリケーションのセットアップに柔軟性を持たせることです。構成ファイルがその柔軟性を実現するための迅速で簡単な方法であれば、はるかに優れていますが、構成ファイルを頻繁に変更することを意図しないでください。
はい、いいえ。アプリケーションのコードをシンプルにすることを試みるべきですか？はい。あなたが書くことはすべてシンプルに、そして要領を保って試みるべきです。必要以上に複雑ではありません。同じことが設定にも当てはまります。ただし、これはアプリケーション固有のものです。構成を「複雑すぎる」ため、構成内にあるべきものをハードコーディングする悪いデザインです。実際、「物事をシンプルに」しようとすると、構成ファイルが巨大な混乱に終わる理由です。時には、最も単純な動きはモジュール化することです。これが、設定ファイルをよく知られている汎用プログラミング言語で記述する必要がある理由です-恐ろしい設定言語ではありません（すべての＆quot;設定言語＆quot; suck ）。
繰り返しますが、構成ファイルを変更するユーザーは完全にアプリケーションに依存しています。しかし、ミニクォークには同意します。アプリケーションをデプロイしている人が構成を担当する必要があります。
可能な限りすべてをソース管理します。ソース管理は素晴らしいです。ものを簡単にロールバックでき、行った変更の完全な履歴と、それらの変更を行った人の記録があります。ではなぜですか？

ライセンス： CC-BY-SA と帰属

所属していません StackOverflow