プロジェクトの最初のイテレーションにどのくらいの詳細を入れるか？

新しい個人プロジェクト（Python）を開始したばかりで、プログラムの「大まかなドラフト」に相当するものを書いています。私はまだ広範なエラー/例外処理または美的なUI要素を入れていません（これらが最終的に必要になることを知っている場合でも）、ドキュメントは私がやっていることを将来見るのに役立つのに十分です。

プロジェクトの設計/管理の設定原則に反して、大雑把に始めるのですか？私は科学者であり、プログラマーではないので、これらのことを理解していません。したがって、主な問題は、次の2つの両極端のどちらに当てはまるかについてコンセンサスがあるかどうかです。

1. すべての例外処理を含め、最初から徹底的で高品質のコードを記述し、最終的に必要になることがわかります。

2. 最初から最小限の作業でラフなドラフトを作成し、後ですべての詳細を記入します。

関連する質問：プロジェクトを完成させるために、デザインの「素晴らしさ」を犠牲にしてよいのはいつですか？

これは完全にプロジェクトに依存するため、単一の答えはありません。ここで2つのことを考える必要があります。最終的な目標は何ですか？どうやってそこに着くと思いますか？

最終結果

Mars Orbiter制御ソフトウェアを書いていますか？次に、可能な限り最も堅牢なコードを作成していることを確認してください。すべての例外が正常に処理されていることを確認してください。

自分だけが実行するプログラムを書いていますか。たまに手動でしか実行しませんか？その後、例外を気にしないでください。重いアーキテクチャを気にしないでください。それがあなたのために働くポイントまでそれを働かせてください。

どうやってそこに着くと思いますか？

必要なものを見つけるのに多くの時間を費やし、その後数か月間、開発を続ける重いウォーターフォール開発を行っていますか？その場合、上記の目標品質をかなり早く達成する必要があります。最初からすべてのエラーチェックインフラストラクチャを計画してください。

重いアジャイル開発を行っていますか？1、2週間何かをまとめて、それを利害関係者に見せ、根本的な修正を求めるかもしれません、そしてあなたは1-2の多くのスプリントを繰り返すことができると期待していますあなたが目標を達成するまで？次に、何かを機能させることをお勧めしますが、一緒に速く壊れやすく、製品の要件が固まったときにベルトとサスペンダーを追加するだけです。

ウォーターフォールまたはアジャイルの決定（実際にはバイナリの選択ではなく連続体である）を制御している場合、予想される変更に基づいてその決定を行います。最終結果がどのようになるかを正確に知っている場合は、滝が最適です。最終的に必要なものについて漠然とした概念しか持っていない場合、アジャイルが最良の選択です。（アジャイルは最近ではより人気があります。本質的に優れているからではなく、2番目の状況がはるかに一般的だからです。）

今、あなた自身の答えを見つけます

ほとんどの場合、答えは中間のどこかにあります。プロジェクトに関するこれらの質問の両方に答えてください。そうすれば、基本的な方向に導かれるはずです。

私は自分で言うことができます。もし私が頻繁に設計された1回限りのスクリプトを書いていて、何もチェックしていない場合。また、エラー処理とアーキテクチャが大きな注目を集めるプロダクションコードも処理します。それはすべてあなたが何をしているかに依存します。

最後に1つ注意点があります。手っ取り早く実行できる1回限りのスクリプトを実行することにした場合は、必ず確認してください。残念なことに、他の人が気づいたときに、何か面白いことをする迅速で汚いスクリプトが広く使用されるようになることがよくあります。これが発生した場合、硬化のための時間が与えられていることを確認してください。

すべてのソフトウェア設計およびコーディングの概念とパターンは、何らかの問題に応じて発生します。パターンまたは概念は、その問題の解決策です。時間が経つにつれて、一部のパターンは、一貫性、親しみやすさ、パフォーマンス、保守性などの特定の要件を満たす方法で問題を解決するため、好ましいソリューションとして「よく知られる」ようになります。

つまり、ソフトウェアパターンが解決しようとしている問題が特定のソフトウェアに存在しない場合、そのパターンは必要ありません。 さらに、どのようなパターン、あなたのソフトウェアのいずれかの議論かもしれないが、あなたの提案ソフトウェアの詳細な議論含まなければならない必要性：それが行うことになっているものを？どのような問題を解決しますか？ユーザーは何人いますか？ユーザーは何らかの方法でデータを共有しますか？などなど。

例外が解決するはずの問題は、コードが何もできないような何かが起こったときです。例は、記憶媒体に存在しないファイル名が指定されたファイル/開く操作です。例外は、コードに呼び出し元に「続行できないようになった何かがあり、それに対して私ができることは何もないので、あきらめます」と言う方法を与えます。コード内にそのような条件が存在する場所がない場合、例外は必要ありません。または、単にエラーコードを返し、例外を完全に回避できます。

経験を積むにつれて、ソフトウェアパターンとその使用が適切な場合について学習します。また、必要な先行設計の量もわかります。繰り返しますが、それは完全にあなたが書いているアプリケーションに依存します。つまり、小さなユーティリティは、大規模なエンタープライズアプリケーションとは根本的に異なる方法で記述されています。

これには非常にシンプルで実用的なアプローチがあり、小規模から中規模の幅広いプロジェクトで機能します。おそらく、火星探検家にとってはうまく機能しないでしょう。

まず、システムに何をしてほしいかを考え出し、個々の機能をメモします。これは、ユーザーストーリーボード全体のように高度なものでも、目の前の紙にいくつかの箇条書きを書き留めるだけの単純なものでもかまいません。しかし、何をしたいかを知っていることが重要です。

それに基づいて、システムの一般的な構造を作成します。繰り返しますが、これは非常に多くの場合、さまざまなクラス/モジュールとそれらの相互関係の簡単な説明ですが、ドキュメント全体と同じくらい複雑になる場合があります。重要なことは、システムをどのように実装するかについて何らかのアイデアがあることです。しかし、これはおそらく作業中に洗練されていくので、複雑で詳細なものにしようとしないでください。

これらすべての機能の中で、プログラムが実行する必要がある重要なこと、つまりコア機能を決定します。

次に、それらを1つずつ実装します。ここで重要なのは、機能を実装したら、これが完了して完全に機能することを実際に確認することです。理想的には、機能し続けることを確認する単体テストを伴います。私は通常、忙しすぎて機能に戻って修正する時間がないことを前提にしています。

コア機能が実装されたら、私は通常、システムを可能な限り実稼働環境の近くで使用するようにします。これにより、a）以前に見逃していた可能性のあるバグ、およびb）次の機能の優先順位を把握できます。

その後、必要に応じて残りの機能を実装し続けることができます。

コード品質と機能

上記を念頭に置いて、期限を設定する必要がある場合、コードの品質よりも機能を犠牲にする傾向があります。単純に、少なくとも私の仕事のラインでは、何かを終えたとき、私の経営者はそれが完了したと仮定するからです。そして、彼らは私に次のタスクを与えることができます。事後にコードをより良くする時間はあまりありません。

さて、例外処理はどうですか？

それをすぐに実装したくない場合は、リストの別の機能としてそれをリストすることができます。そして、それに到達したら、それを実装できます。しかし、おそらくあなたの場合、最初にもっと重要なことはおそらく他にもたくさんあります。

ただし、例外には最低限の要件があります。何かがうまくいかない場合は、ユーザーに通知するようにしてください。例外をどこかに飲み込まないでください。