言い方がよくわかりませんが、やってみます。
プログラムの一部に設定があり、80％は二度と変更する必要がないと確信しているとします。変更可能なコードのどこに線を引くかをどうやって知るのですか？設定をユーザー定義のXMLファイルに完全に反映させるのはやり過ぎです。ただし、これらの設定を後で変更する必要がある可能性がわずか20％あることもわかっているため、ゴムが道路に接する場所でコーディングすることも最適ではありません。
私が尋ねようとしているのは、抽象化ツリーのどこまでプログラムを簡単に変更できるようにするべきかということだと思います。
多くの例の1つは、WebサイトのHTMLコードを手動で作成するのではなく、プログラムで自動的に生成することです。HTMLコードを直接書くのにそれほど時間はかかりません。HTMLコードを自動的に生成するプログラムを作成すると、はるかに時間がかかります。
これは良い質問ですが、絶対的な答えはありません。
アインシュタインが指摘したように：
できるだけシンプルにしますが、シンプルにしないでください。
シンプルさは相対的です。設計における抽象化レイヤーの量について最善の決定を下すことが、優れたアーキテクトを優れたものにします。優れたアーキテクトは、常に特定の状況を評価し、最善のトレードオフを行う必要があります。銀の弾丸はありません。
私はこれを試してみます。私の哲学は次のとおりです。
1 - 構成ファイルとパーサー クラス/関数を非常に単純化してできるだけシンプルに保つことで、何かが必要になったときに、途方もなく肥大化した XML クランチ構成ファイルをインスタンス化することなく、いつでもそれを取得できるという安心感が得られます。パーサー。私の設定ファイルは次のようになります。
DBHostname -> XX.XX.XXX.XX
DBUsername -> foomonger
DBName -> fooDb
DBPassword -> xxxxx
ImageUploadsDir -> /uploads/images/
...
そこから必要なものを抽出するには、静的ヘルパー メソッド (小さなアプリ) またはシングルトン インスタンス (大規模な MVC 駆動型アプリ) を使用します。このバカな友人の ConfigHelper は頭が悪く、オーバーヘッドの生成方法を知りません。
私は平均的な勤務日に何度かこのジレンマに悩まされています: これを config.txt に入れるべきですか、それともクラス定数にするべきですか? 私の答えは、私にはわからないということです-ずっと後まで。構成ファイルに入れる必要があることが判明した場合、参照を変更するための安定した「プロジェクト内の検索と置換」実装を備えた適切な IDE に勝るものはありません。
3 - 開発にテスト サーバーとそれに続く本番環境への展開が含まれる場合、構成ファイルはアプリケーションの展開から悪夢を取り除きます。実際に実用的な代替手段はありません。私が理解している世界では、異なるマシン上の異なるデータベースインスタンスは異なる IP を持っています。
多くの例の 1 つは、Web サイトの HTML コードを手動で記述することと、プログラムに自動的に生成させることです。
信用できる。私たち開発者はマシンの構築を楽しんでいますが、最初に構築するつもりだったマシンを構築するために、マシンの構築に多くの時間を浪費する傾向があります。これは非常に喜ばしいことではありますが、経験上、ほとんどの状況では、所有するマシンの数が増えるほど、サポートする必要のあるシステムの数が増え、障害点が増え、ビジネス オーナーからより多くの非難を受けることになると断言できます。それは楽しくありません。さらに、中間の HTML ジェネレーターが目的の出力を生成できない状況に遭遇する傾向があります。では、ジェネレーターのバグを修正するのに時間を浪費するか、ブードゥー教の回避策を考案するのに時間を浪費するか、単に HTML を手書きするか、何をしますか? 状況にもよりますが、私は後者の方が好きです。
ちょっとした暴言でしたが、少なくとも少しはあなたの質問に答えるのに役立つことを願っています.
過去 4 年間で、この老犬は TDD の新しいトリックを学びました。「本当の」TDD をする時間がないときでも、そうしているふりをします。
だから私はいつも重複したコードを書いています。私はいつも後でリファクタリングするので、これは問題ありません。これはコードを記述するプロセスの一部であり、後で行うものではありません。私は TDD に従い、必要最小限のコードしか書いていないので、コードが機能することを証明する自動化されたテストがあるので、重複が見つかった場合は、テストを再度実行することを知っているので、安心してコードをリファクタリングできます。リファクタリング中およびリファクタリング後。これは、私が何も壊していないことを再び証明します。
このようにして、コードが再利用されるかどうかについて推測しません。再利用されるまでリファクタリングはしません。インスタンスのニーズに応じてインスタンスごとに作成されるため、コードの呼び出し元がコードを汎用化したいという欲求に惑わされていないことがわかります。単体テストを含む呼び出し元は、差し迫ったニーズを満たすように作成されました。個別のリファクタリング パスは、コードを複製しないという幅広いニーズに対応します。
2 つのポイント:
あなたの質問は、変数を構成ファイルに入れるか定数に入れるかよりも、実際のコード設計を対象としていました。それらの点に関する他の回答に同意します。
しかし、一般化されたコードを書くかどうかについて...
私の経験では、目の前のタスクを処理するために特別にコードを作成すると、将来のある時点で同様のコードを作成することになります。タスクを 1 回だけ実行する場合は、問題ありません。しかし、ほとんどの場合、そうではないことがわかりました。
タスクを繰り返していることに気付いた場合は、一歩下がって、一般的な方法でそれを自動化するにはどうすればよいかを検討する必要があります。
また、誰かがまだそれを行っていないことを確認してください。まだ公開していない場合は、コードがどんなに小さくても粗くても、コードを公開することを検討してください。誰かがあなたのために無料で改善してくれるかもしれません。
80% ? ハードコードするのに十分ではありません。構成ファイルに入れます。
100% ? 定数で十分です。