早期に最適化する必要があるため、遅いボクセンで開発する必要があります。
Randall Hyde はThe Fallacy of Premature Optimizationで指摘していますが、Hoare の引用には多くの誤解があります。
約 97% の確率で、わずかな効率性を忘れる必要があります。時期尚早の最適化は諸悪の根源です。
特に、最近の機械はホーアの時代に比べて悲鳴をあげていますが、それは「最適化を避けるべき」という意味ではありません。では、私の尊敬する同僚は、適度なテンポのボックスで開発するべきだと彼が提案したとき、一理ありますか? 遅いボックスではパフォーマンスのボトルネックがより苛立たしいので、注意を引く可能性が高いという考えです。
これはかなり主観的であり、「正しい」答えがないため、コミュニティ wiki である必要があります。
とはいえ、利用可能な最速のマシンで開発する必要があります。はい、遅いものはイライラを引き起こし、スローダウンを修正するよう促しますが、非常に高い代償が伴います。
プログラマーとしての生産性は、頭に保持できるものの数に直接関係しており、プロセスを遅くしたり、まったく妨げたりすると、それらのアイデアを短期記憶に保持しなければならない時間が長くなり、それらを忘れる可能性が高くなり、再学習する必要があります。
プログラムがコンパイルされるのを待っていると、気を取られて、バグ、潜在的な問題、および修正の山が頭から離れてしまいます。ダイアログが読み込まれるのを待つか、クエリが完了するのを待つと、同様に中断されます。
その影響を無視したとしても、後のステートメントの真実をまだ得ています。初期の最適化により、ぐるぐる回って自分自身を追いかけ、すでに機能しているコードを壊し、物事が行き詰まる可能性がある場所を推測します (多くの場合、精度は低くなります)。下。最初からコードを適切に設計しておけば、最適化のことは忘れて構いませんが、それが少し落ち着くまでは、必要な最適化が明らかになるでしょう。
遅いコンピューターは、パフォーマンスの問題を見つけるのに役立ちません。
テスト データがテーブル内の数百行にすぎない場合、データベースはすべてをキャッシュするため、不適切に作成されたクエリや不適切なテーブル/インデックスの設計を見つけることはありません。サーバー アプリケーションがマルチスレッド サーバーでない場合は、500 人のユーザーでストレス テストを行うまで、そのことがわかりません。または、アプリが帯域幅のボトルネックになっている場合。
最適化は「良いこと」ですが、それをより良く行う方法についてあらゆる種類のアイデアを持っている新しい開発者に私が言うように、「あなたがどれだけ早く間違った答えを出してもかまいません」. 最初に正しく処理し、ボトルネックが見つかったら高速化します。経験豊富なプログラマーは、最初から適切に設計および構築します。
パフォーマンスが非常に重要な場合 (リアルタイム? ミリ秒単位のトランザクション?)、一連のベンチマークとツールを設計して実装し、変更によってパフォーマンスが向上していることを科学的に証明する必要があります。パフォーマンスに影響を与える変数が多すぎます。
さらに、古典的なプログラマーの言い訳があります。
あなたの同僚がそれが重要だと考えているなら、彼に遅いコンピュータを与えて、彼に「パフォーマンス」を任せてください:-)
それはあなたが何を作っているか、また対象とする聴衆が何であるかに依存すると思います。
固定ハードウェア (コンソール ゲームなど) 用のソフトウェアを作成している場合は、展開するものと類似または同じ機器 (少なくともテスト機器) を使用します。
デスクトップアプリなどを開発している場合は、必要なマシンで開発し、後で調整して、必要な最小仕様のハードウェアで実行します。同様に、社内でソフトウェアを開発している場合、会社が購入したいマシンの最小スペックが存在する可能性があります。その場合、高速なマシンで開発し (開発時間を短縮してコストを削減するため)、その最小仕様に対してテストします。
要するに、手に入れることができる最速のマシンで開発し、サポートする最小または正確なハードウェアでテストします。
最終的なテスト環境と実稼働環境に近いハードウェアでプログラミングを行っている場合、コードをリリースするときに厄介な驚きが少なくなる傾向があります。
私は十分な数のプログラマーが深刻ではあるが予期せぬ問題によって脇に追いやられるのを見てきました。しかし、データでも同じ問題が発生するのを見てきました。コードは小さなデータセットでテストされ、大きなデータセットで「崩壊」します。
開発環境と展開環境の違いは、予期しない問題の原因になる可能性があります。
それでも、プログラミングには費用と時間がかかるため、エンドユーザーが低速で古い機器を使用している場合、より良い解決策は、テスト時にそれを処理することです (そして、使いやすさを確認するためだけにいくつかの初期テストをスケジュールします)。タイミング）。
潜在的な問題を見逃すことを心配しているからといって、なぜプログラマーを不自由にするのでしょうか? それはまともな開発戦略ではありません。
ポール。
Codd の愛のために、遅い開発マシンではなく、プロファイリング ツールを使用してください!
最適化は避けるべきです。それで Vista ができたのではないですか? :p
しかし、真剣に考えると、常にトレードオフの問題です。自問すべき重要な質問
エンド ユーザーが使用するプラットフォームは? サイクルをドロップできますか? もしそうしたらどうなりますか？
最初の開発は、利用可能な最速または最も効率的な (必ずしも同じではない) マシンで行う必要があるという意見に同意します。ただし、テストを実行するには、ターゲット プラットフォームで実行し、頻繁に早期にテストします。
お届けまでのお時間によります。12 か月の配送サイクルの場合は、今から 12 か月後の顧客の「平均」ボックスが現在の「平均」よりも優れているため、適切な速度でボックスを開発する必要があります。
開発サイクルが「今日」に近づくにつれて、開発マシンはクライアントのボックスの現在の「平均」速度に近づくはずです。
私は通常、手に入れることができる最速のマシンで開発しています。
ほとんどの場合、デバッグ ビルドを実行していますが、既に十分に遅いです。