機能のラピッド プロトタイピングを行っている場合、コードの品質と最適化について本当に心配する必要がありますか?.
5 に答える
5
「プロトタイプ」が製品になった回数を振り返ると、答えはイエスです。
機能のプロトタイプを作成するだけでなく、デザインのプロトタイプも作成することを忘れないでください。
于 2010-03-11T16:12:59.127 に答える
2
はい、品質に。最適化はできません。この質問はコミュニティウィキでなければなりません。
于 2010-03-11T16:10:28.777 に答える
0
はい。品質、明快さ、シンプルさに焦点を当て、それが何をしているのか、なぜなのかを説明するコメントを付けます (本当に複雑でない限り、それがコードの目的である方法については気にしないでください)。
ここで行うほとんどすべての作業は、「もしも」から始まります。そして、それが機能する場合は、それを続行します。
コードを書く前に何が起こるべきかを説明するコメントを書き、コメントに合わせてコードを書きます。最初にコメントを書くと、全体をどのように構成するかを考える必要があります。これにより、多くの FALSE 仮定が回避され、実際に開発が高速化されることがわかりました。
また、戻ってきたときにこれを再利用するのが非常に簡単になります。コードを読んで理解する必要はなく、コメントを読むだけです。自己文書化コードのナンセンスに行かないでください。バグを自己文書化するだけです。コードがコメント/文書とまったく一致するかどうかを確認するために何もチェックする必要はありません。
後で最適化について心配することができます -いくつかの Apache ログ ファイルを解析する趣味のプロジェクトに取り組んでいるときに MFC CMaps から STL に変更することによって得た大きな勝利のこの説明を参照してください。これは、最初のコンセプトが機能した後に行われ、パフォーマンスに問題があることが明らかになったときにのみ行われました。
于 2010-03-12T12:23:03.980 に答える
0
私は明確さを重視します。
于 2010-03-11T15:49:56.143 に答える
0
品質と最適化がプロトタイプの要件である場合は、そうです。そうでない場合は、いいえ。ラピッド プロトタイピングを行っているからといって、仕様へのプログラミング、ソース コード管理の使用、テストなどの標準的な操作手順を放棄することはありません。おそらく、迅速に開発されたプロトタイプの要件として高性能が必要になることは比較的まれです。しかし、それは別の問題です。
于 2010-03-11T16:22:56.200 に答える