構成ファイルはどの時点でプログラミング言語になりますか？
私はしばらくの間、構成ファイルとコードとの関係について検討してきましたが、日によって、風の方向によっては、私の意見が変わったようです。 LISPの学習中に最初に得た気づきにどんどん戻っていきますが、データとコードにはほとんど違いがありません。これは、構成ファイルについても二重に当てはまるようです。右から見ると、PerlスクリプトはPerlの構成ファイルに過ぎません。これは、QAや、構成ファイルの変更を担当する必要がある人のような分業などのタスクにかなり大きな影響を与える傾向があります。
設定ファイルから本格的な言語へのクリープは一般的に遅く、一般的なシステムを作りたいという欲求によって引き起こされているようです。ほとんどのプロジェクトは、ログを書き込む場所、データを検索する場所、ユーザー名とパスワードなどのいくつかの構成項目を備えた小さなものから始まっているように見えます。しかし、その後、プロジェクトは成長し始めます。動作のタイミングと順序が制御され始め、必然的に誰かがそれにロジックを追加し始めたいとします（たとえば、マシンがXの場合は10、マシンがYの場合は15を使用します）。ある時点で、設定ファイルはドメイン固有の言語になり、その部分では不十分に記述された言語になります。
準備ができたので、次は私の質問です。
- 設定ファイルの真の目的は何ですか？
- 設定ファイルをシンプルに保つように試みるべきですか？
- それらに変更を加える責任があるのは誰ですか（開発者、ユーザー、管理者など）？
- それらはソース管理されるべきですか（質問3を参照）？
先に述べたように、これらの質問に対する私の答えは常に変化しますが、今は考えています：
- プログラマーでない人が大きな動作の塊を素早く変更できるようにするため
- はい、ざらざらしていないものはすべてコードに含める必要があります
- ユーザーは構成ファイルを担当し、プログラマーは構成ファイルとコードの間の構成層を担当して、アプリケーションをより細かく制御する必要があります。
- いいえ、しかしより細かい中間層は
非常に興味深い質問！
構成ファイルはすぐに本格的なプログラムになることに同意するので、構成ファイルを非常に単純な "key = value"形式に制限する傾向があります。たとえば、OpenSERを「構成」しようとしたことのある人なら誰でも、あなたが話している感覚を知っています。それは構成ではなく、（苦痛な）プログラミングです。
アプリケーションが今日では想像できないほど非常に「構成可能」である必要がある場合、本当に必要なのはプラグインシステムです。他の誰かが新しいプラグインをコーディングし、将来それをアプリケーションにフックできるようにアプリケーションを開発する必要があります。
だから、あなたの質問に答えるには：
設定ファイルの真の目的は何ですか？
アプリケーションをインストールする人が、ホスト名、スレッド数、必要なプラグインの名前、それらのプラグインのデプロイメントパラメータなどのデプロイメント関連のパラメータを週にできるようにするには、この原理の例としては、FreeRadiusの構成を参照してください）など。ビジネスロジックを表現する場所ではありません。
設定ファイルをシンプルに保つように試みるべきですか？
間違いなく。あなたが示唆したように、設定ファイルの「プログラミング」は恐ろしいです。避けるべきだと思います。
それらに変更を加える責任があるのは誰ですか（開発者、ユーザー、管理者など）？
一般に、アプリケーションをデプロイする管理者と言います。
それらはソース管理されるべきですか（質問3を参照）？
私は通常、構成ファイル自体をソース管理しませんが、すべてのパラメーターとそのデフォルト値、およびそれらが何をするかを説明するコメントを含むテンプレート構成ファイルをdoソース管理します。たとえば、構成ファイルの名前が
database.confの場合、通常はdatabase.conf.templateという名前のファイルをソース管理します。さて、もちろん私は私が何をしているかについて話している開発者として。 管理者として、各インストールで選択した実際の設定をソース管理したい場合があります。たとえば、数百台のサーバーをリモートで管理し、それらの構成を追跡する必要があります。これをソース管理で行うことを選択しました。
編集：上記はほとんどのアプリケーションに当てはまると思いますが、もちろん例外もあります。たとえば、アプリケーションでは、ユーザーが複雑なルールを動的に構成できるようにする場合があります。ほとんどのメールクライアントでは、ユーザーがメールを管理するためのルールを定義できます（たとえば、「john doeから送信され、To：フィールドに私を含まないメールはすべて破棄する必要があります」）。別の例は、ユーザーが新しい複雑な商用オファーを定義できるアプリケーションです。ユーザーが複雑なデータベースレポートを作成できるようにするCognosのようなアプリケーションについて考えることもできます。電子メールクライアントは、おそらくルールを定義するためのシンプルなインターフェイスをユーザーに提供し、これにより複雑な構成ファイル（またはおそらく少しのコード）が生成されます。一方、商用オファーのユーザー定義構成は、構造化された方法でデータベースに保存される場合があります（単純なkey = value構造でもコードの一部でもありません）。また、他の一部のアプリケーションでは、ユーザーがpythonまたはVB、またはその他の自動化可能な言語でコーディングできるようにすることさえできます。つまり、...走行距離はさまざまです。
OK。あなたは本当にシンプルな設定を望んでいるユーザーがいるでしょう、あなたは彼らにそれを与えるべきです。同時に、「これを追加できますか？構成ファイルでどうすればよいですか？」という絶え間ない要求がありますが、両方のグループをサポートできない理由がわかりません。
私が現在取り組んでいるプロジェクトでは、構成ファイルにLuaを使用しています。 Luaはスクリプト言語であり、このシナリオでは非常にうまく機能します。 デフォルト設定 の例が利用可能です。
これは主にkey = valueステートメントであり、valueにはLuaの組み込み型のいずれかを指定できることに注意してください。最も複雑なのはリストであり、リストはそれほど複雑ではありません（構文の問題です）。
今、私は誰かが彼らのサーバーのポートを起動するたびにランダムな値に設定する方法を誰かが尋ねるのを待っています...
最近プロジェクトに取り組んでいて、構成ファイル内に条件文を入れたいと思っていました。
key = val
key2 = val
name = `hostname`
私がミニ言語を書きたくなかったのは、非常に注意深く書かないと、役に立つ柔軟性を許容できなかったからです。
代わりに、私は2つの形式があると判断しました。
「＃！」で始まるファイルの場合実行可能だったので、実行した結果を解析しました。
そうでなければ私はそれをそのまま読む
つまり、次のような「構成ファイル」を作成できるようになりました。
#!/usr/bin/Perl
if ( -x /bin/foo )
{
print <<EOF;
foo=me
bar=you
EOF
}
else
{
print <<EOF;
foo=bar
bar=foo
EOF
}
このようにして、ユーザーが動的構成ファイルを使用したい場合に威力を発揮し、独自のミニ言語を記述する必要がないという単純さを実現しています。
すべての（存続期間が長い）構成ファイルスキーマは、最終的にプログラミング言語になります。あなたが説明するすべての含意のため、彼女がプログラミング言語を作成していることを認識し、それに応じて計画することは、彼女が悪いレガシーで将来のユーザーに負担をかけないようにするのが賢明です。
計算理論に目を向けると、プログラミング言語として数えるものを定義できます。構成ファイルの形式が Turing Complete の場合、それはプログラミング言語として合理的にカウントされます。この定義では、 倉庫番 のレベルを記述するファイル形式は、プログラミング言語としてカウントされます（ ここ を参照）。 Regular Grammars や Pushdown Automata のように、Turing Completeの下にも他の複雑なレベルがあります。
別の見方をすると、多くの設定ファイルはデータのマークアップしかできないが、適切なプログラミング言語は algorithms を実装できる必要がある。たとえば、JSONは構成ファイル形式ですが、ECMAスクリプトはプログラミング言語です。
私は設定ファイルについて別の哲学を持っています。アプリケーションの実行方法に関するデータそれでもデータであるため、コードではなくデータストアに属します（構成ファイルIMOはコードです）。エンドユーザーがデータを変更できるようにする必要がある場合、アプリケーションはそのためのインターフェースを提供する必要があります。
私はデータストアを指すために設定ファイルのみを使用しています。
これが私の考えです。
アプリケーションの実行時の動作を簡単に変更できるようにするため。これは、必要に応じて、プログラマーまたは非プログラマーが行うことができます。これは開発中の可能性もありますが、私は多くの場合、構成ファイルを、プログラムをより柔軟にするための方法と見なしています。
はい。ランタイムのさまざまな動作を制御するためにさまざまなオプションが必要になる可能性があるという制約があるため、構成ファイルはできるだけシンプルにする必要があると思います。私は構成設定をグループ化し、それらをできるだけ単純化することを好みます。
変更の内容と理由によって異なります。ユーザーが変更する場合は、フロントエンドを作成して詳細から非表示にする必要があります。同じことは、開発者以外の一般にも当てはまることがよくあります。
私はしばしば「デフォルト」構成をソース制御しますが、実際のランタイムのためにシステムごとにこれをオーバーライドする方法があります。
ロジックを構成ファイルに追加することに関しては-私はこれを避けます。アプリケーションのロジックで構成ファイルを切り替えるだけの方が良いと思います。設定ファイルの動作は、私の経験では、保守性と理解の欠如につながります。設定ファイルはできるだけシンプルにすることを強くお勧めします。
私はこの質問の前提に同意する傾向があります。これが起こることを早期に予測することで、私はトラブルに巻き込まれるのを避け、したがってnever自分の構成システムをロールします。
- オペレーティングシステムの構成機能（plist、gconf、または適切なものなど）を使用するか、
- または、単純なフラットファイル。既製のINIパーサーのようなもので処理できます。
- 弾丸を噛んで、軽量の言語パーサー（通常はlua）をアプリケーションにプラグインします。
- または、SQLiteまたは同様のリレーショナルデータベースにデータを保存します。
そして、自分で辞任して、私が下した決断で生きるか、できなければ、アプリケーションに適した上記の選択肢のいずれかを使用するようにリファクタリングします。
ポイントは、自作の構成ソリューションを使用する理由は本当に何もないということです。 1つには、アプリケーション固有の新しい構成形式を学習する必要があることは、ユーザーにとって困難です。もう1つは、既製のソリューションを使用するときに無料で提供される多くのバグ修正とアップデートのすべてからメリットを得られることです。最後に、機能のクリープを停止します。これは、実際には大幅なオーバーホールを行わずに機能を1つ追加することはできないため、構成システムが最初から手に入るわけではないためです。
それは、チームの他の開発者とあなたが何に同意するかに依存します。構成ファイルを構成ファイルと同じように使用していますか、それとも Model Driven アプリケーションを作成していますか？.
設定ファイルがプログラミング言語になる症状：
- 名前=値のペアは互いに依存し始めます
- フロー制御が必要だと感じている（例if（this）よりも）
- 設定ファイルのドキュメントは、（アプリケーションを使用するだけでなく）さらなる開発を行うために不可欠になります。
- 設定の値が読み込まれる前に、いくつかのコンテキストが必要です（つまり、値は設定ファイル自体の外部の何かに依存します）
設定ファイルは常に、醜く非論理的な「本格的なプログラミング言語」になる道を歩みます。優れたプログラミング言語を設計するには芸術とスキルが必要であり、プログラミング言語から設定言語に変わったものは恐ろしいものになりがちです。
良いアプローチは、pythonまたはRubyのようにうまく設計された言語を使用し、それを使用して [〜＃〜] dsl [〜＃〜] を作成することですこうすることで、構成言語は表面上は単純なままですが、実際には本格的なプログラミング言語になります。
私はpython設定ファイルがあるプログラムisコードを見てきました。特別なことをする必要がない場合（条件など）は、あまり見えません他の構成スタイルとは異なります。たとえば、ファイルconfig.pyのようなもの：
num_threads = 13
hostname = 'myhost'
（たとえば）INIファイルと比較して）ユーザーの唯一の負担は、文字列の周りに ''を付ける必要があることです。他のインタープリター言語で同じことを実行できることは間違いありません。必要に応じて設定ファイルを複雑にする無制限の機能を提供しますが、ユーザーを怖がらせる可能性があります。
「流暢なインターフェース」への移行を考えると、あなたの質問は非常に関連があると思います。多くの開発者は、XMLで構成されたアプリケーションに関して「光を見て」います。 XMLの使用は非常に冗長で、正しく編集するのが難しい場合があります（特にスキーマが提供されていない場合）。流暢なインターフェイスを使用すると、開発者は、プレーンテキストの構成ファイル（またはコマンドラインパラメーター）のキーと値のペアを利用して、ドメイン固有の言語でアプリケーションを構成できます。また、テストなどのために、アプリケーションの新しいインスタンスを簡単にセットアップして構成することもできます。
ここにあなたの質問に対する私の答えがあります：
- 設定ファイルの真の目的は何ですか？
構成ファイルは、ユーザーが実行時にプログラムの動作をカスタマイズできるようにする方法です。
- 設定ファイルをシンプルに保つように試みるべきですか？
理想的には、プログラムを構成するために、構成ファイルは少なくとも流暢なインターフェイスで補足する必要があると思います（これは多くの点で便利です）。設定ファイルが必要な場合は、キーと値のペア以外は何もないシンプルなものにしてください。
- それらに変更を加える責任があるのは誰ですか（開発者、ユーザー、管理者など）？
これに対する答えはあなたの組織に依存すると思います。ソフトウェアが適切に構成されていることを確認するのは、ソフトウェアを展開する担当者の責任です。
- それらはソース管理されるべきですか（質問3を参照）？
私は他の誰かからこの答えを盗みます:)テンプレート構成をソース管理に保存し、各ローカルユーザーのニーズに合わせて変更するというアイデアが好きです。 1つの開発者の構成ファイルが別の開発者の悪夢である可能性があるため、ユーザーごとに異なるものはソース管理から除外するのが最善です。テンプレートを用意することは、アプリケーションをデプロイする人（または他の開発者）が設定ファイルに有効な値を正確に確認できる良い方法でもあります。
はい、設定ファイルは単純でなければなりません。それら自体は「ロジック」を含むべきではありません-それらを条件文全体ではなく、if文の式のリストと考えてください。
これらは、アプリケーション内にコーディングされたオプションのどれを使用するかをユーザーが決定できるようにするためにあります。そのため、それらを複雑にしようとしないでください。自己破壊的な結果になります-単純な構成ファイルを作成してしまう可能性がありますそれ以外の場合は、元の構成ファイルの構成方法を制御します！
マイクロソフトでの「オスロ」作業の目的の1つは、この問題の解決を許可することです（必須ではありません）。
- アプリケーションには、含まれる新しいコンポーネントのモデルが付属しています。既存のモデルも使用します。たとえば、Webサービスが含まれる場合があるため、Webサービスのシステムモデルを再利用できます。
- モデルには、それらを説明するメタデータが含まれます。これには、ツールがテキストまたはグラフィックでアクセスするための十分な情報が含まれます。
- モデルの一部は「構成」に対応します
これは、今日の構成ファイルに相当するものが、構成のテキスト編集とグラフィカル編集の両方をサポートするのに十分なほど豊富であることを意味します。グラフィカルツールは、「Oslo」（コード名「Quadrant」）で提供されます。
私は逆張りするつもりで、XMLで表現できる以上のものを具現化する場合にのみ、それが言語であると送信します。または、XMLが言語と見なされる場合。
または、ほとんどの設定ファイルはクラスと考えることができますが、プロパティのみがあり、メソッドはありません。そしてメソッドがなければ、それは言語だとは思いません。
結局のところ、「言語」はフワフワした抽象概念ですが、はい、エッジがあいまいです。
アプリケーションのコードはそれほど重要ではなくなります...スクリプトがあり、クラス、メソッド、メソッド引数、およびプロパティの動作を定義するあらゆる種類の属性があります。ユーザーは、データベーストリガーとデータベース制約を定義できます。非常に複雑な構成ファイルが存在する可能性があります。私たちのシステムはオープン（SOA）である必要があるため、ユーザーはXSLTスタイルシートを定義して入出力を操作できる場合があります。また、BizzTalkのように複雑な構成が必要なものもあります。ユーザーは複雑なワークフローを定義できます。
この複雑な環境に対処するには、より優れたコードを記述する必要があるため、アプリケーションのコードがより重要になります...
構成ファイル：「私の目的は何ですか？」
あなた： "バターを設定します。"
構成ファイル： "OK ..."
構成ファイル：「私の目的は何ですか？」
You： "バターを設定しました。"
構成ファイル：「オーマイゴッド」
設定ファイルには「本当の目的」はありません。アプリケーションにとって意味のあるものは何でも。一般に、マシン間で異なる（または異なる可能性がある）もので、アプリケーションの実行中に変更されないものは、おそらく構成ファイルにあるはずです。他のサービスのデフォルト、ポート、およびアドレスはすべて、優れた候補です。キーとシークレットも優れた候補ですが、セキュリティ上の理由から、通常の構成とは別に処理する必要があります。設定ファイルの目的が迅速な変更を可能にすることであることに私は同意しません。目的は、アプリケーションのセットアップに柔軟性を持たせることです。構成ファイルがその柔軟性を可能にする迅速で簡単な方法である場合は、はるかに優れていますが、構成ファイルを頻繁に使用することをしないでください変化。
はいといいえ。アプリケーションのコードを単純にすることを試みるべきですか？はい。書くすべてのことをシンプルかつ要領よくするように努めるべきです。必要以上に複雑になることはありません。同じことがあなたの設定にも当てはまります。ただし、これは非常にアプリケーション固有です。構成が「複雑すぎる」ため、構成内にあるべきものをハードコーディングするのは悪い設計です。実際、「物事をシンプルに保つ」ことを試みることが、構成ファイルが最終的に大混乱になる理由です。時々、最も簡単な動きはモジュール化することです。これが、設定ファイルを、ひどい設定言語ではなく、よく知られた汎用プログラミング言語で書く必要がある理由です（read： all "configuration languages" suck ）。
繰り返しますが、誰が設定ファイルを変更すべきかは完全にアプリケーションに依存しています。しかし、私はミニクォークに同意します。アプリケーションを展開する人は誰でも構成を担当する必要があります。
あなたができるすべてをソース管理します。ソース管理は素晴らしいです。ものを簡単にロールバックでき、加えた変更の完全な履歴と、誰がそれらの変更を行ったかの記録があります。なぜでしょうか？
私はpythonプログラムを構成ファイルとして使用すること、特にデーモンの場合）の大ファンです。「構成ポート」を除いて、デーモンを構成から完全に空にすることに取り組みたいと思います。 pythonプログラムは次にデーモンに接続し、デーモン内にオブジェクトを作成し、それらをワイヤリングして目的の構成を作成します。すべてがセットアップされたら、デーモンをそのままにして実行できます。もちろん、利点は、設定ファイルを書き込むための本格的なプログラミング言語を入手できることと、別のプログラムからデーモンと通信する方法がすでにあるため、デバッグと統計の取得にそれを使用できることです。欠点は、いつでも入ってくる別のプログラムからのメッセージを処理する必要があることです。