抽象化のレベルを混合すると、プロジェクトのベースに爆弾が置かれます

アーキテクトとして何年にもわたって、私はさまざまな顧客を見てきました。技術仕様と顧客の要望を策定する際の最も一般的な間違いの1つは、さまざまなレベルの抽象化を混合することです。ある人が来て、次のように言い



ます。-ドアのドライブを制御し、7セグメントの画面に現在の状態を表示し、TCPを介してこのサーバーと通信できるように、常に外部サーバーとリモート制御し、コントロールパネルにVueJSを使用できるハードウェアが必要です。



その人が何を望んでいるのかは明らかなようです。誰かがそのようなTKを持っていても熱狂を引き起こします-人は、彼が何を望んでいるのかをはっきりと理解しているようです。多くの場合、特定のコントローラー/コンポーネント/フレームワーク/プロトコルを指していることさえあります。



そしてもちろん、そのような注文のために、あなたは必要な鉄片を作ることができます。また、選択したコンポーネントが互いに矛盾しない場合でも機能します。しかし、計算がプロジェクトではなく製品であり、それをサポートする必要がある場合は、時間をかけてこれらの要望をレベルに慎重に分割し、そのような画面の理由、TCPの理由、およびVueJSの出所を理解する方がはるかに便利です。アヒルの子症候群により、お客様に心地よい気持ちを持っていただける技術であることがわかるかもしれません。または、他の種類の画面があることを知らないだけです。



この場合、最初に最初のレベルについて説明します。それは、表示とリモート制御を備えたドライブを制御するデバイスです。



次に、要件の指定を開始します（ただし、特定のテクノロジーは指定しません）。

IP68の場合、230V電源を備え、modbusを介して周波数ドライブを介して800W非同期ドライブを制御するデバイス。インジケーターがはっきりと表示され、その4つの状態（開/閉/進行中/故障）を10メートルからの人が認識しなければなりません。リモートコントロールが利用可能です。インターネット上の最新のブラウザから。



その後、要件の実装レベルの選択を開始できます。これがそのようなコントローラー、これがそのようなrs485トランシーバー、これがそのような電源、ここがそのようなインジケーターです。



これらの2つのレベル（要件と実装）を簡単に分離できます。ほとんどの場合、同じ要件に対して異なる実装を選択できます。これにより、要件のレベルが変更されることはありません。要件のレベルは、実装が高すぎる、または視覚的に気に入らないという事実のために変更される可能性がありますが、開発者にとってより便利なコントローラーの選択のために変更されるべきではありません。そのような要件。



顧客が8センチメートルの文字の画面を望んでいるとしましょう。この時点で、アーキテクトまたは製品マネージャーは、なぜ正確に8センチメートルなのかを尋ねる必要があります。ほとんどの場合、顧客には「10メートルからの視認性」という要件がありますが、彼はタスクを簡素化することを決定し、すぐに特定の要件を表明しました。または、彼はプロジェクトをより理解しやすいオブジェクトで考えているため、単純に抽象的に見ることはできません。抽象的な「10メートルから見える画面」は、「セグメントで構成された、ボックス内の大きなディスプレイよりも複雑です。私はここにいます。壁に掛けます。」



しかし、定義上、顧客にはプロジェクトを開発する能力がありません。そうでなければ、顧客はあなたのところに来なかったでしょう。そして、たとえ彼がこれらの能力を持っていたとしても、なぜ彼はあなたのところに来たので、この特定のプロジェクトの開発にそれらを適用することはできません。



プロジェクトの決定は、それらの責任者が行う必要があります。顧客が選択した特定の画面のコードの開発のタイミングについて責任を負わない場合は、この画面を選択しないでください。顧客の仕事は、彼の意見では、選択された画面モデルが実装する要件を言うことです。



アーキテクチャ上の意思決定者にとっての課題は、これらの要件を満たすために最も適切なソリューションを選択することです。 LEDスクリーン、LCD、または4色のトラフィックライト、および碑文が貼り付けられたボードにすることができます。



しかし、アーキテクトは、顧客の言うことすべてを与えられたものと見なすべきではありません。このようにして、開発に十分な技術仕様を作成できれば、顧客は彼と開発の間の仲介者を必要としません。



