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

Question 1

私はしばらくの間、構成ファイルとコードとの関係について検討してきましたが、日によって、風の方向によっては、私の意見が変わったようです。Lispの学習中に最初に得た気づきにどんどん戻っていきますが、データとコードにはほとんど違いがありません。これは、構成ファイルについても二重に当てはまるようです。右から見ると、Perlスクリプトはperlの構成ファイルにすぎません。これは、QAや、構成ファイルの変更を担当する必要がある人のような分業などのタスクにかなり重い結果をもたらす傾向があります。

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

準備ができたので、次は私の質問です。

設定ファイルの真の目的は何ですか？
設定ファイルをシンプルに保つように試みるべきですか？
それらに変更を加える責任は誰にあるべきですか（開発者、ユーザー、管理者など）？
それらはソース管理されるべきですか（質問3を参照）？

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

プログラマーでない人が大きな動作のチャンクを素早く変更できるようにするため
はい、ざらざらしていないものはすべてコードに含める必要があります
ユーザーは構成ファイルを担当し、プログラマーは構成ファイルとコードの間の構成層を担当して、アプリケーションをより細かく制御する必要があります。
いいえ、しかしより細かい中間層は

Question 2

非常に興味深い質問！

私は、構成ファイルをすぐに本格的なプログラムにすることができることについて、私が完全に同意しているため、構成ファイルを非常に単純な "key = value"形式に制限する傾向があります。たとえば、OpenSERを「構成」しようとしたことのある人なら誰でも、あなたが話している感覚を知っています。それは構成ではなく、（苦痛な）プログラミングです。

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

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

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

アプリケーションをインストールする人が、ホスト名、スレッド数、必要なプラグインの名前、それらのプラグインのデプロイメントパラメータなど、いくつかのデプロイメント関連パラメータを週にできるようにするには、この原理の例としては、FreeRadiusの構成を参照してください）など。ビジネスロジックを表現する場所は間違いありません。
設定ファイルをシンプルに保つように試みるべきですか？

間違いなく。あなたが示唆したように、設定ファイルの「プログラミング」は恐ろしいです。避けるべきだと思います。
それらに変更を加える責任は誰にあるべきですか（開発者、ユーザー、管理者など）？

一般に、アプリケーションをデプロイする管理者と言います。
それらはソース管理されるべきですか（質問3を参照）？

私は通常、設定ファイル自体をソース・コントロールしていないが、私はない、すべてのパラメータとそのデフォルト値を持つテンプレートコンフィギュレーションファイルを、ソース・コントロール、およびコメントは、彼らが何を記述する。たとえば、構成ファイルがという名前のdatabase.conf場合、私は通常、という名前のファイルをソース管理しますdatabase.conf.template。もちろん今、私は開発者として何をしているのかについて話しています。 管理者として、各インストールで選択した実際の設定をソース管理したい場合があります。たとえば、数百台のサーバーをリモートで管理し、それらの構成を追跡する必要があります。これをソース管理で行うことを選択しました。

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

Question 3

OK。あなたは本当にシンプルな設定を望んでいるユーザーがいるでしょう、あなたは彼らにそれを与えるべきです。同時に、「これを追加できますか？構成ファイルでどうすればよいですか？」という絶え間ない要求がありますが、両方のグループをサポートできない理由がわかりません。

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

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

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

Question 4

最近私はプロジェクトに取り組んでいて、構成ファイル内に条件文を入れたいと思っていました。


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
}

これにより、ユーザーが動的構成ファイルを使用したい場合に威力を発揮し、独自のミニ言語を記述する必要がないという単純さを実現します。

Question 5

すべての（存続期間が長い）構成ファイルスキーマは、最終的にプログラミング言語になります。あなたが説明するすべての含意に起因して、config-file設計者は、彼女がプログラミング言語を作成し、それに応じて計画していることを認識して、将来のユーザーに悪い遺産を負わせないようにするのが賢明です。

Question 6

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

私はデータストアを指すために設定ファイルのみを使用しています。

