プロトタイプと本番レベルのソリューションの違いは何ですか？

この質問は、純粋に学習し、技術的な理解を深めるためのものです。私は完璧な解決策はないことを知っており、この問題は解決策のリストを終わらせる可能性がありますが、すべてのアーキテクトがデモとライブプロジェクトの違いを理解することは非常に重要だと思います。

過去に.Netで多くのデモソリューションを作成しました。私は現在、アーキテクトに割り当てられ、プロダクションレベルのWebソリューションを実装しているため、非常に高いレベルで、デモをプロダクションレベルのソリューションに変換するために何が必要かを尋ねたかったのです。私の理解から、これには（クライアントの要件を機能的に実装する以外に）必要があります：

1. すべてのメソッドのユニットテスト
2. 〜100％のコードカバレッジを確実に実現
3. すべての例外と可能なポイントカットのロギング-AOPで可能
4. インターフェース設計パターンの使用、依存関係の注入、おそらくspring.netなどのフレームワークの使用
5. インストルメンテーションのためのパフォーマンスカウンターとプロファイラーの使用
6. 適切なセキュリティの適用-つまり、Windows認証（クライアントが必要とするものである場合）。
7. すべてのメソッドのトランザクション管理
8. ソリューションの新規展開前のWebアプリケーションファイルのバックアップ

ほかに何か？

私の質問は、機能/ドキュメントではなく、技術面に関連しています。それ以外の場合は、別の方法に進むためです:-)

ありがとうございました。

最も重要な違いは、プロトタイプの目的は次のとおりだと思い
ます。1。特定の方法で問題を解決できることを証明する、または
2.クライアント/管理者に、製品の外観と感触を与える

一方、ライブシステムの目的は次のとおり
です。1.特定の問題を解決する/問題に対処する。

2つの目的は完全に異なることに注意してください。
したがって、私の意見では、ライブシステムを開発する前にプロトタイプを破棄する必要があります。

これはまた、プロトタイプは通常「迅速かつダーティ」なプロジェクトであり、質問で正しく指摘した考慮事項（テスト、パフォーマンス、セキュリティなど）なしにまとめられているためです。
したがって、悪いプロジェクトを改善しようとするよりも、新しい適切なプロジェクトを開始するほうがよいでしょう。

要件によっては、これらのすべてが必要なわけではありません。必要な場合もあります。あなたが私が何を意味するかを知っているなら;）ユニットテストとコードカバレッジは良いことですが、プロセスの他の部分のやり方によっては必要ないかもしれません。パフォーマンスプロファイリングよりも重要なのは、十分に文書化されたコード、またはトレーニングマニュアルであると言う人もいます。それは異なります！

私はあなたが技術的な側面を見ていることに気づきましたが、うまくいけば私のポイントを理解してくれるでしょう、それは非技術的な側面によって異なります。または、少なくともそうするべきです。

インスツルメンテーションにパフォーマンスカウンターとプロファイラーを使用することは適切ですが、非常に多すぎるかもしれません。必要ないかもしれません。

ここで欠けているのは、プロジェクトのコンテキスト、スコープ、およびビジネス要件を説明できないことです。

コンテキストとスコープでは、つまり、社内で使用するものを作成していますか？お客様向けですか？エンドユーザーが使用していますか？それは実際にはメモ帳のジャジーバージョンですか、それとも最初から新しいRDBMSですか？何を含める必要があるかは、見ているプロジェクトによって大きく（大きく）異なります。

ビジネス要件とは、ソフトウェアのユースケースではなく、プロジェクト管理/生産プロセスの要件を意味します。制作プロジェクトにこれらすべてが必要だと主張する場合、コストはそれに応じて反映されます（非常に高い）。それは、予算を超えているか、遅れているか、開発を開始するための青信号が与えられていないことを意味します。

基準の固定セットを持つことよりも重要なのは、単に優れた生産/開発フレームワーク、高い可視性、定期的なリリースを備え、品質をそのように評価できることです。関係する誰もコードカバレッジについてがらくたを与えていない可能性があります。

