コーディングする前に設計に費やす時間はどれくらいですか？
私の経験では、コードに取り掛かる前にプロジェクトの計画をスケッチするときに少し時間を費やすと便利です。このような計画には通常、フレームワーク/ツールの選択、要件と期待の記述、モックアップの実行が含まれます。
私は通常これを真剣なプロジェクトのためにのみ行いますが、1回限りのまたは短期間の試みに対してはそれほどではありません。
コーディングを開始する前に、プロジェクトの計画/設計に費やす時間を聞きたいと思います。あなたはすべてのプロジェクトのためにそれをしますか、それとも単に「深刻な」プロジェクトのためにそれをしますか？
それはプロジェクトに大きく依存します。
プロジェクトがすでに記述されている仕様（バイナリデータファイルの仕様など）に基づいている場合は、あまり設計が含まれていない可能性があります。
プロジェクトが非常に投機的または研究指向である場合、デザインを事前に作成するよりも、使い捨てコードを記述してデザインを策定することに多くの時間を費やす可能性があります。
プロジェクトが大規模なプロジェクトの場合は、高レベルのアーキテクチャについてもっと前もって考える必要があります。
それがかかる限り
プロジェクト、モデル、リスク、および未知数を理解する
特にリスクと未知数
私たちの仕事ではスクラムを使用しているので、最低限、ユーザーストーリーをタスクに分解するのに十分な設計の検討を行う必要があります。タスクを書くために何が必要かについて、かなり良いアイデアが必要です。重要なのはそれらを書くことです誰か他の人が理論的には実装を実行できるようにすることです。私は通常、小さな詳細（たとえば、どのアルゴリズムを使用するか）をタスクの推定時間に組み込みます。冗談抜きの調査を行う必要がある場合は、それを独自の仕事にします。
エピック（複数のスプリントが続くプロジェクト）を扱うとき、私は "デザイン"と呼んでいるものをはるかに自由に使用できます。その場合のデザインには、通常、基本的なアーキテクチャの大まかなスケッチと、私が実行することを期待する少数のユーザーストーリーが含まれます。これはカウボーイコーディングではありませんが、厳密な設計プロセス（従来のウォーターフォールモデルを考える）でもありません。どこかでゲームが変わります（要件の変更またはa-haの瞬間）。私は、捨てられたり、大幅に変更されたりする可能性のあるものに時間をかけすぎないようにしています。
著名なジェイミー・ザウィンスキーは、「Coders at Work」という本の中で次のように述べています...私たちが使用できるものをコーディングできるように十分な時間を費やしてから、そこから進んでください。プロジェクトと競争に応じて、何かを行うための最良の方法の計画と思考にあまりにも多くの時間を費やし、所定の時間枠で製品が機能しない場合、競合他社はゲームをリードし、大きな損失。
私は必ずしもそれに同意するわけではありませんが、彼が達成したことについて彼に信用を与える必要があります。