コードを書き、それから戻って最適化するのは非効率的なワークフローですか？
私は新しい熱狂的なプログラマーです。私は過去2、3年間、大小のプロジェクトを行ったり来たりしてきました。
私はいつもコード内の小さな障害にぶつかり、それが大きなメモリの占有や不要なコード行を追加してしまいます。大規模なプロジェクトに関する私の哲学は、常に「頭から離れて」すべてのコードを実用的な製品に書き込んでから、戻ってコードをより単純で最適化された形式に縮小することでした。ただし、これは常に機能するとは限りません。データベース構造を実行するとき、瞬間的に現れる機能を追加するために何度も戻る必要がある傾向があります。自発的な発案のため、コードのブロック全体を消去する必要があります。
あなたへの私の質問は、プログラム全体を書いて、それから戻ってそれを最適化する方が効率的ですか、それとも私がそれを書くときにコードを最適化するべきですか？
その引用は、本来の意図されたコンテキストを超えて使いすぎて適用されますが、全体的なポイントは確かにここに当てはまります。最適化する必要があると確信するまで最適化を停止しないでください。作成するまで確信が持てません。プログラムのほとんど。
プログラム全体を記述してから戻って最適化する方が効率的ですか、それとも記述時にコードを最適化する必要がありますか？
どちらでもない
SDLCのhugeコンポーネント全体が欠落しています：design。
サンドボックス環境ではなじみのない概念を証明する必要があります（つまり、実際にはプロジェクトの他の部分とリンクしていないか、リンクしている場合は、もう少し考えてみると簡単に交換できますそれ）。
プロトタイプから学んだことを取り入れて、技術設計を作成します。これまでに、未知のものを証明し、潜在的な小さな技術的な落とし穴を見つけたはずです。ここでの目的は、設計を完全にフラッシュし、必要に応じて最適化することです（最適化のためのリファクタリング、コーディングは悪い習慣です）。
次にデザインを実装します。あなたが説明しなければならないかもしれない小さな見落としがあるかもしれません、しかしあなたがあなたのメインプロジェクトに入るコードを書き始める時までに、あなたはあなたのコンセプトを（プロトタイピングによって）証明するだけでなく、あなたとあなたの仲間が考えることができる限り多くのエッジケースを説明する効率的なデザイン（テクニカルデザイン）を手に入れるでしょう。
私はあなたに反対の提案をします。 UMLモックのようなものを使用する場合でも、単にクラスの概要を説明する場合でも、最初にクラスの概要を説明するとします。次に、最善のアプローチと思われる方法を決定したら、書き始めます。プロジェクトの目立った部分が終わったら、戻ってゴミを掃除するのが適切です。
プロジェクトと開発者の規模に応じて、これはクラスのセット、個々のクラス、または（まれに）メソッドになる場合があります。しかし、最適化のためにすべてが完了するまで待つことは、ほとんど決して良い考えではありません。 OTOH、最適化が早すぎることも同様に悪いことです。これは、書き込みとその後のクリーニング、および書き込みとその後のクリーニングのプロセスを唯一のオプションとして残します。
実行中のプログラムが最適化が必要なものを教えてくれるまで、最適化しないでください。
toが何を最適化するかを知らずに最適化すると、 酔って彼の鍵を探している に少し似ています。
私にとっては、後知恵で最適化する側で誤りを犯す方が生産的であることがよくあります。基本的な実装をたたくだけで、正確さの観点から簡単に推論でき、プロファイラーを手にして必要に応じて再検討できます。戻ってドリルダウンし、主要な領域でシステムを調整する必要がある場合でも、システムがより早く具体化されるのを確認したいので、可能な場合はより高速なソリューションに向けて反復することを好みます。
しかし、practicalの部分に大きな重点を置く必要があります。なぜなら、スカラーで小さなオブジェクトと対話することを中心に設計されたソフトウェアを作成できるわけではないからです。 、一度に1つずつの方法で、デザインを変更せずにそれを最適化するための多くの余地を見つけることを期待しています。レースカーを運転するのに10メートルの道路しかない場合は、レースカーを持っていても意味がありません。一度に1つずつ小さなものを処理する非常にきめ細かいインターフェースを設計すると、呼吸を残さない設計でこのように追い詰めることができます。最適化の余地。
したがって、パフォーマンスが重要な領域を予測する場合に役立ちます。これは、測定せずに予測できることが多いと思います*。きめ細かいではなく、十分に粗いインターフェイスを設計するのに役立ちます。
- すでに述べたように、測定するまで詳細を完全に予測できない場合でも、パフォーマンスが重要な部品がシステム内のどこにあるかをかなり適切に予測できると思います。あなたがしなければならないのは、「100万ものものをどこでループするのか」のような基本的な質問をすることです。さて、GUIシステムを実装している場合、100万を超えるものをループする場所は明らかであり、処理するために100万を超えるピクセルをループする可能性があるGUI描画関数にあります。将来的に最適化および最適化するのに十分な余裕を持って設計するために、この領域はおそらくパフォーマンスが重要になると推測するのは不合理ではありません。
たとえば、システムをきめ細かいPixelオブジェクトとの相互作用を中心に展開させるのではなく、PixelsのコレクションとImageオブジェクトとの相互作用を中心に展開するように設計します。すぐに。同様に、Particleオブジェクトの代わりに、ParticleSystemと対話します。 Creatureの代わりに、Creaturesと対話します。一度に1つの小さなもの（一度に1ピクセルなど）を処理するように設計されたコールバックの代わりに、一度にさまざまなもの（一度に1ピクセルの範囲）を処理するように設計されたコールバックがあります。これらのタイプのものは、デザインを変更せずに最適化するためのより多くの呼吸の余地を残します。
汎用ライブラリ
とは言うものの、このアドバイスは、大きなプロジェクトに進んで取り組みたいあなたのような人々を対象としています。たとえば、データ構造の汎用ライブラリを設計するという考え方で、その意図が可能な限り広く適用可能であり、それが基本的に最終製品である場合は、その作成方法を検討する時間を節約できます。可能な限り前もって効率的です。もちろん、測定、調整、反復を行っても、基本的な実装をたたくだけでなく、書き直す必要があると確信している場合はそうです。
そのような場合、効率と適用性は関連する概念です。ライブラリのパフォーマンス特性が歪んでいて、バランスの取れたデータ構造がない場合、人々はそれらをあまり使用しないか、チューニング時にますます多くのデータ構造が導入されると感じる可能性があるためです。前者で十分だったかもしれません。そのため、ほとんどの場合、事前にできる最も効率的なバージョンを取得しようとするだけで、実際にお金を払うことができる場合があります。コードの最適化、特に参照の局所性については、使用するデータ構造がますます少なくなり、より幅広いデータ構造で使用できるようになったため、何年にもわたって私は気づきました。狭い範囲で適用できる歪んだパフォーマンス特性を持つ領域ではなく、領域の範囲。その結果、最適化の考え方から生まれたとしても、維持するコードがはるかに少なくなり、生産性が向上します。
あなたの場合、「最適化」するのに最適な時期は、何をしているかによって異なります。
コードが非常にモジュール化されている場合、後でそれをいじるのはそれほど煩わしくないかもしれないので、後で「最適化」する方が良いかもしれません。データベーススキーマに大きく依存している場合は、後でデータベーススキーマをいじるのは面倒なので、早めに「最適化」する方がよい場合があります。
（「最適化」の意味がよくわからないため、「最適化」は引用符で囲んでいます。）