（この注記は、 技術的負債 、 リファクタリング症候群、および2番目のシステムの効果を含む一連の投稿の終わりです。）
設計パターンの利点は何ですか？ （*）まず第一に、実績のあるアーキテクチャソリューションの再利用であり、開発者間のコミュニケーションの簡素化です。 しかし、 デザインパターンに加えて、コーディング、テスト、コード変更（別名リファクタリング）パターン、アーキテクチャパターンなど、他にも多くのパターンがあります。 実際、私たちは本当に新しいことをすることはめったにないので、膨大な数の分野で実績のある標準ソリューションが存在します。 また、開発チームが直面する問題のほとんども多様ではないため、これらの人々の行動も非常に均一です。
「技術的負債」 、 「リファクタリングシンドローム」 、 「セカンドシステム効果」は、開発チームが定期的に遭遇する典型的な状況です。 そして、彼らからの主な利点は、問題を正確に見て、その存在を適切な人々に証明することです。 プロジェクトの技術的負債が大きすぎることに気付いた場合、マネーのメタファーを使用すると、マネージャーまたは顧客にこの問題の重要性を証明するのがはるかに簡単になります。 そして、彼にイベントを開発する別の方法を注意深く示します。（1）すべてをそのままにしておく。 （2）合理的なリファクタリングを通じて技術的負債を削減する;（3）すべてを書き直す。
同様に、過剰な書き換えの欲求や高度なソリューションへの傾向など、開発者の問題について知っている場合、利用可能なリソースを最適な方法で使用するのがはるかに簡単になります。 ある開発者の長所が別の開発者の短所を補うような方法で開発者を組み合わせると、極端になるリスクを減らすことができます。
適切なタスクと合理的なプラグマティズムに適切な人材を使用することに加えて、あらゆる種類のリスクを軽減し、不適切な技術的決定を下すために考えるべきいくつかの考えがあります。
リスク管理とカプセル化
ジョン・ロビンズ 、もしあなたが知らなかったなら、有名なバグスレイヤーになる前に、彼はアメリカ陸軍のグリーンベレー帽を務めていました。 そして、彼自身が認めているように、彼の中で優秀な戦士を認識することは困難ですが、彼はソフトウェア製品の開発とリスクの管理において軍事作戦を計画することから「トリック」を使うことを学びました。
はい、「Vasilyが分析または要件の収集段階を完了する前にVasilyを与えるとどうなりますか？」（**）のような質問があるかもしれませんが、同僚からの拍手ではあまりにも厳しいかもしれませんが、現在の解決策が間違っていることが判明した場合は？」は非常に便利です。
たとえば、データベース、プロセス間通信ライブラリ、DBMS、またはユーザーインターフェイスを作成するためのライブラリとの相互作用のモデルを選択します。 そのような決定を行うたびに、「この決定が誤っていると判明し、それを放棄しなければならない場合はどうなりますか？」と自問するのは場違いではありません。そのようなエラーの影響を最小限に抑える方法と、それがうまくいかない場合はどうなりますか？
このようなエラーのリスクを最小限に抑えるための主なアイデアは、そのようなソリューションを最小限のモジュールにカプセル化することです。 これにより、エラーが発生した場合に変更する必要のあるモジュールの数が最小限に抑えられ、技術的な負債とその後の変更のコストが削減されます。
たとえば、プロセス間通信にWCFを使用することを決定した場合、これは、サービスがすべての穴から突き出て、ビジネスロジックがサービスクラスに直接配置されることを意味しません。 または、サードパーティ製機器での作業用プロトコル、RPCの手動実装などのカスタムインタラクションプロトコルを使用する場合、アプリケーション全体でこの情報を薄いレイヤーで塗りつぶす必要はありません。 または、COMがまだ好きな場合もあります（ドンボックスはそれを見ることさえできませんが）、すべてのオブジェクトをCOMオブジェクトにラップするべきではありません。
あまりにありふれたように思えるかもしれませんが（まあ、または書くことも）価値はありませんが、残念ながら、このような例は誰もがそれについて知っていると考えるにはあまりにも頻繁に出くわします。
カプセル化は、クラスのプライベートフィールド（つまり、データの非表示）だけでなく、より広い意味での情報の非表示でもあります。 したがって、 WCF の使用を 別のモジュールでカプセル化することは、アーキテクチャの観点から は、クラスの int 型 を 持つプライベートフィールドと、 設計の観点から はまったく同じカプセル化 です。
高レベルの抽象化（アセンブリ/モジュール/クラスよりも高レベルの他のがらくたなど）も、パブリックインターフェイス（抽象化）と実装（非表示の詳細）で構成されます。 氷山の一角である抽象化とカプセル化の概念-抽象化とその水中部分-実装の詳細をカプセル化することは、それらが通常あまり正式に適用されない場合でも、アセンブリまたはモジュールと別のクラスに適用されます。
プロセス間通信モジュールに再び戻って、この相互作用のオープンインターフェイスを選び出し、実装の詳細として可能な限りWCFを隠すことができます。 とにかく、このベンチャーから100％何も出てこないことは間違いありません。また、 「漏れやすい抽象化の法則」によれば、低レベルの実装の詳細に関する情報は他のレベルまたはモジュールに漏れます。 しかし、「このがらくたがうまくいかず、現在の解決策をあきらめなければならない場合はどうなりますか？」という簡単な質問に答えようとしても、このがらくたが本当にうまくいかない場合は結果を減らす必要があります。
1つの頭は良い、2つは突然変異
一人がしなければならない決定が山ほどあります。 デザイナーが駆け回り、15人の開発者全員に意見を求め、それぞれを喜ばせようとすると、何か旅行が起こることはまずありません。 同時に、最近のWindows 3.11はデザインアートと人間工学の頂点にあるように思われます。 そして、アプリケーションアーキテクトがシステムのアーキテクチャに関して自分自身の意見を持っているすべての人（そして、ご存じのように、各プロジェクトの参加者がそれを持っている）のアドバイスを求めた場合、この作業の結果も長くかかりません。
集団会議で使用するORMを決定する集団農場管理モデルには、多くの欠点があります。 しかし、議論、鼻水、よだれ、アピールなしで一人が技術的な決定を下す管理モデルの有用性も非常に疑わしい。
多くの場合、チームには最も経験豊富な「コショウ」があり、それだけですべての重要なアーキテクチャ上の（そしてそうではない）決定が行われます。 この状況は、この「コショウ」自体（FAC、FAC）には役立ちますが、特に「コショウ」が他の人にアドバイスを求めない場合は、プロジェクト全体にはあまり役立ちません。
最初の問題は、人々がゆっくりと「コショウ」が正しいという習慣を身につけている一方で、「コショウ」自体にもそのような習慣があることです。 その結果、誰もがフローに沿って進み、重要な決定に異議を唱える人はいません。なぜなら、彼の決定は信頼されているからです。 そのような態度の結果として、これらの決定の質は低下します。
2番目の問題は、単独で行うことはできない多くの決定があることです。 私は個人的に、企業図書館の設計を委任する人を複数知っていません（自分だけにこれを信用しません）（***）。 問題は、再利用の概念は何十年も先延ばしにされてきましたが、それでも私たちの分野で最も難しいタスクの1つであることです。 何十人もの人々が使用するライブラリを設計する場合、通常のアプリケーションを設計するときに決してとることのない、まったく異なる妥協を行い、決定を下す必要があります。 ここで、 「回廊テスト」なしでは、単純に不可能です。なぜなら、あなたの脳が頭の中にない人にとって、あなたが簡単で理解できると思うものは確かにそうではないからです。
チームのフルナンバー2がない場合、これは非常に簡単な理由でソリューションの品質の低下につながります。 ナンバーワン（私たちの「コショウ」）は、シラミの決定を確認するために誰かと話すのは愚かです。その結果、チームは長い間間違った方向に進むことができますが、チームは自分のジュースで沸騰しているため、気づくのは非常に困難です。
さらに、経験豊富な「コショウ」は、単に彼らの経験のおかげで、チームを説得して率直に間違った決定を下すことができます。 対談者の体重区分が異なる場合、経験のある人が対談者の観点から説得することは、それがいかに適切であるかに関係なく難しくありません。 C ++やC＃よりも優れているなどの論争では、それぞれの側に多くの引数があり、より経験豊富な「ペッパー」があるため、1つの引数を呼び出して他の引数を差し控えることができます。 その結果、プロジェクトの利益ではなく、Pepperの利益のために決定が下されます。
ほとんどのチームでは、他の人のコードをレビューすることさえ非常にまれであり、一般に仕様、アーキテクチャ、またはデザインのレビューについて話す必要はありません。 しかし、エラーがすぐに検出されるほど、修正のコストが安くなることも直感的に明らかです。 部外者の見た目は「私の創造」にさらに規律を当て、意思決定の質を向上させるという考えそのものです。
フィニータ
前のメモで説明した問題を軽減できる方法は他にもたくさんありますが、いくつかのヒントは、これらの問題を解決することはできませんが、発生のリスクを大幅に減らすことができるようです。 したがって、ここでは短い形式になっています。
1）実用主義のルール（極端なものは必要ありません）; このアドバイスはいつでもどこでも適用され、「リファクタリング症候群」や「二次システム効果」などの問題を回避するのにも役立ちます
2）決定を石で切り詰めないでください（どこかでめちゃくちゃになった可能性があります。その後、もう一度のみに取り組む必要があります）
3）合理的な同僚と合理的に相談する。外部からの眺めは常に役に立つため
--------------------------------------
（*）利点に加えて、デザインパターンは有害な場合があります。 最も有用なツールやテクノロジーでさえも、軽率で不合理な使用は、「不条理と腐敗」につながります。 単純な概念を実装するために多数の設計パターンが使用されたときに、「オーバーエンジニアリング」問題に何度遭遇しましたか？ 一般的に、これはプラグマティズムと常識がいつものように最良の選択であり、設計パターンも例外ではないという事実の別の例です。
（**）ジョン自身によると、彼は最初の集会の1つでこの質問を正確に尋ねました。 文字通り、彼の質問は、「ボブが要件収集フェーズを完了する前に死んでしまったら？」、詳細についてはオリジナルを大胆に参照することです。「 アプリケーション.NET 2.0アプリケーションのデバッグ」 、「コードファースト、後で考える」セクションアプローチ。」
（***） John Skeetに よる al MiscUtilsのライブラリについては話していない。 第一に、彼のライブラリは実際の問題を解決する上で「成長」し、第二に、ジョンは同僚やユーザーのフィードバックに基づいて多くの変更を加えたと確信しています。 大規模なライブラリの設計の複雑さについて少なくとも少し学びたい場合は、 AbramsとKvalinaによる「フレームワーク設計ガイドライン」を参照してください。このテーマには多くの興味深い考えがあります。
行動パターン
All Articles