プロトタイプと本番レベルのソリューションの違いは何ですか？
この質問は、純粋に学習し、私の技術的理解を深めるためのものです。私は完璧な解決策はないことを知っており、この問題は解決策のリストを終わらせる可能性がありますが、すべてのアーキテクトがデモとライブプロジェクトの違いを理解することは非常に重要だと思います。
過去に.Netで多くのデモソリューションを作成しました。私は現在、アーキテクトに割り当てられ、プロダクションレベルのWebソリューションを実装しているため、非常に高いレベルで、デモをプロダクションレベルのソリューションに変換するために何が必要かを尋ねたかったのです。私の理解から、これには（クライアントの要件を機能的に実装する以外に）必要があります：
- すべてのメソッドのユニットテスト
- 〜100％のコードカバレッジを確実に実現
- すべての例外と可能なポイントカットのロギング-AOPで可能
- インターフェース設計パターン、依存性注入、おそらくフレームワークを使用することなど。 spring.net
- インストルメンテーションのためのパフォーマンスカウンターとプロファイラーの使用
- 適切なセキュリティの適用-つまり、Windows認証（クライアントが必要とするものである場合）。
- すべてのメソッドのトランザクション管理
- ソリューションの新規展開前のWebアプリケーションファイルのバックアップ
他に何か？
私の質問は、機能/ドキュメントではなく、技術面に関連しています。それ以外の場合は、別の方法に進むためです:-)
ありがとうございました。
最も重要な違いは、プロトタイプの目的は次のとおりであるということです。
1。問題が特定の方法で解決できることを証明するためまたは
2。クライアント/管理者に、製品の外観と感触を与える
一方、ライブシステムの目的は次のとおりです。
1。特定の問題を解決する/問題に対処する。
2つの目的は完全に異なるであることに注意してください。
したがって、私の意見ではプロトタイプはライブシステムを開発する前に破棄する必要があります。
これはまた、プロトタイプは通常「迅速かつダーティ」なプロジェクトであり、質問で正しく指摘した考慮事項（テスト、パフォーマンス、セキュリティなど）なしにまとめられているためです。
そのため、悪いプロジェクトを改善しようとするよりも、新しい適切なプロジェクトを開始した方がよいでしょう。
要件によっては、これらのすべてが必要なわけではありません。あなたが私が何を意味するかを知っているなら;）ユニットテストとコードカバレッジは良いことですが、プロセスの他の部分のやり方によっては必要ないかもしれません。パフォーマンスプロファイリングよりも重要なのは、十分に文書化されたコード、またはトレーニングマニュアルであると言う人もいます。それは異なります！
私はあなたが技術的な側面を見ていることに気づきましたが、うまくいけば私のポイントを理解してくれるでしょう、それは非技術的な側面によって異なります。または、少なくともそうするべきです。
インスツルメンテーションにパフォーマンスカウンターとプロファイラーを使用することは適切かもしれませんが、非常にやり過ぎかもしれません。必要ないかもしれません。
ここで欠けているのは、プロジェクトのコンテキスト、スコープ、およびビジネス要件を説明できないことです。
コンテキストとスコープでは、つまり、社内で使用されるものを作成していますか？お客様向けですか？エンドユーザーが使用していますか？それは実際にはメモ帳のジャジーバージョンですか、それとも最初から新しいRDBMSですか？何を含める必要があるかは、見ているプロジェクトによって大きく（大きく）異なります。
ビジネス要件とは、ソフトウェアのユースケースではなく、プロジェクト管理/生産プロセスの要件を意味します。制作プロジェクトにこれらすべてが必要だと主張した場合、それに応じてコストが反映されます（非常に高い）。それは、予算を超えているか、遅れているか、開発を開始するための青信号が与えられていないことを意味します。
基準の固定セットを持つことよりも重要なのは、優れた生産/開発フレームワーク、高い可視性、定期的なリリースを備えていることです。これにより、品質をそのように評価できます。関係者が誰もコードカバレッジについてがらくたを与えていない可能性があります。
興味深いことに、ポイント1、2、4、7は、プロトタイプの構想中にすでに行われていると思いますが、everyのメソッドをeveryでテストする必要はないと思います=クラス。 get/setメソッドが正しく動作するかどうかではなく、重要なコードをテストします。
セキュリティが大きな問題であるアプリケーションの目的に応じて、ポイント6は、プロトタイプでそれを達成する必要があるほど重要な場合があります。アプリケーションの目的によっては、パフォーマンスが重要な場合、ポイント5が重要になる場合があります。私の意見では、重要と見なされる場合、プロトタイプでポイント3、5、および6が必要になる可能性があります（ポイント8は、実際のアプリケーションに有効です）。
編集：私の意見はsJhonnyの意見とは完全に異なるようです。なぜなら、私はプロトタイプを将来の開発の基礎/シェル/スケルトンと見なしているため、プロトタイプを捨てないでください。
すでに言及されていることに加えて、プロダクションプロジェクトでは（特に）以下が必要です。
0-実装方法を選択する
1-主要な要件（ユースケースなどを含む）を確定して公開する
2-アーキテクチャを正しく理解する
3-正しいツールを選択する
4-パフォーマンスのためのデータベースの設計
5-クラス設計とワークフロー設計を作成する
6-バックアップされたデータベース/データソース/フィードを統合する戦略を決定して実装する
7-セキュリティ要件の定義と実装
物理的な実装（サーバー、接続、ライセンスなど）のための8つの配置
9-ストレージ要件を計画し、パフォーマンス指標を決定する
10-すべてのアーティファクトを生成し、本番環境にインストールする
11-テスト
12-最終的なソリューションを提供し、フィードバックを実装する
生産品質のソリューションの最も重要な機能は-私の意見では-robustnessです。
何が起こるかに関係なく、ソリューションは状況を慎重に処理し、知る必要がある人に通知し、続行します（エラーが回復可能な場合）。
デモのないプロジェクトのように構築すると言いますが、デモから学んだことをデザインに含めることができます。生産を開始した後でも、初期コーディングはうまくいかない場合があります。とにかく、その大部分をリファクタリングする必要があります。
取り組むべき本当の問題はあなたの時間の制約です。意思決定者がデモの作業を続けてほしいと思っているとき、彼らはアプリケーションの大部分が準備ができているという印象を受けているので、それほど長くはかかりません。他の人が、あまりにも現実的なモックアップではなくスケッチをクライアントに表示することを好む理由について、このロジックを使用していると聞きました。デモコードには気を付けてください。このプロセスでは考えられなかった、おそらく文書化していない問題が発見された可能性があります。ここでそれらを考慮する必要があります（非常に簡略化されていますが、はい、たとえばデータベースにアクセスできない場合があります）。
すべてのプロトタイプとデモが同じように作成されているわけではありません。コード全体が役に立たない場合や、特定の部分が非常にうまく機能している場合があります。デモかどうかは、違いを知っている必要はありません。 Legacayアプリを捨てて最初からやり直すのではないですか？私が尋ねたことを忘れてください。
プロトタイプには次の2種類があります。
「クリーンアップ」されて量産コードになる迅速で汚れた「概念実証」アプリケーション。 「クリーンアップ」段階は悪夢になる傾向があり、または実際には「敷物の下で問題を一掃する」段階であり、多大な技術的負債が発生します。
「モックアップ」プロトタイプまたは「ワイヤーフレーム」。これらは、紙と鉛筆のUIスケッチでも、言語で作成されたインタラクティブなモックアップでもかまいません。このモックアップは、どのように組み合わせるかについて多くのことを考えることなく、すばやくこの種のものをまとめることができます。実際のアーキテクチャではなく、偽のデータを使用する必要があります。要点は、関係者にシステムがどのようになるかについてのアイデアを与えるため、要件を調整できますが、最終的なソリューションの一部として使用することはできません。
私は第二種が好きです。本当に選択肢がないので、彼らは捨てられます。