MVCを非プログラマーに説明する必要があります。つまり、進捗レポートのコンテキストで、他の部門のマネージャーに。私がしていることの1つは、MVC分離に向けてコードベースをリファクタリングすることです。

MVC分離とは何ですか？彼らが尋ねる必要があるのはなぜですか？

このようなかなり技術的な答えを読んだ後： 本当にMVCとは何ですか？、私はプログラマーではない人と話をするので、完全に満足しているわけではありません。彼らはうなずくかもしれませんが、おそらくそれが何であり、なぜそれが必要なのか理解できないでしょう。

現実には、「ソフトウェアに変更を加える柔軟性を向上させるために、懸念、義務、機能、クラス、ブロック、タスク、物事の分離」以外のMVCを完全には把握していません。DIやOOのツールや手法などの手法を使用して、データベースをビューから分離し、ビジネスロジックからビューを分離することは、MVC分離と考えています。

たとえば、次に販売や会計のバックグラウンドを持っているプログラマーでない人にMVCを説明するとき、何を伝えますか？

MVCについては説明しません。

あなたがすることは、これがコードベースの再構築であることを説明することです。

コードベースを簡素化する再構築により、開発者はバグ報告や機能要求をより少ないバグでより速く、より適切に変更できます。

彼らは技術的な詳細を知る必要はなく、なぜそれが行われたのか、それを行うことで何が達成されたのか、ビジネスがどのように利益をもたらすのかを知る必要はありません。

言い換えれば、彼らに彼らの言語を話します。

Odedの回答の要点を支持する一方で、技術プロジェクトをビジネスマネージャーに「彼らの言語」で説明する必要があるが、「技術的な詳細を知る必要はなく、なぜそれが行われたのか」という疑問があります。

部門長とのプロジェクトまたは投資レビュー会議に参加していて、「これが私たちがやっていることだ」と宣言した場合、彼らは「うーん...なぜ？時間とエネルギーの大きな投資のように思えます。あなたが何をしているのか、そしてその理由をもう少し理解していただけますか？それは非常に合理的な質問のようです。あなたは「まあ...それは複雑だ」という立場に巻き込まれたくない。または「いいえ、説明できません。」または「それについて心配しないでください。」プロジェクトのレビューを行っているスタッフが上級であればあるほど、「説明できないものだけ」を飛ばす可能性は低くなります。少なくとも1レベル深くして、他の人が快適に感じるようにすることができれば、より良い

ヒップポケットにMVCのスケッチを用意しておきましょう。何かのようなもの：

「少し技術的ですが、... MVCはコードをモデル（コアデータとビジネスロジックを担当）、ビュー（データを表示）、およびコントローラー（ユーザーとの対話と更新を処理）に分割します。 -おそらくソフトウェアエンジニアリングの最も成功した「デザインパターン」。「単なる配管」のように思えるかもしれませんが、寄せられるすべての要求を処理するには、より強力な基盤が必要です。バグを迅速に解決します。」

たとえ最後にMVCを完全に理解していなくても、またわかりやすくするために（「卵を割ってオムレツを作る」ために）単純化しすぎたとしても、私はそれがはるかに快適だと思うでしょう。上級管理職に「説明できない」または「理解する資格がない」と言うよりも、説明を用意してください。

ソフトウェアを変更する柔軟性を向上させるため

マネージャーは最終結果に興味を持っています。彼らが技術的であるほど、彼らがあなたがそこに着く方法に関心を持つ可能性は低くなります。MVCは非常に一般的で、人気があり、実績があります。

将来変更要求が行われた場合、管理者に変更をより簡単かつ迅速に行えることを知らせることができます。誰もがこれを聞くのが好きです。

これは一般的な戦略であるため、新しい開発者を雇用しても問題は発生しません。実際、強力な支持者である優れた開発者を引き付けることができます。

この特定のプロジェクトに多くの差し迫った問題がある場合、これはすべて非常に困難になります。彼らは一歩後退するつもりはないかもしれないので、あなたは2歩前進することができます。解決策としては、待機するか、小さなピースで実装することがあります。

• モデル-電線/電気
• ビュー-照明器具
• コントローラー-ライトスイッチ

コンポーネント（照明器具、照明スイッチ/調光器）を比較的簡単に切り替えることができます。配線はそれほど多くないかもしれませんが、他のコンポーネントに影響を与えずに行うことができます。誰もが、マーケティング/販売タイプであっても、それを頭で視覚化できるはずです。（明確な分離など）

