柔軟性を高めるために、事前に、または必要に応じて、基盤となるアーキテクチャを作成する必要がありますか？
この質問で 私は尋ねました：疎結合を可能にするために、より多くのレベルの抽象化を設計するコストは、利益に見合う価値がありますか？
多くの場合、コストに見合う価値があると言われていますが、アプリケーションが実際にこの基礎となる設計を後で使用するのか、それとも時間の無駄になるのかを理解する必要があります。
私の新しい質問は：
柔軟性と保守性を可能にするインフラストラクチャを作成する必要があります事前に-したがって、既存のインフラストラクチャと抽象化レベルで開発されるため、開発を「よりクリーン」で「組織化」する必要がありますか？
このアプローチでは、後で実際にどのように実装されるかについてあまり知識がなくても、基盤となるインフラストラクチャを設計します。したがって、後で使用されない可能性のあるものをコーディングしていて、時間を無駄にしている可能性があります。しかし、開発はよりクリーンで組織化されます。
または、柔軟性を高め、物事をより疎結合にするためのインフラストラクチャを作成する必要があります中何かの実装-したがって、後で実際に使用されない可能性のあるものに費やす時間を減らすことができますか？
このアプローチでは、使用されないものをコーディングすることはできませんが、基礎となる抽象化レベルと設計を設計する必要があります既存のコードの場合したがって、基礎となる設計をコーディングする代わりに、既存のコードを変更しますbeforeこれらのデザインを使用するコードをコーディングします。
アプローチ1の例： "さて、アプリケーションのこの比較的大きな部分の作成を開始します。この部分は通常、いくつかのGUIへの反応に関係します。基本的なレベルの抽象化を作成しましょう。プログラムのこの部分。後で実装するときに使用します。」
アプローチ2の例： "さて、私はプログラムのこの部分を設計している最中です。作業している間、この部分は疎結合であることがわかります。次のレベルの抽象化を作成しましょう。それを許可し、そのレベルの抽象化を使用するようにこのコードを変更してください。」.
どちらのアプローチがより理にかなっていますか、またはより一般的ですか？
率直に言って、両方。
すべてのコードが記述され、数十の場所で結び付けられた後、抽象化レイヤーを追加することはほぼ不可能です。悲しいことに、すべての抽象化レイヤーを取得することもほぼ不可能ですちょうどいい実際にそれを実行して、物事がどこに行くのかを見ずに。
したがって、実際には、両方を実行することになります。最初に抽象化を追加して、柔軟性と過剰設計の境界線を越えようとします。必要になる可能性が非常に高い場合、または推測が間違っている場合に壊滅的となる場合に、柔軟性を作成します。簡単に言えば、リスクを軽減します。
次に、時間の経過とともに抽象化を追加または削除します。リファクタリングは、コードを「適合」させるための鍵です。物事が複雑すぎることに気付くことがあります。時々あなたは物事があまりにも結合していることに気付くでしょう。時間の経過とともにクリーンアップします。
どれだけが「十分」であるかについてのこの種の感覚、そしてwhereその抽象化が存在することは、デザインを作成し、それらがどのように成功するか（またはより頻繁に失敗するか）を確認するにつれて時間とともに発達する重要なスキルです。
アプローチ1には反対することをお勧めします。コードの記述は発見のプロセスです。敵との接触を乗り切る計画がないのと同じように、すべての設計には、実装を開始したときにのみ検出される欠陥があります。さらに、任意の数の方向とレベルで何でも抽象化できます。あまりにも多くの「what-if」用に設計すると、アーキテクチャがニーズに合わなくなります。十分に理解すると、 Greenspunの10番目のルール または 内部プラットフォーム効果 （考えてみてください-すべてがカスタマイズ可能であれば、何ができるか）のようなばかげたものになってしまいます。左はプログラミング言語です。）
その上、移動するターゲットを追いかけています（要件の変更）。奇跡的にデザインを正しくnowにしたとしても、あなたが言ったように、それが後で関連するという保証はありません。
要するに、それは滑りやすい坂です。それはすぐに価値を提供するわけではなく、間違った方向にあなたを導く可能性が高いです。
Pythonコミュニティには、「Guido's Time Machine」というすばらしいアーティファクトがあります。つまり、Pythonで構文とメカニズムを設定する際の、Guido VanRossumの先見性に多くの人が驚いています。これは、時間の経過とともに非常にクリーンで直感的に機能することが証明されました。
ただし、誰もがタイムマシンを持っているわけではなく、要件を予測するのは難しい場合があります。
アジャイルでは、ルールは「要件に近いプログラム」です。 TDDでは、これは「機能する最も単純なソリューション」です。
ただし、ブルートフォースの実装と、将来の要件を予測するための抽象化の間にはバランスがあります。
私見では、a）クリーンで柔軟で拡張可能なコードを提供するために、Niceの抽象化に注意を払い、b）プロジェクトを実際にはそうではない過度に一般化されたインフラストラクチャの沼に変えることに注意することが重要です何でも。
多くの時間、私は私の副次的なプロジェクトで私の暇な時間に心の広いものに取り組みます。しかし、エンジニアが、経験のレベルを問わず、世界の問題を解決するためのメカニズムに興奮したとき、私はまだ会議でひるむ。
結局のところ、機能を顧客の前に置いていることを確認してください。ただし、対象を絞ったアプリケーションを使用して、抽象化の力を鋭く保ちます。