興味深いことに、ポイント1、2、4、7は、プロトタイプの構想中にすでに行われているはずですが、すべてのクラスのすべてのメソッドをテストする必要はないと思います。get / setメソッドが正しく動作するかどうかではなく、重要なコードをテストします。

セキュリティが大きな問題であるアプリケーションの目的に応じて、ポイント6はプロトタイプでそれを達成する必要があるほど重要な場合があります。アプリケーションの目的によっては、パフォーマンスが重要な場合、ポイント5が重要になる場合があります。私の意見では、ポイント3、5、および6は、クリティカルと見なされる場合、プロトタイプで必要になる可能性があります（ポイント8は、実際のアプリケーションに有効です）。

編集：プロトタイプはあなたの将来の開発の基礎/シェル/スケルトンであると私が考えるので、私の意見はsJhonnyのものとは完全に異なるようです、私にとってプロトタイプは捨てられません。

すでに言及されていることに加えて、プロダクションプロジェクトでは（特に）以下が必要です。

0-実装方法を選択する

1-主要な要件（ユースケースなどを含む）を確定して公開する

2-アーキテクチャを正しく理解する

3-正しいツールを選択する

4-パフォーマンスのためのデータベースの設計

5-クラス設計とワークフロー設計を作成する

6-バックアップされたデータベース/データソース/フィードを統合する戦略を決定して実装する

7-セキュリティ要件の定義と実装

物理的な実装のための8配置（サーバー、接続、ライセンスなど）

9-ストレージ要件を計画し、パフォーマンス指標を決定する

10-すべてのアーティファクトを生成し、本番環境にインストールする

11-テスト

12-最終的なソリューションを提供し、フィードバックを実装する

生産品質のソリューションの最も重要な機能は、私の意見では、堅牢性です。

何が起こるかに関係なく、ソリューションは状況を慎重に処理し、知る必要がある人に通知し、続行します（エラーが回復可能な場合）。

プロトタイプには次の2種類があります。

• 「クリーンアップ」されて量産コードになる、迅速で汚れた「概念実証」アプリケーション。「クリーンアップ」段階は悪夢になる傾向があり、または実際には「敷物の下の問題を一掃する」段階であり、多大な技術的負債が発生します。

• 「モックアップ」プロトタイプまたは「ワイヤーフレーム」。これらは、紙と鉛筆のUIスケッチ、または言語で作成されたインタラクティブなモックアップである場合もあります。このモックアップは、どのように組み合わせるかについて多くのことを考えることなく、すばやくこの種のものをまとめることができます。実際のアーキテクチャではなく、偽のデータを使用する必要があります。要点は、関係者にシステムがどのようになるかについてのアイデアを与えるため、要件を調整できますが、最終的なソリューションの一部として使用することはできません。

私は第二種が好きです。本当に選択肢がないので、彼らは捨てられます。

デモのないプロジェクトのように構築すると言いますが、デモから学んだことをデザインに含めることができます。生産を開始した後でも、最初のコーディングは悪い場合があります。とにかく、その大部分をリファクタリングする必要があります。

対処すべき本当の問題は、時間の制約です。意思決定者がデモの作業を続けてほしいと望むとき、彼らはアプリケーションの多くが準備ができているという印象の下にあるので、それほど長くはかかりません。他の人が、あまりにも現実的なモックアップではなくスケッチをクライアントに表示することを好む理由についてこのロジックを使用していると聞きました。デモコードには気を付けてください。このプロセスでは考えられなかった、おそらく文書化していない問題が発見された可能性があります。ここでそれらを考慮する必要があります（非常に単純化されていますが、はい、たとえばデータベースにアクセスできない場合があります）。

すべてのプロトタイプとデモが同等に作成されているわけではありません。コード全体が役に立たない場合や、特定の部分が非常にうまく機能している場合があります。デモかどうかは、違いを知っている必要はありません。あなたはレガカイアプリを捨ててやり直すだけではありませんか？私が尋ねたことを忘れてください。