Question 7

計算理論に目を向けると、プログラミング言語として数えるものを定義できます。構成ファイルの形式がTuring Completeの場合、それはプログラミング言語として合理的にカウントされます。この定義により、倉庫番のレベルを記述するファイル形式は、プログラミング言語としてカウントされます（ここを参照）。通常の文法やプッシュダウンオートマトンなど、Turing Completeよりも下にある他のレベルの複雑さもあります。

別の見方をすると、多くの設定ファイルはデータマークアップしかできないのに対し、適切なプログラミング言語はアルゴリズムを実装できる必要があります。たとえば、JSONは構成ファイル形式ですが、ECMAスクリプトはプログラミング言語です。

Question 8

これが私の考えです：

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

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

Question 9

私はこの質問の前提に同意する傾向があります。私はこれが起こることを早期に予測することでトラブルに巻き込まれるのを避け、それゆえ私自身の設定システムを決してロールしません。

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

そして、自分で辞任して、私が下した決断を生きるか、できなければ、アプリケーションに適した上記の選択肢のいずれかを使用するようにリファクタリングします。

ポイントは、自作の構成ソリューションを使用する理由は本当に何もないということです。1つには、アプリケーション固有の新しい構成形式を学習する必要があることは、ユーザーにとって困難です。もう1つは、既製のソリューションを使用すると無料で提供される多くのバグ修正と更新のすべてのメリットを得られることです。最後に、機能のクリープが停止します。これは、実際には大幅なオーバーホールを行わずに機能を1つ追加することはできないため、構成システムが最初から手に入るわけではないためです。

Question 10

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

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

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

Question 11

設定ファイルは常に、醜く非論理的な「本格的なプログラミング言語」になる道を歩みます。優れたプログラミング言語を設計するには芸術とスキルが必要です。構成言語からプログラミング言語への変更は恐ろしい傾向があります。

適切なアプローチは、PythonやRubyなどの適切に設計された言語を使用し、それを使用して構成用のDSLを作成することです。そうすれば、構成言語は表面上は単純なままですが、実際には本格的なプログラミング言語になります。

Question 12

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

ここにあなたの質問に対する私の答えがあります：

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

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

設定ファイルをシンプルに保つように試みるべきですか？

理想的には、プログラムを構成するために、構成ファイルは少なくとも流暢なインターフェースで補足する必要があると思います（これは多くの点で便利です）。設定ファイルが必要な場合は、キーと値のペア以外は何もないシンプルなものにしてください。

それらに変更を加える責任は誰にあるべきですか（開発者、ユーザー、管理者など）？

これに対する答えはあなたの組織に依存すると思います。ソフトウェアが適切に構成されていることを確認するのは、ソフトウェアを展開する担当者の責任です。

それらはソース管理されるべきですか（質問3を参照）？

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

Question 13

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

num_threads = 13
hostname = 'myhost'

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

Question 14

はい、設定ファイルは単純でなければなりません。それら自体には「ロジック」を含めないでください。それらは、条件ステートメント全体ではなく、ifステートメント内の式のリストと見なしてください。

それらは、アプリケーション内にコーディングされたオプションのどれを使用するかをユーザーが決定できるようにするためにあります。そのため、それらを複雑にしようとしないでください。最終的に自己破壊的になり、単純な構成ファイルが作成される可能性があります。それ以外の場合は元の構成ファイルをどのように構成するかを制御します！

Question 15

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

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

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

Question 16

私は逆張りするつもりで、XMLで表現できる以上のものを具現化する場合にのみ、それが言語であると送信します。または、XMLが言語と見なされる場合。

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

結局のところ、「言語」はフワフワした抽象概念ですが、そうです、エッジは曖昧です。

Question 17

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

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

Question 18

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

Question 19

設定ファイル：「私の目的は何ですか？」
あなた：「バターを設定する」
設定ファイル：「OK ...」
設定ファイル：「私の目的は何ですか？」
あなた：「バターを設定します。」
設定ファイル：「ああ、なんてことだ」

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