設定で共通設定を上書きするようなコードだったとします。以下のようになるでしょう。設定を確認しようと思ったら、両方の設定を確認しなければならないことがほとんどです。上書きされてる可能性があるからです。開いて確認しても、欲しい設定が書いてあるとは限りません。設定を確認した限り問題ないはずなのに、なぜかプロダクション環境でエラーが起きる」ということが起こります。上書きしていることは忘れがちです。ある設定を書き換える場合、全ての設定ファイルを開き、全体の設定がどうなるかを相互に眺めながら確認する必要があります。書き換えて問題ないかどうかを判断するために、全ての環境で最終的にどうなるかを見る必要があるからです。手間が掛かるため「ある環境では問題なくても、ある環境では問題がある設定にしてしまう」ということが起こります。いう結論に至りました。書いて良いと思います。以下のように書くのがいいでしょう。外に書いても構わない。中で上書きしないように注意する必要がある。2000endこの設定ファイルは、以下のルールに従って書かれています。分岐する環境ごとのパターンマッチでワイルドカードを使わない同じ設定を絶対に上書きしないこのルールに従って書けば、書き換えて問題ないかを判断するのに時間が掛かったり、書き換えた項目が反映されなかったり、書き換えた範囲が大きすぎて他の環境で影響が出るといった問題はかなり少なくなるでしょう。このように書くのかを、それぞれ説明していきます。同じアプリケーションの設定を一箇所に纏めるあるアプリケーションの設定を確認したり書き換えたりする時、同じアプリケーションの設定が1画面に収まる範囲にあった方が分かりやすいからです。環境ごとに設定ファイルが分けられていた場合、それぞれの設定ファイルを開く必要があるため、確認するだけで大分手間が掛かります。同じ設定は同じ場所にあり、他の場所には決して無いということが分かっていれば、考えることは大幅に減ります。分けるしか無くなります。環境ごとのパターンマッチでワイルドカードを使わない例えば以下のように書いてはいけません。2000endこれは、環境が増えた時に、意図しない設定になってしまうのを防ぐためです。同じ設定を絶対に上書きしないこれは最初に説明した通りです。設定を上書きすると、見なければならない範囲が増えてしまいます。外に書いても構いませんが、確実に上書きしないようにうまくやる必要があります。設定する必要があります。厳密にやるなら、設定ファイルを上書きするコードが入ってたらエラーにした方がいいでしょう。そのような実装にはなっていないし、設定ファイルのロード時に外部ライブラリを読むのは難しいので、人間が頑張る方向で妥協しています。以下のようになります。2000endそれぞれのルールは、小さいアプリケーション向けの設定と同じで、単にアプリケーションごとにファイルを分けただけです。このように書くことで、設定ファイルを間違えて書いてしまう可能性は大分低くなると思います。頑張るなら、これらのルールを人間が頑張って守らなくてもいいようなスクリプトを書いて、それ経由で設定を記述するのがいいでしょう。書く」というやり方は、設定ミスが発生しやすいのでやめましょう。以下のルールに従って書きましょう。分岐する環境ごとのパターンマッチでワイルドカードを使わない同じ設定を絶対に上書きしないまた、ある程度規模が大きくなってきたら、アプリケーションごとに設定ファイルを分けましょう。変わった技術でゲームをつくったりする会社。プログラマだけじゃなく、企画、デザイン、イラストなど開発全般揃ってます。upLoginユーザーは見つかりませんでした。