アプリケーション/システムでは、スイッチが照明器具の内部に埋め込まれ、照明器具が銅線で包まれていることを上司/同僚に伝えます。ここで、照明器具、スイッチ、またはワイヤーを更新しようとすることを想像してください。非常にコストがかかり、他のコンポーネントへの影響は非常に高く、おそらく他の何かを壊すことなく行うのは危険です。

MVCは、コードベースにパターンを適用して、ごちゃごちゃした（ただし機能している）混乱を、エラーが少なく、より速く、より簡単に変更を行えるものに変えます。

理解するための簡単な方法MVCを：モデルがデータであり、ビューは画面上のウィンドウであり、コントローラは2間の接着剤です。

史上最高のルーブリック：「SMARTモデル、THINコントローラー、DUMBビューが必要です」

他のソフトウェア設計パターンと同様に、MVCは問題の「ソリューションの中核」を表現すると同時に、各システムに適応できるようにします。特定の実装ではなく、概念として見た方がよいでしょう。この概念には多くの実装があります。

すべてのMVCバリアントはコンポーネントの同じ区分を使用しますが、通常はそれらのコンポーネントの相互作用が異なります。

知らない人のために、MVCは、1979年にTrygve ReenskaugがSmalltalkで使用するためのデザインパターンの観点から最初に説明されました。彼の論文は、「Smalltalk-80でのアプリケーションプログラミング：Model-View-Controllerの使用方法」というタイトルで公開され、将来のほとんどのMVC実装の基礎を固めました。

私はOdedに中程度に同意します-ざらざらした詳細を説明することなく、あなたがやっていることが重要で有用であるとあなたの非技術的な仲間やマネージャーに納得させる方法を学ぶことは、あなたが開発するのに賢明なスキルです。

しかし、複雑な概念を簡単な用語で説明できると実際に助けになると思います-非技術系マネージャーがしばしば抱える問題の1つは、技術者が何をしているかを正確に理解するのが難しいため、それらを信用しない。それは単なる人間の性質です。あなたが理解していないことは、それを信じるよりも役に立たないか間違っていると信じる方が簡単です。したがって、概念を自由に理解しやすくすることができれば、必要なときにいつでもそれを使用することができ、時間が経つにつれて、非技術的なマネージャーは、必要に応じて理解できることを学びます-あなたはそれを引っ張っていませんそれらについて-あなたは彼らに彼ら自身の正気のための詳細をspaしみません。彼らはあなたをもっと信頼するでしょう。

それはさておき、質問に答えましょう。

ビジネスマンが理解しているアナロジーを使用すると便利です。MVCの場合、ビジネスとして説明します。

• モデルはビジネスロジックとデータを担当します。これらは、プログラムが実行する内容と、プログラムの実行方法の詳細を定義するものです。プログラムがビジネスの場合、モデルは倉庫、工場、労働者、資本設備になります。彼らはまた、ルールが守られ、ポリシーが施行されることを確実にする下位レベルのマネージャーになります。
• ビューはプレゼンテーション層です。システムで何が起こっているかをユーザーに示し、プログラムと対話する手段を提供します。プログラムが会社の場合、ビューはショールームのフロア、トレードコンベンションの販売ブース、または営業担当のようになります。オプションを表示し、ユーザーフレンドリーな情報とフィードバックを提供し、リクエストを会社に戻します。
• コントローラーは調整レイヤーです。情報はモデルからビューへ、またはその逆へ情報を取得し、すべてが連携して仕事をするようにします。プログラムが会社の場合、コントローラーは中レベルおよび高レベルの管理者になります。彼らは細部にあまり関与しませんが、適切な人が仕事をするための適切なツールを持っていることを確認し、高レベルの決定を承認または拒否します。それらは、物事が一緒に機能するように全体的な方向を提供します。

この類推でそれを説明することの利点は、優れたマネージャーが懸念をこの方法で分離する知恵を見て、彼らがよりコントローラーのようであり、将来の詳細にあまり関与しないことを決定するかもしれないということです！

それがうまくいけば「何」に答えるでしょう-「理由」もこの類推で簡単です：

