XP方法論の開発の初期段階で採用されたアプローチから始まり、設計とアーキテクチャはアジャイル開発の動的に発展する世界では場所を持たない恐竜であると考えられていたため、設計段階に対する態度は非常に異なる可能性があります。 多くの人々は、反復的な開発プロセスとリファクタリングが私たちのためにすべてを行い、良いデザインがそれ自体で現れると信じて、現在ソリューションデザインについても考えていません。
チームが完璧なソリューション（建築家の聖杯）の検索に数週間費やすことができる場合、設計があらゆる方向に「拡張」でき、実装する方法がないほど「柔軟性」が高い場合、もう1つの極端なケースがあります。
これらの両極端を観察することは興味深いですが、それがチームで発生しない場合のみです。 ほとんどの場合、設計と開発の段階が密接に関連しており、ほぼ連続的に繰り返し実行される場合、設計に対する合理的な態度はその中間のどこかにあります。 さらに、開発者が決定に直面するたびに、彼は自分に圧力をかける無数の要件の中から妥協点を見つけようとします。より効率的なソリューションまたはより拡張可能なソリューションを使用します。 さらに重要なのは、一貫性または重大な変更。 SRP（単一責任原則）に違反する方法、またはモジュールをより使いやすくする方法。 効率などのためにコードの保守性を犠牲にする価値はありますか？
その結果、ほとんどの開発者は...
デザインとは、多くの相反する目標や要件の中で妥協点を見出す技術であり、その重要性は時間とともに変化する可能性があります。
コンテキストは重要です
私は本/記事の多くの著者または単に絶対的な形で意見を述べる同僚のカテゴリー性に多少悩まされています：シングルトーンを決して使用せず、テストカバレッジは100％でなければならず、オープンフィールドは世界的な悪です。 このようなステートメントの問題は、ほとんどの場合それらが非常に正しいことですが、これはこれらのヒントがためらうことなく盲目的に信じられることを意味しません。
はい、ほとんどの場合、オープンフィールドは本当に危険なプラクティスですが、だれが既存のシステムとやり取りするために構造（重要なタイプの.NET）でそれらを使用することを妨げますか？ はい、ユニットテストは素晴らしいことですが、100％のテストカバレッジがなければプロジェクトが失敗するわけではありません。 まさにこの理由で、経験豊富なプログラマーが「何が良いですか？」という質問をされた場合、「賢明な唐辛子」はそれを「真正面から」答えず、解決される問題のコンテキストを理解するために明確な質問をしますか？ 結局、ある場合に適用するのに合理的であるもの（量産コードの単体テストを書くこと）は別の場合にはまったく不要かもしれません（1日のプロトタイプについて話している場合はどうでしょうか？）。
同じ理由で、他の人の決定を非難することが非常に多く、この決定の質は1秒あたりのWTFの量によって測定されることがよくあります。 しかし、実際には、それが採用された条件に関する十分な情報がない場合が多いのです。 例は次のとおりです。C＃では、配列の共分散と呼ばれる過度に疑わしい可能性があります。 これは、次のコードスニペットが正しく、コンパイルではなくランタイムエラーが発生することを意味します。
object[] o = new string[] {“1”,”2”, “3”}; o[0] = 42;
この機能の理由は、Java言語の最初のバージョンからのものであり、90年代後半にC＃言語を開発する際、既存のプログラマを新しい言語に「フック」することの重要性が決定的でした。 そのため、通常のCライクな構文が使用されます。これは、たとえ欠点があったとしても、C / C ++およびJavaプログラマーにはすでによく知られています。 そのような決定は今では疑わしいように思えるかもしれませんが、採用に至った理由（他の言語との一貫性とランタイムエラーの可能性）を理解することで、言語またはライブラリがこのように実装され、そうでない場合に、なぜ開発に影響するのかが明らかになります
他の誰かの決定を絶対的なカテゴリーで判断することは不可能です。決定を正しく評価するには、どのような制限が行われたかというプレッシャーの下で理解する必要があります。
さて、あなたは言いましたか？!!
彼らはあなたに何回言った：「ねえ、あなたはあなた自身がこれを行う必要はないと言ったが、あなたはそれを自分で行う！」または別に！」 問題は、時間の経過とともに決定が変わることです。 時間が経つにつれて、いくつかの基準（コード効率）の重要性が低下し、他の基準（アーキテクチャの一貫性と保守の容易さ）の重要性が増加する場合があります。
誰かに何かを証明するためだけに、私の決定を最後まで守ることはありません。新しい事実が現れたとき、または既存の基準の重みが変わったとき、私の態度は変わります。 これは、要件を指定するとき、またはこの特定のケースでは保守性や使いやすさを犠牲にするよりも生産性が重要であることが明らかになったときに常に発生します。 また、決定自体がタスクに大きな影響を与える可能性があるため、元のソリューションは認識できないほど変化します。
良いデザイン
開発者がそれを達成するために行かなければならないパスが複雑であるように、良いデザインの定性的特性を決定することは困難です。 私たちのほとんどは、特にこのデザインの作者が他の誰かである場合、デザインに問題があります。 主にソリューション全体が頭の中にあり、設計のあらゆる側面が明白であるため、独自の設計で問題を定義することはより困難です。
設計上の問題を見つけるのに最適な方法は、自分で横から見るか、誰かに説明することです。 良いデザインとは、完全性や正確性を犠牲にすることなく、同僚に10分で説明できるデザインです。 「どのように機能するか」を説明する際に、多くの要因を考慮し、多くの詳細を掘り下げ、同じことを15回繰り返さなければならない場合、明らかに設計に問題があります。 多くの場合、優れた設計は非常にシンプルであり、複雑さを最小限に抑え、不要な接続または明白でない接続を最小限に抑えます。 優れたアーキテクチャのような優れた設計は、固有の複雑性と戦いますが、解決される問題の本質において既に過剰になっている追加の複雑性を導入しません。
形式性と設計の質の高さは、間違いのコストとそれを修正するコストとの妥協点でもあります。 2つのモジュール間のインターフェイスが多かれ少なかれ定義されている場合、このインターフェイスを理想に近づけるのではなく、実装に移行することは非常に可能です。
良いデザインはそれ自体が目的ではないため、完璧なソリューションを追求する必要はありません。 他の多くのものと同様に、常識とプラグマティズムはあなたの最高のアドバイザーです。
-
記事の途中で与えられたデザインの定義は、エリック・リッパートの考えを自由に翻訳したものです（彼の投稿の 1つで表現しました） 。 デザインとは、互換性のないさまざまなデザイン目標の間で妥協する技術です。