プロジェクトの最初の反復にどのくらいの詳細を入れますか？
私は新しい個人プロジェクト（Python）を始めたばかりで、プログラムの「ラフドラフト」に相当するものを書いています。私はまだ広範なエラー/例外処理または審美的なUI要素を入れていません（これらのものが最終的に必要となることがわかっている場合でも）、ドキュメントは将来私が何をしていたかを確認するのに十分です。
大まかに始めるのは、プロジェクトの設計/管理の設定された原則に反していますか？私は科学者であり、プログラマーではないので、これらのことについてはスピードが足りません。したがって、主な問題は、次の2つの極端な例のどちらに該当するかについてコンセンサスがあることです。
すべての例外処理を含め、最終的に必要となることがわかっているような、徹底した高品質のコードを最初から作成します。
最初から最小限の作業の下書きを書き、後ですべての特徴点に記入します。
これはプロジェクトに完全に依存しているため、単一の答えはありません。ここで2つのことを考える必要があります。あなたの最終的な目標は何ですか？どうやってそこに着くと思いますか？
最終結果
Mars Orbiter制御ソフトウェアを作成していますか？次に、可能な限り最も堅牢なコードを作成していることを確認してください。すべての例外が同じ問題で処理されていることを確認してください。
あなただけが実行するプログラムを書いていて、たまに手動で実行するだけですか？次に、例外を気にしないでください。重いアーキテクチャを気にしないでください。それがあなたのために働くところまでそれを働かせてください。
どうやってそこに着くと思いますか？
あなたは重い滝の開発を行っていますか？そこでは何が必要かを理解するのに多くの時間を費やし、その後何ヶ月も開発を続けますか？もしそうなら、あなたはかなり早くに上記の目標品質を達成したいと思います。最初に計画したすべてのエラーチェックインフラストラクチャを取得します。
1週間か2週間何かをまとめる激しいアジャイル開発を行っていますか？それは、根本的な修正を求めるかもしれない利害関係者に表示され、多くの1-2ウィースプリントを反復できることが期待できる場所ですあなたが目標を達成するまで？次に、何かを機能させることをお勧めしますが、同時に壊れやすく、製品の要件が固まるにつれてベルトとサスペンダーを追加するだけです。
ウォーターフォールまたはアジャイルの決定（実際にはバイナリの選択ではなく連続体）を制御している場合は、予想される変化に基づいてその決定を行います。最終結果がどのようになるか正確にわかっている場合は、ウォーターフォールが最良の選択です。最終的に何をする必要があるかについて漠然とした概念しかない場合は、アジャイルが最良の選択です。 （最近、アジャイルの方が人気があるのは、本質的に優れているからではなく、2番目の状況がはるかに一般的だからです。）
今、あなた自身の答えを見つけてください
ほとんどの場合、答えは真ん中のどこかにあります。プロジェクトに関するこれらの両方の質問に答えてください。そうすれば、基本的な方向に導くはずです。
私自身、それは、設計が非常に小さく、エラーチェックを行わない1回限りのスクリプトを頻繁に作成する場合です。エラー処理とアーキテクチャーが大きな注目を集める製品コードも処理します。それはすべてあなたが何をしているかに依存します。
最後に1つ注意点：簡単に実行できる1回限りのスクリプトを実行する場合は、必ず確認してください。残念ながら、他の人が気づいたときに、何か面白いことをする素早いスクリプトが幅広い用途に利用されることがよくあります。これが発生した場合は、硬化のための時間が与えられていることを確認してください。
すべてのソフトウェア設計とコーディングの概念とパターンは、何らかの問題に対応して発生します。パターンまたは概念は、その問題の解決策です。時間が経つにつれて、一部のパターンは、一貫性、親しみやすさ、パフォーマンス、保守性などの特定の要件を満たす方法で問題を解決するため、望ましいソリューションとして「よく知られている」ようになります。
したがって、ソフトウェアパターンが解決しようとしている問題が特定のソフトウェアに存在しない場合、パターンは必要ありません。さらに、ソフトウェアのパターンの説明- might必要なソフトウェアには、提案されたソフトウェアの詳細な説明も含める必要があります。それはどのような問題を解決しますか？何人のユーザーがいますか？ユーザーは何らかの方法でデータを共有しますか？などなど。
例外が解決するはずの問題は、コードが何も実行できない何かが発生した場合です。例としては、ストレージメディアに存在しないファイル名が指定されるFile/Open操作があります。例外により、コードは呼び出し側に「私が続行するのを妨げる何かが起こったので、それに対して私ができることは何もないので、私はあきらめています」と言う方法を与えます。コードにそのような条件が存在する場所がない場合は、例外は必要ありません。または、単にエラーコードを返し、例外を完全に回避することもできます。
経験を積むにつれて、ソフトウェアパターンとその使用が適切な時期について学びます。また、必要な事前設計の量もわかります。繰り返しますが、それは完全にあなたが書いているアプリケーションに依存します。小さなユーティリティは、大規模なエンタープライズアプリケーションとは根本的に異なる方法で記述されています。
これには非常にシンプルで実用的なアプローチがあり、小規模から中規模の幅広いプロジェクトで機能します。火星探検家にはおそらくうまくいきません。
最初に、システムに何をさせたいかを考え出し、個々の機能のそれぞれを書き留めます。これは、ユーザーストーリーボード全体のように洗練されたものでも、目の前の紙に書き留められたいくつかの箇条書きのように単純なものでもかまいません。しかし、あなたがそれをしたい何を知っていることが重要です。
これに基づいて、システムの一般的な構造を作成します。繰り返しになりますが、これは非常に多くの場合、さまざまなクラス/モジュールとそれらが互いにどのように関連しているかを簡単に描いたものですが、ドキュメント全体と同じくらい複雑な場合があります。重要なことは、システムを実装する方法について何らかの考えがあるということです。しかし、これは作業に応じて改良される可能性があるため、複雑で詳細な説明は行わないでください。
これらすべての機能のうち、プログラムが実行する必要がある重要なこと、つまりコア機能がうまく機能します。
次に、それらを1つずつ実装します。ここで重要なのは、機能を実装すると、これが完了して完全に機能することを実際に確認することです。理想的には、機能が継続して機能することを確認する単体テストが伴うことです。私は通常、忙しいので機能に戻って修正する時間がないと思い込んでいます。
コア機能が実装されたら、通常はシステムをできるだけ実稼働環境に近い場所で使用するようにします。これにより、a）以前に見逃した可能性のあるすべてのバグ、およびb）次の機能の優先順位を把握できます。
その後、必要に応じて残りの機能を実装し続けることができます。
コード品質と機能
上記を念頭に置いて、期限を設けなければならない場合、コードの品質よりも機能を犠牲にする傾向があります。単に、少なくとも私の仕事では、何かを終えたとき、私の経営陣はそれが完了したと想定しているからです。そして、彼らは私に次の仕事を与えることができます。事後、コードをより良くする時間はあまりありません。
今、例外処理についてはどうですか？
すぐにそれを実装したくない場合は、それをリストの別の機能としてリストすることができます。そして、それに到達したら、それを実装できます。しかし、おそらくあなたの場合、最初にもっと重要なことは他にもたくさんあるでしょう。
ただし、例外には最低限の要件があります。出力がどれほど醜くても、問題が発生した場合は必ずユーザーに通知してください。例外をどこかに飲み込まないでください。