各部門が1つのタスクセットを担当し、他のユーザーが何をしているのかを心配することなく、常に必要なリソースを持っていることがわかっている理想的な会社を想像してください。営業担当者は、顧客を見つけて注文を取得し、承認した経営陣に返送してから、フルフィルメントのために倉庫/生産/エンジニアリングに行きます。フィードバックは直接的なものです。問題がなければ、誰も関与する必要はありません。これは優れたMVC設計です。各部分に仕事があり、他の部分について心配する必要はありません。そうすれば、必要に応じて簡単に変更できます。非MVC設計では、責任は明確ではありません。営業担当者は、顧客が別の何かを求めたときに製品を変更しようとする場合があります。または、彼らはその日の気持ちに応じて異なる価格を与えるかもしれません。CEOは、生産ラインをいじって工場の床に落ちている可能性があります。その場合、より信頼性の高いサプライチェーンを確立する方法を心配する必要があります。倉庫の従業員は、すでに行われた注文を履行する必要があるときに、顧客と話をしている売り場に出かけることがあります。

言い換えれば、優れたMVC設計により、各部分は1つのことに集中できるため、適切に組織化された会社のように適切に行うことができます。

**免責事項-あなたの会社がうまく組織されていない場合、彼らはこれに腹を立てるかもしれません。その場合、別のアナロジーが必要になります。別の仕事も必要になる場合があります。

MVCの利点は、主に懸念の分離にあります。

これにより、人々は自分の得意分野に集中できます。

Database admins develop the model
Programmers write the controllers
and Graphic designers can design the views.

絡み合ったシステムでは、スタッフがこれらのすべての分野の専門家である必要があるか、1つの分野の変更が他の分野に影響を与える場合に問題が発生する可能性が高いため、コストが削減されます。

MVCアーキテクチャの実際の例を提供します：携帯電話、卓上電話、Skypeなど。ビュー（ダイヤルパッド、スピーカー、マイクの種類）を変更してもモデル（オーディオ信号）には影響しません。コントローラーは音波を音声信号に変換する電話。

MVCが私の懸念を分離していることを伝えます。

私の最初の関心事はコードロジックです-Webサイトに目的のアクションを実行させるために舞台裏で行うことです。

私の2番目の懸念は、ビジネスロジック-彼ら（ユーザー）がアプリケーションに何をして欲しいかです。

3番目の懸念は、サイトがどのように見えるか、つまり、ユーザーが望むことを行うためにアクセスするページです。

（私は彼らにこの次の部分を伝えません）だから、順番に、私の説明はモデル、コントローラー、ビューについてでした。

利点を説明する

MVCをビジネス上のメリットの観点から説明します。あなたのマネージャーはこれを理解することができ、利点が説得力がある場合は参加します。

MVCを使用すると、アプリケーションを適切なユニットに分割できます。各ユニットは、他のユニットとは独立して存在します。クリーンで、保守可能で、テスト可能なコードが得られ、潜在的にシステム間でコードを再利用できます。

モデル

各モデルは、顧客レコードや製品などの単一タイプのビジネス情報を、関連するすべてのビジネスロジックとともにカプセル化します。

これを分離することにより、アプリケーションの他の部分から分離してビジネスロジックを簡単にテストできます。

モデルを追加することでアプリケーションを簡単に拡張することもできます。これは非常にモジュール式でクリーンです。

理論上の各モデルは、他のモデルから独立して存在できます。サービスオブジェクトを使用してモデル間の関係を処理することにより、これを強制することを検討できます。システムの他の部分に影響を与えずにモデルを交換できます。

景色

ビューを分離すると、基盤となるバックエンドを壊さずにフロントエンドを簡単に更新できます。

システム全体へのアクセスを必ずしも許可せずに、フロントエンドコードを別の開発者に提供できます。

また、既存のシステムで動作する代替フロントエンドを自由に作成できます。データをモバイルアプリ、API、PDF、またはExcelスプレッドシートとして表示できます。これは、システムの残りの部分にハッキングすることなく行うことができます。誤って物を壊す可能性は低くなります。フックする既存のシステムの統合ポイントを簡単に作成できます。

コントローラー

コントローラーはモデルをビューに配線します。すべてが分離されます。別のビューで簡単に配線できます。モデルコードを変更する場合、ビューは知る必要さえありません。

その他の利点

これは一般的なパターンです。他の開発者は、コードを理解して作業することができます。数年後にコードに戻ると、おそらくそれを理解して変更を加えることができるでしょう。あなたのコードは、将来の開発者にとってもう一つのレガシーな頭痛の種になる可能性が低くなります。

すべてに場所があるので、きれいなコードを生成するのがはるかに簡単です。スパゲッティ化のリスクは劇的に減少します（排除されません）。コードが保守可能になります。

すべてがモジュール式であるため、その一部を個別にテストできます。コードはテスト可能であり、バグやセキュリティホールを隠蔽する可能性は低くなります。システム全体を簡単にテストできるため、将来のアップグレードははるかに簡単になります。