プロジェクトを計画して開始するにはどうすればよいですか？

プロジェクトを開始するたびに、重要な瞬間にコアクラスを完全に変更し、あいまいなエラーに巻き込まれることにします。高度な計画を立てて、通常は良い足でスタートしますが、別の日に行き、「別の方法」でそれをやりたいと思います。

クラスのマッピングや単体テストの開始などのプロジェクトを開始するときに、標準のようなものはありますか？中規模プロジェクトを計画および開始するときの良い慣習は何ですか。

最後のプロジェクトと開始されたのは、発射体の動きのシミュレーターでした。

計画するときは、アプリケーションについて可能な限りすべてのことを事前に計画しないでください。赤ちゃんのステップで計画します。アプリケーションの使用を開始するために必要な最低限の機能は何ですか？そこから始めましょう。

プロジェクトを開始するときは、絶対最小機能のみをコーディングしてください。コードを作成するときは、スマートなカプセル化を使用して、適切でクリーンなコードを作成していることを確認してください。これにより、後で変更を加えることによるエラーを最小限に抑えることができます。

満足するまで、その最小限の機能を繰り返します。次に、新しい機能と拡張機能を1つずつ追加し始めます。ここでも、スマートなカプセル化を使用して、適切でクリーンなコードを書くことに焦点を当てます。

赤ん坊のステップで計画し、きれいなコードを書くと、実際に行う必要のある変更の数が最小限になります。その最初の機能を書き終える頃には、アプリケーションの基盤が置かれるパターンを採用しているはずです。その基盤に問題がある場合、次の機能で問題をすばやく明らかにする必要があります。ピースがどのように統合されるかを確認するのは簡単です。この時点で行う変更により、中断が最小限に抑えられます。

あなたの計画は役に立たないようです。実行可能な計画を立てるのに十分な経験がないため、それは驚くことではありません。解決策は簡単です。そんなに計画を停止します。あなたが行くようにコードを書いて書き直すことを受け入れるだけです。あなたの時間を除いて、コードは無料なので、それは大丈夫です。UIアプリケーションを作成している場合は、空のウィンドウから始めて、完了するまで少しずつ追加します。より多くの経験があれば、プロジェクトはより速く進みます。コードを変更しているので心配するのは、音楽の学生が実際にすべてのノートが無駄になるのを心配しているようなものです。

ある程度のコードをコーディングするまで、最高のデザインがどのようなものになるかは、実際には誰にもわかりません。したがって、優れた設計の秘theは、最初のドラフトが必然的に最適ではないことを認識し、小さな部分をより早く、より頻繁に書き換えることを計画することです。ほとんど完全なプログラムを廃棄する代わりに、欠陥を認識したらすぐに行または関数またはクラスを書き換えます。

経験豊富なプログラマーは通常、最初のドラフトでもそれを正しく理解していません。経験によってもたらされるのは、悪いデザインをより早く認識する能力と、より迅速に書き直す能力です。

私の経験では、この問題は、さらに経験を積むと消えます。何が機能し、何が機能しないかを感じることができます。さらに、適切なカプセル化により、設計変更のコストを削減できます。モジュールがより密にカプセル化されているほど、後で変更する方が安くなります。クラスを分離しておくための優れた動機と考えてください。

http://nathanmarz.com/blog/suffering-oriented-programming.html

これで問題が解決します。彼は、ソフトウェアが可能であることを確認し、プロトタイプを作成して作成することから始めました。その後、彼はコードの取得と分割を開始します。次に、彼はそれを最適化します。

アプリケーションの設計には2つの側面があります。1つ目は、アプリケーションで何ができるかを決定することです。2つ目は、その方法を設計することです。その変更は非常に重要であり、アプリケーションの成熟度（およびアプリケーションの方向のシフト）に応じて、再作業ではなく書き換えとしてアプローチするのが最適です。

2番目の側面は方法です。単体テストとアジャイル開発プラクティスを使用すると、リファクタリングによって特定の機能が達成される方法を変更する影響を最小限に抑えることができます。これらのテクニックを活用する方法を学ぶことの一部は、練習練習です。

私は何度も何度もアドバイスをします。ペットプロジェクトを選択します。能力を最大限に発揮してください。新しいことを学び、学んだことを応用して、そのプロジェクトの開発方法を改善します。

たとえば、Todoリストから始めます。シンプルに...最初はデータベースストレージについても心配しないでください。ただ動かしてください。今、その基盤の上に構築を開始します。MVVMとWPFを学びたいと思うかもしれません...メモリ内のToDoリストを実装する方法を既に知っているので、解決すべき問題が1つ少なくなります。次に、複数のユーザーがデータベースから自分のやることリストをロードできるようにします。メモリで解決し、プレゼンテーションを分離したので、データアクセスの学習に集中できます。そこからアプリケーションを拡張して、より複雑なドメインモデル（たとえば、Todoリストからプロジェクト管理ソリューションへの変更）、Webインターフェイス、またはモバイルデバイスで実行することもできます。この仕事をするための鍵は、あなたが達成できるものを選ぶことです。あなたがそれに対して進歩をマークすることができ、あなたが時間とともに成長することができます。

私の経験では、システムの設計には多くの場合、実際のコーディングと同じかそれ以上の時間がかかります。「事前に計画する」と言うとき、実際に何を計画していますか？たぶん古い学校に行って、実証済みの設計方法論の1つを使用します。または、実際にコードを書く前に古い学校に行って擬似コードを書きます。

