プロジェクトの開発を始める前に何を計画しますか？
クライアントからプロジェクトの仕様を受け取ったとしましょう。今度は、プロジェクトの開発を開始します。通常は、最初のモジュール（通常はユーザー登録）から始めて、1つのモジュールから次のモジュールに移動します。モジュールの動作を開始する直前に頭の中で計画するだけですが、その前に計画はありません。
ただし、仕様を調べて、コーディングする前にシステムがどのように機能するかを計画したほうがよいと思います。たとえば、メインコンポーネントは何か、コンポーネントはどのように相互作用するかなどです。私が何を計画すべきか正確にわかりません。
私が何を求めているのかをよりよく理解するには、どうすればいいですか-
a）プロジェクトをコンポーネントに分割し、
b）それらの相互作用を計画します。たとえば、クラス図を作成したり、単体テストを作成したりする必要がありますか？
何か案は？
新しいプロジェクトを開始する特権がある場合、空白のキャンバスが作成されます。これは、同時に刺激的で困難な作業です。私は繰り返し作業をしていますが、これが作業を分割する方法です。
- プロジェクトの目標から始めます。目標は必ずしも最も曖昧ですが、クライアントまたはユーザーがソフトウェアで何をしようとしているのかに焦点を合わせるのに役立ちます。結局のところ、本当にクールな機能をいくつか落とすことになったとしても、それらの目標を達成したいと思うでしょう。
- 次に、アプリケーションをサブドメインに分割し始めます。これを行う方法はおそらく100通りあります。そのため、プロジェクトの目標から始めます。アプリケーションを、それらの目標をサポートするいくつかの関連するサブシステムに分割したいと考えています。これにより、次のタスクに集中できます。
- サブシステムが相互作用する方法とタイミングを特定します。詳細は扱っていません。サブシステムの統合システムがあることを確認するための高レベルの情報のみです。プロジェクトの全体的な目標をサポートする詳細を具体化できるように、この一般的な考え方が必要です。
- 現在取り組んでいるサブシステムの詳細のみを提供してください（現在の戦略と同様）。このサブシステムが他のサブシステムとどのように相互作用する必要があるかはすでに知っていますが、最も意味のあるものにするために、いくつかの代替案を考え出す必要があるかもしれません。各サブシステムはインターフェースで分離されているため、システム全体を壊すことなく、可能な限り実装を調整できます。
- 他のサブシステムでの実装方法と比較して、現在のサブシステムでの実装方法を確認してください。一貫性のないすべてのアプローチは、ユーザーが学ばなければならないものです。新しいコンセプトについて話していても問題ありません。使いやすさのために、怠惰だったという理由だけで存在する情報を削除するための5つの異なる方法は望まないでしょう。同じユーザーインターフェイス要素を再利用することは、アプリケーションをより直感的にする最も簡単な方法です。 3つの概念を学ぶことは、20を学ぶことよりもはるかに簡単です。
本質的に、プロジェクトを非常に高いレベルからより詳細な設計まで段階的に定義するこのアプローチは、私に役立ちました。実際にサブシステムを実装しようとすると、サブシステム間の相互作用も洗練されます。それはいい。
スペックを超えたらもっといいと思います
正しい。良いアイデア。
コーディングする前に、システムがどのように機能するかを計画しました。
良い。それ以上のことをしてください。
主なコンポーネントは何ですか、
優れた。
彼らがどのように相互作用するか、
正しい。
何を計画したらいいのかよくわからない。
すでにたくさんのものをリストアップしているのにどうして確実になれないのですか？それらがあなたに関係するものであるなら、なぜそれらに集中するだけではないのですか？
4 + 1ビューモデルについて読む： http://en.wikipedia.org/wiki/4%2B1_Architectural_View_Model
Zachmanフレームワークについて読んでください： http://en.wikipedia.org/wiki/Zachman_Framework
それはあなたが計画する必要があるものです。
どのようにすればよいですかa）プロジェクトをコンポーネントに分割します。
他の同様のプロジェクトには、広く採用されている設計パターンを使用します。
疑問がある場合は、J2EEブループリントを読んでアイデアを探してください。
http://www.Oracle.com/technetwork/Java/javaee/blueprints/index.html
どのようにすればよいですかb）それらの相互作用を計画します。たとえば、クラス図を作成したり、ユニットテストを作成したりする必要がありますか？
はい。すべて良いアイデアです。
最も重要なこと：仕様を確認し、顧客とやり取りして、より洗練された仕様を取得します。
要件は間違いなく不完全、あいまい、または不正確です。時間の最大の無駄は、間違ったことをすることです。顧客はプロのソフトウェアエンジニアではないため、一連の優れた要件の開発に優れているとは期待できません。
そのため、仕様を確認し、顧客にインタビューして、これが本当に彼/彼女が必要とし、望んでいるものであり、余裕があるかどうかなどを確認する必要があります。
テスト/ユースケースを開発し、お客様とともにレビューします。要件をテストできない場合は、破棄してください。
デザインを開発し、すべての部分が理論的には必要なことを行うように正しく機能するかどうかを確認します。
すべてのレイヤーで使用されるすべてのテクノロジーをテストし、機能は無視するアーキテクチャプロトタイプを開発します。機能仕様ではなく、アーキテクチャをテストしています。アーキテクチャが間違っていると、すべてを書き直す必要があるため、適切なアーキテクチャを入手することが重要です。速度、効率、セキュリティなどの要件を満たしていることを確認してください。
コーディングを始める前に、デザインを用意しておく必要があります。
それができたら、通常、最初に最初のアーキテクチャフェーズを実行して、アプリレイヤーがどのように適合するかを定義します。これには、セキュリティやロギングなどのバックボーン要素が含まれます。
次に、1つの機能を上から下に構築して、完全に実装できるようにします。
その後、そこから行きます。
すべて
すべてを計画します。一度にコード化されている部分よりも紙の上で変更する方が簡単です。ドキュメント化の優れた基盤と、他の多くの利点があります。