要件が属するアーキテクチャのレベルではない要件の説明は、プロジェクトのアーキテクチャを埋めることが保証されている危険なものであり、希望の説明だけでなく、単独では安全であるが混合すると爆発する準備ができている危険なガスの混合物になります。そして、このアーキテクチャに従って実装されたシステムは遅かれ早かれ爆発します-現在の抽象化、複雑な変更、または機能の変更を伴う落下クラッチ。



あなたが家を建てていると想像してください。家の基本的な要素はレンガです。レンガの半分を購入することはできませんが、レンガのダンプトラックを5台購入しても、家は購入できません。そして、100個のレンガでさえ壁にはなりません。構築するには、最低レベルで、1つのレンガで操作する必要があります。それ以上でもそれ以下でもありません。



しかし、レンガで、そしてレンガの集合体でさえ家を設計することは、非常に悪い考えです。



まず、複雑さが増します。すべてのメモリとリソースは有限であり、より多くを費やすよりも少ない方が良いです。各レンガの位置を説明する家は、知覚するのが難しすぎて、要素が多すぎます。描画が難しく（個々の部屋をすばやく描画するのではなく、各レンガを描画します）、描画が読みにくく、3Dモデルのレンダリングに時間がかかり、購入リストはトンではなく正確な数のレンガで動作します。



第二に、柔軟性が失われます。1つのレンガをシフトすることはすでに間違いです。低レベルの開発では操作の余地がないため、他の人の作業を余儀なくされ、重要ではないエラーメッセージが表示されます。 「レンガの壁を30センチの厚さにする」というタスクを設定した場合、強度やその他の制限に違反しない限り、ビルダーは好きなようにレンガを置くことができます。彼にレンガの位置の正確な図を与えると、次のチェックで、数ミリメートルの継ぎ目の厚さの累積差により、特定のレンガの位置に0.5センチメートルの誤差が生じ、壁とそのTKの不一致につながります。これは間違いである場合もありますが、ほとんどの場合、1つのレンガの位置が正しくないと何も影響せず、状況によって決まります。これは、設計時に考慮に入れることができませんでした。たとえば、製造時のレンガの寸法が正しくありません。あなたは戻ることができます、あなたはそのようなものから構築することができます、それはより簡単でより安いでしょう。個々のレンガのレベルで設計すると、この選択が失われ、理想的な結果に一致するか、すべての作業を破棄する必要があります。



第三に、レンガの集合体が互いに無限に流れ込み、それらの間にある種のスペースがある限り、別のレベルに移動して部屋について考え始めることはできません。レンガは私たちにとってそれらの間のスペースよりも重要です。それはレンガがないことであり、生活の場ではありません。部屋のために家が建てられているようですが、部屋の壁を変更したいという願望は非常に難しく、レンガを移動したり、新しい石積みの注文を作成したりする操作が非常に多くなるため、ほとんどこれをやめます。不快な壁に同意する方が、常にレンガを移動するよりも簡単です。 -ここで計画中。



第四に、基本要素を交換するという考えは耐えられません。すべてがレンガの上に構築され、レンガで距離を数え、レンガでコストを数え、レンガで重量を数え、レンガで壁の熱伝導率を数えます。これは、不要な測定単位や不要な抽象化を作成しないため、便利です。レンガの熱伝導率は距離に簡単に変換され、コストは距離から簡単に導き出されます。



しかし、他の素材で作られた家に取り組むことは不可能です。レンガに集中するのをやめなければならず、これは世界の全体像を破壊します。抽象化レイヤーを正しく分離することで、部屋をメートル単位で完全に設計し、ルーブル単位のコスト、トン単位のパイルの負荷を計算し、W /（m K）単位の熱伝導率を計算し、最後の設計レベルでのみ、何を取るかを決定します-レンガ、気泡コンクリートまたはコンクリートパネル。また、お客様がソリューションを気に入らない場合は、プロジェクトの残りの部分に触れずに変更してください。



アーキテクチャに取り組むことは、抽象化のレベルをウォークスルーすることです。これらのレベルのビジョンは、優れたアーキテクトにとって不可欠なプロパティです。