コードの開発よりも設計に時間がかかるべきですか？
プログラムの設計開発に90％の時間を費やした場合、コーディング部分は10％の時間しかかからないと聞いたことがある。以前は設計に0％費やしていたときよりも、アーキテクチャの設計に費やす時間の約30％を費やす方がはるかに成功しました。その結果、私のプログラムは不必要な結合を回避しているように見え、リファクタリングが行われる前に変更するための柔軟性が向上しています。
すべてのオブジェクトにどのような名前を付ける必要があるか（オブジェクトの名前付けには非常にこだわっています）が明確になり、それぞれに単一の責任を持たせたら、通常、設計フェーズを終了します。設計に自信を持ち、ソフトウェアの構築を開始する準備ができたと感じたら、設計を再考し続けるためにより多くの時間をかけることにはメリットがありますか？私にはそれはやり過ぎかもしれません。
有効な設計とコード開発時間の比率はどのくらいですか？設計時間はコード開発時間よりも長くする必要がありますか？
従来の見積もりを行うときの私の経験では、労力配分は約30％の設計、40％の実装、30％のテストであり、通常、関連するクラス、その責任、およびオプションで主要なメソッドを特定すると、設計は完了したと見なされます。
非常に完全で包括的な設計を行うときに実行するリスクの1つは、実行できるということです Analysis Paralysis これは、明確にせずに設計を「改善」し続けるため、何も実行されないことを意味します現在の状況の利益。
したがって、行うべき設計の量には間違いなく最適があり、その最適は、設計が関連する要件に対処し、実装時にガイドとして機能するのに十分なほど詳細であると安心できる点にあります。
まず、プロジェクトの種類によって異なります。それはあなたがすでに繰り返してきたものに似ていますか？その場合、コーディング部分は非常に短くなる可能性があります。一方、それが完全に新しく、多くの新機能がある場合は、おそらく多くの機能をコーディングする必要があります。 （それとも、既存のライブラリを使用します。どちらをテストする必要がありますか。新しいライブラリのテストは開発の一部と見なされますか？）
第二に、「デザイン」と「開発」の正確な定義は何ですか？たとえば、1人がUMLでクラスを描画し、最後にそれらをコードにコンパイルします。別の人がIDE=でクラスを作成し、それらをリファクタリングしますが、まだメソッド本体を記述していません。前者の作業はおそらく「設計」として分類され、後者は「開発」として分類されますが、同じことをしているだけで、異なるツールを使用しています（より哲学的な人は、おそらくallコーディングis設計と主張するでしょう）。
第三に、それはおそらく使用するプログラミング言語、方法論などに依存します。まもなく-if設計段階でmistakeを作成しましたが、気づきやすかったり困難だったりしますか？設計段階で気付かない場合は、正式に開発に費やしている間に見つけて修正する必要があるためです。
黄金律として「90％」を使う必要はないと思いますが、あなたに最適なものを使ってください。順列で試すのではなく、方法を考える時間を増やすためのガイドラインとして考えます。
「ゴールデンルール」に大声で「いいえ」と言うだけで、それを指標として使用します「はい」、「強制しない」。
私はプロジェクトでより多くの計画を立てる傾向があります。前回は何が機能し、何が機能しなかったかがわかっているので、アーキテクチャの計画の詳細に入ることができます。
私が何か新しいことをするとき、私は何をしなければならないかについて漠然とした考えを持っています。しかし、すぐにコーディングを開始し、悪いアイデアを早期に放棄することは、一連のことを計画して後で実装するよりも優れたアイデアであることが証明されています。
したがって、実装するソフトウェアについて知るほど、計画に専念することができます。