外部構成ファイルはアンチパターンと見なされますか？

多くの場合、私はアプリケーションが明らかに破損している状況にありましたが、外部構成ファイルに欠陥があることがわかりました。通常、これは間違ったファイルが存在するか、不正なデータが含まれていることが原因です。

外部ユーザー/プロセスがアプリケーションのランタイム特性を変更できるようにするより良い方法はありますか、またはこれが問題の最もよく知られている解決策ですか？

Unix /etc やJavaのJNDIなどに焦点を当てるのではなく、一般的なケースについての議論が欲しいです。

ほとんどのアプリケーションでは、いくつかの外部構成が必要になります。マジック変数に依存させるか、内部の場所に保存することで、これを非表示にすることができますが、その必要はなくなりません。目標は、何を外部にすべきか、何を内部にできるかを認識することです。内部部品のみをテストできます。

アプリケーションは、外部構成ファイルが正しいことを信頼してはなりません。正確性をチェックし、エラーを報告します。アプリケーションが構成ファイルをチェックできない場合は、おそらくそれを使いすぎています。構成ファイルがアプリケーションの動作を変更する場合、私の意見ではそれは外部であってはなりません。

たとえば、データベースのユーザー名/パスワードは、データベースに接続しようとすることにより、アプリケーションで簡単に確認できます。これが失敗した場合、それはそれを報告することができ、それは明らかにアプリケーションコードのバグではありません。同様に、ファイルパスの存在とアクセス権を確認できます。

これで、SQLクエリを構成ファイルに入れると、アプリケーションはそれらのクエリの正確さを簡単に確認できなくなります。同じことは、完全な依存性注入仕様（Java-Spring XMLの1つ）ファイルにも当てはまります。それらは外部設定ファイルに含まれるべきではありません。

しかし、指定された構成が外部のものを記述していて、その正しさをすぐに確認できれば、外部構成ファイルに問題はないと思います。

編集：エラーレポートに、使用されている構成ファイルが表示されていることも確認してください。何が問題なのかを見つけようと何時間も試みた後、間違ったファイルを探していたことがわかるほど、イライラすることはありません。

私はそれらをアンチパターンよりも「既知の問題領域」として分類します。固定構成を展開するのでない限り、構成情報をどこかに保存する必要があります。私は通常、ほとんどの構成情報をデータベースに保存するのが好きですが、データベース接続情報をどこかに保存する必要があります。私は、ユーザーのホームディレクトリやWindowsレジストリではなく、アプリケーション構造自体に構成情報を格納するというJava / Springのアプローチを好みますが、それは個人的な好みです。

外部設定ファイルはアンチパターンではありません。他のすべてのように、それらは問題のシステムに応じて上手くまたは下手に使用することができます。

外部設定がユーザーに何が起こっているのかを知らずにアプリを壊すことができるいくつかのアプリに遭遇したようです。それは悪いことですが、それは構成ファイルのせいではなく、構成ファイル内のどの部分がアプリ内にあり、どの部分がアプリ内にあるかを決定した人の責任であり、それらの間のエラーを処理する方法です。

私の意見では、いいえ、外部設定ファイルはアンチパターンではありません。

これは、ソフトウェアの複雑さを管理するための単なるアーキテクチャパターンの手法です。

SOLID設計原則の時代に、ソフトウェアの複雑さをMonolithic_applicationから、一緒に接続する必要のあるより独立したモジュールに移行しました。

「外部設定ファイル」の代わりに、コードでモジュールを直接設定することになります。

どちらかといえば、構成をロジックからデータに移動することをお勧めします。コードを作り直す必要なく、アプリケーションをより柔軟にすることができます。データファイルの欠落は、IMHOのコーディングに関する悪い慣行よりも、インストール時のドキュメントやずさんな作業が少なすぎる場合に当てはまります。

お気に入りのSCMツールをCMツールとしての役割を倍にする：構成ファイルをリポジトリーに配置します。設定を変更するには、変更をコミットし、自動展開ツールにそれらを本番環境にプッシュさせます（もちろん、さまざまな自動テストを実行した後です！）

Et Voila！すべての構成変更の記録に加えて、自動CI /テストシステムの追加のセーフティネットがあります。

以前に指摘したように、アーキテクチャと設計パターンは製品システム自体に限定されず、それを生成するのに役立つチーム/プロセス/システムにまで及びます。