元の計画に固執するのではなく、なぜ重要な瞬間に物事を変えているのかを自問する必要があると思います。元の計画に欠陥はありましたか？または、物事を行うためのより良い方法を示す洞察に満ちた瞬間がありましたか。それは実際により良かったのですか、それとも違うのですか？

expが上がると、書き直し/スクラッチして最初からやり直す必要が少なくなります。解決しようとしている問題を書き留めます。必要だと思う漠然としたクラスの説明を書き留め、どのように対話する必要があるかを書き留めてください。すべてがどのように機能するかを理解してから、コーディングします。クラスのすべてのプロパティ、メソッドを書き出すのに何時間も費やさないでください。この段階では、あなたがすべきことの50Kのフットビューを取得しようとしています。詳細を書き留める必要がある場合は、コーディングを開始してください。コーディングを開始しない場合。

あなたがこれをとても難しいと思う理由は、あなたはアイデアを持っているが、それが何をしたいのか完全なアイデアを持っていないということです。あなたがあなた自身のプロジェクトをやっていて、あなたが彼らが望むものをあなたに話す顧客がいないなら、それはあなた自身の顧客になるのはあなた次第です。顧客の靴に身を置き、不可能なウィッシュリストの作成を開始します。

言い換えれば、あなたが始めるとき、何もデザインしないでください!!! 。

システムに実行させたいことの大きなリストを作成したら、すべてに優先順位を付け、基本システムを実行するための最小機能を決定します。これは単一の基本機能でも画面全体でもかまいませんが、お客様がテストするのに十分役立つと感じるものである必要があります。

したがって、機能のウィッシュリスト+基本的な優先度= 要件。

それがすべてできたら、非常に高度な設計を行います。座って、システムが最初のいくつかの優先順位を設定して実行するために必要なものを考えてください。必要に応じて気を変えてください。しかし、ここで、コードまたはシステム構成をスパイクして、可能なことをさらに学習することができます。設計の基本的なアイデアを検証するのに十分なだけ移動してください。

すなわち：今、 あなたはあなたのデザイナーの衝動にふけることができます。

完了したら、機能の実装を開始します。機能ごとに基本的な機能仕様を作成します。これは、機能ステートメントのコレクションと同じくらい簡単です。必要に応じてストーリーカード。これにより、自分の考えを少し頭に入れて、実装をテストおよび構築する仕様となる一連のステートメントを作成できます。

泣き叫ぶ、犬を滑らせて... コード!!

そこから、仕様に合わせてテストを実装し、テストごとにコードを記述します。ビルドして「リリース」し、プロジェクトが十分に完了するまで次の機能を繰り返します。

それは本当に経験に帰着しますが、私が見つけたこのアプローチは、あなたがすべてをやりすぎて先延ばしの無限のサイクルに縛られるのではなく、あなたが何をすべきかにあなたの心を集中させるのを助ける簡単な公式です一度。

プロジェクトの目標を設定し、要件のリストを取得し、外部システムへのインターフェイスをロックダウンするなど、基本を実行した後。

次に、すべてのユーザーインタラクションに対してユースケースまたは「ストーリー」を実行する必要があります。ボリュームは、「良い」ユースケースまたはストーリーを作成するものについて書かれており、多くのバリエーションがあります。ユースケースは、私が出会った中で最も効果的な設計ツールです。これらは、不必要な要件を排除すると同時に欠落している機能を選択し、設計を必要なものまで削除するのに役立ちます。私が言ったように、方法論は異なりますが、ほとんどの実践者は同意します-

• 簡潔な英語のテキスト。
• 「Goal Driven」が最も効果的です。「Monkey gets a grape」は「Monkey Pushes red button」よりも優れています。
• 技術用語を禁止します。「プルダウン」、「テキストボックス」はありません。適切なユースケースは、インターフェイステクノロジーから独立している必要があります。HTMLベースのシステムのユースケースを採用し、ユースケース自体に変更を加えずに音声起動システムに使用できる必要があります。（これは非常に困難ですが、価値があります！）。
• 最初のドラフトの単語数を50％減らすことを目指し、不要な手順や冗長性を取り除きます。

主要なクラスを指定する準備ができているよりも：

UML-ユニバーサルモデリング言語。クラスを設計するための標準ツールです。各クラスのパブリックメンバーとメソッドを指定し、それらを明確で簡潔なグラフィカルモデルでリンクします。

シーケンス図、データモデルと組み合わせて、コーディングを行う前に設計を検証および改善できます。

取得したい結果に焦点を移し、新しい実装を学習/試行することで得られる可能性のある利益と、1番に戻る道をたどるリスクとを比較検討します。

あなたがスクエア1に戻った場合、経験を積んだからといってすべてが失われるわけではありません。

締め切りがある場合（楽しみのためにプログラミングしているように聞こえるかもしれません）、これは本当に注意が必要です。常に一方通行の場合、時間が経つにつれて古い方法を使用する危険があります。反対の方向に進み続けると、より遅い速度（学習アドベンチャーの結果に応じてさまざまに遅い速度）で出力を生成する結果になる危険があります。

私は仕事を通して燃え上がり、物事を年々速く終わらせていましたが、ある日、自分のスキルセットが最新ではなくなっていることに気付きました。