- 柔軟性が無条件に良いものだと思っているから ―― コードを変更せずに設定ファイルでカスタマイズできるならそっちのほうがいい設計に決まってるよ、という思い込みのある人が多い。実際には、ベタに書けば簡単なものを設定に出すと複雑になることが多いから、これは事実ではないのだけど。
- バイナリのアップデートが面倒だから ―― 運用ポリシーによっては、バイナリの更新はオオゴトだけど設定変更は通常作業みたいな環境がある。そういう環境では、設定にできるだけ多くのものを追い出してインストール後の柔軟性を最大化しようというインセンティブが生じる。さらに、そういうポリシーのもとで育ったエンジニアはそれが常識だと思って内的なベストプラクティスにしてしまっているので、そうではない環境でもついそれを適用してしまう。
- 汎用のサーバプログラムの設定ファイルも難解だから ―― 汎用のサーバプログラムの設定は、オライリーから分厚い本がでるほど難しいものがよくある。ああいうプログラムは様々な環境で使われるから柔軟性を確保するために設定ファイルとプログラムとがああいうふうに分離されているわけだが、自分で自分のためのサーバプログラムを書く場合はあれはお手本にならない。
- 他愛もないものが徐々に恐ろしく複雑なのものに成長してしまうから ―― 大抵「この場合だけこの設定を適用したい」みたいなニーズを満たすために条件分岐のようなものを足すところから複雑化が始まる。条件として書ける式のパターンをもっと汎用的にしたりして、ループや変数もどきをアドホックに足していくと、結果としてひどい出来のスクリプト言語みたいなものが出来てしまうことがある。そういう謎言語（当事者にはプログラミング言語として認識されていない場合も多い）を書くのが辛すぎて設定ファイルを自動生成しようなどという話が出てきたらもう末期だ。関係者全員が次第に複雑化するシステムに徐々に慣らされてしまうので、そういうインクリメンタルな「改善」をどこかの時点で拒否するのは難しい。
- プログラマのモラルハザード ―― 設定は運用任せという体制の場合、プログラマはできる限り設定ファイルに機能を移したほうが仕事が簡単になる。なんでも「原理的には設定ファイルで可能」という状態にしておけば、設定ファイルの難解さから生じる問題も含めてすべて運用の責任ということにできる。運用チームの地位が低い場合には特にこれは問題になる。
設定ファイル問題への究極の解はないと思う。しかし前回書いたように、具体的なユースケースがわかっているのに不要な一般化を行わないほうがいいという話と同じで、やるべきことは大抵の場合コードで素直に直接実装するのがよいと思う。「こんな環境依存の具体的なことはコードで直接書くのではなくて設定ファイルでなんとかならないかな？」という誘惑を感じることは多いが、そういう誘惑はほとんどの場合無用にシステムを複雑化することになるだけだろう。ベタに書いてしまうくらいが正しいバランスだったりすることが多いと思う。