プロジェクトに最初にアプローチするときは、一歩下がってすべてを検討するのが最善ですか、それともただ飛び込んでコーディングを開始し、後日磨くのが最善ですか？基本的に、最初に設計しますか、それともラピッドプロトタイピングを試みますか？
私は両方の方法でやけどを負いました。時にはすべてを考え抜こうとしますが、実際に核心に迫ると、考慮していなかった問題に遭遇します。また、最初にコーディングするときに、必要なコードで終わることもあります。より良い全体的なデザインに合うようにやり直しました。私の問題の多くは経験不足に起因しますが、どんなアドバイスも歓迎します。
漸進的かつ反復的に進みます。
少し設計し、少し実装します。
設計から始めると、実際に何かを実装する前に実際のフィードバックを得ることができないトンネル効果に悩まされる可能性があります。
デザインなしで始めて、あなたはあなたが後悔するであろう決定をすることができます。
理想的な状況は、システムの非常に骨格的なエンドツーエンドバージョンを実装して、テストし、顧客にデモンストレーションできるようにすることです。
最初に設計する方が常に安全ですが、これはプロトタイピングが機能しないことを意味するものではありません。プロトタイピングの本当の問題は、設計を行うときにコードを破棄するのではなく、すでに作成したコードを保持したいという衝動に抵抗することです。
銀の弾丸はありません。デザインファーストが好ましいアプローチのようです。ただし、設計の実装中に発生する可能性のあるすべての複雑さを予測することはできません。それらのいくつかは潜在的にショーストッパーになる可能性があります. さらに、クライアントのために書いている場合は、同じページにいることを確認するためだけに何かを表示できるのは良いことです.
私の職場では、フィードバックを得て、潜在的な問題のアイデアを得るために、迅速なプロトタイプを作成します。次に、正式な設計と正式な実装を行います。ほとんどの場合、プロトタイピング段階から多くのコードを回収できます。私はこのアプローチが好きです。なぜなら、最終的にクリーンで保守しやすいコードになることが多いからです。
ゴールの法則を参照してください。重要なのは反復することです。少し設計し、少し実装し、少しテストしてから、あなた（またはあなたの顧客）が満足するまで繰り返します。これが、新しい種類の「アジャイル」手法の本質です。
場合によります。
プロトタイピングは、要件や解決策が必ずしも明確でない場合に最も役立ちます。例として、私は財務調整が重要な環境（大規模な商業保険）でデータウェアハウスプロジェクトを行っています。このプロジェクトには、財務と調整するシステムを取得するための大規模なプロトタイピング演習が含まれています。これを取り巻くビジネスルールは十分に文書化されていなかったため、プロトタイプはすべてのコーナーケースを公開するのに役立ちました。
他の場合には、設計優先のアプローチがより適切かもしれません。これは、要件と賢明なソリューションアーキテクチャが合理的に明らかな場合に最も当てはまります。
作業を開始する前に、まとまりのあるアーキテクチャについてある程度理解しておく必要があります。これは特に大規模システムに当てはまります。
プロトタイピングは、プレゼンテーション層など、デザインの特定の側面に使用できます。
事前にどのようなビジネス要件があるかによると思います。それらが（比較的）詳細で完全であれば、私はそれらの要件に基づいて設計します。最初に作業するものがほとんどない場合は、プロトタイプを作成して顧客に何を入手したかを示し、さらに要件情報を受け取ります。
アジャイル手法を使用して開発する必要があります。簡単に言えば、あなたはあなたが行っているデザインです。チームは製品所有者と一緒に、開発するトピックのリストを定義し、それらを重要度順に並べ、開発を反復に分割します。開発される機能としての各イテレーションとイテレーションの開始時に、各機能を設計します。
詳しくはこちらをご覧ください。
アジャイル手法は設計を避ける言い訳にはならないことに注意してください。設計のテストをより頻繁に、より小さな単位で行うことを奨励するだけです。
明らかな不明点やリスクがなくなるまで、設計をスケッチし、その要素を分解するのが好きです。「スパイク」プロジェクトの未知数とリスクが強調表示され、実現可能性を判断するためのタイムボックスと、推奨される方法が機能しないことが判明した場合の可能な代替案に関するメモが表示されます
アーキテクチャ全体に慣れたら、ボトムアップ (または優先順位に従って) 機能に飛び込んで設計を完了し、初期テストを作成してから実装します。
編集: 「最初に設計するかプロトタイプを作成するか」という質問は悪い仮定をしていることに注意してください。つまり、設計を行わずにプロトタイプを作成することは可能ですが、もちろんそうではありません (百万匹の猿の方法論を使用している場合を除く)。
最初にプロジェクトにアプローチするときは、プロトタイプを作成します。ただし、すべてのプロトタイプを作成しないでください。1 つの重要なこと (それが何かを意味する場合は 1 つの「ユース ケース」) のプロトタイプを作成し、「内なる目を向けてその道筋をたどります」 - その 1 つのことを成し遂げようとする際に遭遇する実際的な問題に注意してください。
重要なことを行うには何が必要かがわかったので、基本原則以上のものから設計することができます。
もちろん、これは、進行中の開発作業に対して最小限のコストでプロトタイプを作成できる環境で作業していることを前提としています。しかし、そのような環境で作業している場合は、デザインに関する議論にプロトタイプを多用してください。運が良ければ、それらのいくつかを保持することができます。
プロトタイプに入れられたすべての作業を、必要なことを実行できないことがわかったときに破棄するリスクを冒すことをいとわない場合を除いて、最初に設計します。少なくとも、無駄な労力を最小限に抑えるために、プロトタイプの作成方法を決定するのに役立つ、プロジェクトの高レベルの設計を行う必要があります。
何を作りたいか分かっていれば、すぐに設計に取り掛かります。
クライアントのために何かを構築している場合は、プロトタイプを作成して、ユーザーからのより具体的な要件を緩和します。
答えではないかもしれませんが、私の経験からの提案です。
ほとんどの場合、もっと早くコーディングを始めていれば、より良い生活を送っていたでしょう。牛が帰ってくるまで設計することはできますが、コーディングを開始するときに牛が地平線上にいる場合は、慎重な設計を時間内に実装するのが難しい場合があります。