開発者に遅い開発マシンを与えると、コードはより速く/より効率的になりますか？
開発者に絶叫する高速マシンを与えたとしましょう。 WPFベースのVS2010は非常に迅速に読み込まれます。次に、開発者は、自分のボックスで正常に実行されますが、現実の世界でははるかに遅いWPFまたはWPF/eアプリケーションを作成します。
この質問には2つの部分があります...
1）開発者に遅いマシンを与えた場合、それは結果のコードがより高速またはより効率的であることを意味しますか？
2）開発者に高速のIDE=エクスペリエンスを提供する一方で、「典型的な」ランタイムエクスペリエンスを提供するために私は何ができますか？
更新：
念のため、経営陣への片手での対応を準備しています。これは私の考えではありません。クライアントの誤った要求を修正するために皆さんが助けてくれます。もっと弾薬をくれてありがとう、そしてこれにいつどこで取り組むべきかについて言及してくれてありがとう。次のような有効な使用例を+1しました。
-特定のサーバー側プログラミングの最適化
-テストラボ
-最上位のグラフィックカードではなく、より優れたサーバーを購入する可能性
絶対
マネージャーがすべての会議を豚ラテン語で行うべきであることも事実です。コミュニケーション能力が全体的に向上し、簡単な文章を話すときに不利になります。彼らは彼らの要点を伝えるために顔の表情とボディランゲージにもっと頼らなければならないでしょう、そして私たちは皆それがとにかくすべてのコミュニケーションの少なくとも70％であることを知っています。
CFOはそろばんとチョークのみを使用する必要があります。さもなければ、彼らは「生データ」に頼りすぎてしまい、「直感」に十分ではなくなります。
そして、副大統領以上は、半ば酔いながらゴルフコースなどの注意散漫な環境ですべての重要なビジネスミーティングを開催する必要があります。ああスナップ...
答えは（私は太字で言う）常に
[〜＃〜]いいえ[〜＃〜]。
予算を最大限に活用して開発し、展開する機器の最小最大仕様範囲でテストします。
エミュレーター、仮想マシン、テスター付きの実際のマシンがあり、すべてがパフォーマンスをテストしてそれが要因であるかどうかを確認できます。
1） 非常に、非常にありそうもない。番号、 そしてあなたの開発者はそれを提案するためにあなたのコーヒーに嫌なものを入れるかもしれません。開発者がコードがコンパイルするまで、またはIDEが実行していること、または実行している時間を実行するために待機する時間 ない コードを改善するために費やす。彼らのメンタルフローも混乱させます。問題に心を留めておけば、彼らはその問題をはるかに効率的に解決するでしょう。
2）実際にサポートしてほしい最低のスペックを表す2台目のPCにそれぞれKVMスイッチを使用して、それと実際のワークステーションの間を移動するようにします。
長いコンパイル時間が好きです。履歴書に取り掛かる時間が増えました。
これはひどい考えです。開発者はできる限り生産的になることを望みます。つまり、開発者に可能な限り高速なマシンを提供し、コンパイルが完了するのを一日中待たないようにします。 （わずかにOTですが、WebSenseなどを使用して潜在的に役立つサイトへのアクセスをブロックしないことも役立ちます。）まだStone-Ageテクノロジーを実行しているユーザーがいるという制約がある場合は、テストマシンが必要です。同様の仕様で、早期にそして頻繁にテストして、テクノロジーの選択に関して間違った方向に進んでいないことを確認してください。
開発は、実現可能な最高の環境で行う必要があります。テストは、実行可能な最悪の環境で行う必要があります。
遅いマシンが提供された場合、開発プロセスを最適化し、配信されたコードを最適化しないで1日を過ごします。だから：いいえ！
組み込みシステムのプログラマーは常にこれに遭遇します！そして、2つの部分からなるソリューションがあります。
- 要件は、YハードウェアでのXパフォーマンスを指定する必要があります。
- Yハードウェアでテストし、Xパフォーマンスが得られない場合は、バグを報告してください。
そうすれば、開発者が作業しているハードウェアは関係ありません。
それが終わったら、より高速な機器でプログラマが1日30時間、または1年で125時間節約できるとしましょう。そして、それらが利点とオーバーヘッド（シリコンバレーでは途方もなく低い）で年に10万ドル、または1時間に50ドルかかるとしましょう。その125時間* $ 50 /時間は$ 6250です。したがって、プログラマ1人あたりのロックイン開発ハードウェアに年間6250ドル未満を費やせば、お金を節約できます。
それはあなたがあなたの経営者に伝えなければならないことです。
ティム・ウィリスクロフトはこれの前半をコメントでかなり言っていました、そして公正な世界では、彼はこの答えが得るあらゆる点の半分を得ます。
10月24日追加：
私の元雇用主はその理論を持っていました、そしてそれは彼らが約1億ドルを払いのけるのを助けました。
彼らは日本を拠点とするコングロマリットで、日本、韓国、中国のプログラマーを雇っていました。そこらの人々は、安っぽい開発用ハードウェアを使用し、13時間の労働日を過ごし、机で寝ていて、人生を送っていないのはクールです。したがって、彼らはLinuxベースの携帯電話OSを開発するために有名なシリコンバレーの会社を買収したときに、現代のギアを欲しがっていた愚かなカリフォルニア人はただのプリマドンナであり、実際には（生産性のように）正当な理由がないと考えました。
4年後、OSはがらくたのように機能し、すべてのスケジュールが吹き飛ばされ、顧客は怒り狂い、契約が左右に打ち切られました。最後に、OSプロジェクトがキャンセルされ、コングロマリットの世界中の労働力の大部分が昨年解雇されました。そして率直に言って、私はそのすべてのお金と努力がどこに行ったのか株主に説明しなければならなかった幹部の一人でいたくなかったでしょう。
この大失敗を引き起こしたのは、遅い開発マシンだけではありませんでした。他にも多くの戦略的および戦術的な失敗がありましたが、それらは、塹壕で働いている人々が列車の事故を目の当たりにするのと同じ種類のものであり、意思決定者がなぜそれができないのか疑問に思いました。
そして、スローギアは確かに要因でした。結局のところ、予定どおりに納品することが難しい状況にある場合、意図的に作業を遅くすることは本当に賢いことでしょうか？
プログラミングには、「 時期尚早な最適化がすべての悪の根源である 」という古い格言があります。あなたはすべての悪の別の「ルート」（または少なくとも最初のブランチ）を無事に作成できたと思います。これからは、「開発者の時期尚早な最適化がすべての悪の根源である」と言えます。
簡単に言えば、これは開発時間を遅くし、その後のメンテナンスをより困難にするだけです。コンパイル時間が長くなり、ディスク上のコードの検索が遅くなり、オンラインで回答を見つけるのに時間がかかります。最も重要なのは、開発者が必要な機能をテストできるようにするために、時期尚早にコードを最適化することです。
その最後のポイントは最も重要な問題であり、他の多くの回答では取り上げられていません。最初のバージョンは問題ないかもしれませんが、その後コードを更新する場合、開発者の時期尚早な最適化により、コードの焦点が優れた設計から離れ、「これを次のようにする」に近づくことがわかります。コードの私のスタイルを維持するために最小限の作業」スタイル。当時選択された最適化は不要であり、コードを他の半最適化されたハックの上にある半最適化されたハックのパスにロックする可能性があるため、機能を追加することはより困難になります。
この例として、現在のバージョンの最小システム要件が速度の遅いシングルプロセッサマシンであると想像してください。あなたはこのボックスに開発者を置き、彼らは製品を迅速に開発したかったので、多くのハックに依存する複雑なシングルスレッドソリューションを思い付きました。 5年後の現在、デュアルプロセッサマシンの最小要件を持つ製品の新しいバージョンがあります。並行して実行できるプログラムの部分をきれいに分離できるようにしたいが、開発者にハッキーなソフトウェアを作ることを強いた5年前に行った決定により、新しい最小要件の全能力を使用できなくなった。
あなたがすべきことは、開発サイクルの終わりに、下限のボックスで受け入れテストを行うフェーズを追加することです。確かに、開発者のマシンが速いためにコードの一部は遅くなりすぎますが、その部分を分離してそこで最適化できます。コードの残りの部分は、クリーンでメンテナンス可能な状態を保ちます。
あなたの質問は、「開発者に貧弱な開発者用マシンを提供し、それでも優れたコードを入手することで、早期に最適化するように強制できますか」そして答えはノーです。
興味深い読書、それらすべての答え。
しかし、私はここで答えるほとんどの人が要点を逃していると思います。私が読んだように、問題は（少なくとも）開発者にP1を与えてより高速なコードを作成することではありません。
重要なのは、今日の多くのソフトウェアは、非常に強力なコンピュータにもかかわらず、前のミレニアムで使用したseftwareと同じくらい遅いか、さらには遅いということです。ここでの答えから判断すると、ほとんどの開発者はそのヒントを得られません。これは、Webアプリケーションでは非常に明白です。このサイトは非常に良い例外ですが、多くのサイトでは1 MBのフロントページがあります。それがダウンロードされるのを待つことで何が得られますか？知りません。ユーザーがそれに費やす必要がある時間を尊重しない開発者からの無知、またはあなたがMBごとに支払う場合のさらに悪い支払いについてのようだと私は思います。問題は、これらのすべてのWebページに高解像度の画像が含まれていないことです。多くの場合、それは開発環境から配信されたがらくたコードのほんの一部です。もちろん、それは私が推測するがらくたコードではありませんが、ユーザーとして私に利益をもたらしません。
一般に、それはコードを最適化することだけでなく、コードが与える以上に遅くなるものを含めないことを選択することと同じくらい重要です。
数週間前、私は1995年からラップトップを始めました。Windows3.xはすぐに稼働し始めました。 Enterキーが完全に解放される前に（少なくとも）、データベースからいくつかのデータを取得する必要があります。
今日、ソフトウェアから多くのことを得ることができますが、コンピューターも何倍も速くなっています。開発業界がなぜ1995年からソフトウェアのスピードを維持し、新しい機能を求めているために人々に新しいハードウェアを購入させないのか。今日では、日常のプログラムやWebサイトが、以前とまったく同じことをするために新しいハードウェアを購入せざるを得ない状況になっています。しかし、もちろんより洗練された方法で。
Linuxの開発はこれをうまく処理しているように思えます。 Linuxディストリビューションは、アニメーション化されたウィンドウのような多くの目を見張るようなものを備えた空想的なものでさえ、何年も前からかなり遠いウィンドウでした。それは彼らがそれが今日のコンピュータで働いていたにもかかわらず、そして昨日さえ持っているということです。最先端のハードウェアだけではありません。
今では、多くの開発者が不健康なレベルのアドレナリンを持っていると思います。はい、私はすべての前で待っているすべてからの不満を返す方法を見つけました：
office sql server（startup up management console）arcgis（starting and using）acrobat reader（starting up）agresso（using、using、at least a web application）windows（staring and using、well I I geted 7まだ）.net webページ（ダウンロード）
等々
良い感じ ：-）
乾杯
ニクラス
1）開発者に遅いマシンを与えた場合、それは結果のコードがより高速またはより効率的になる可能性があることを意味しますか？
私たちは過去60年間ソフトウェアを構築してきましたが、このような質問がまだありますか？コーナーを切るもう1つの試みのようです。問題ありませんが、問題は論理的だと思いますか？次の用語で考えてみてください（可能な場合）：過酷な条件、雨、泥などで動作できる4x4車を構築したいとします。エンジニアと組立ラインを要素の下に置いて、結果の車両がそれらで動作できることを確認しますか？
つまり、イエス・キリスト！開発とテストがあります。テストは別の過酷な環境で行われるか、開発者は自分の開発環境でストレステストに適した方法でテストベッドを組み立てる方法を知っています。それができない場合は、より優れた開発者に置き換えてください。
2）開発者に高速のIDE=エクスペリエンスを提供する一方で、「典型的な」ランタイムエクスペリエンスを提供するために私は何ができますか？
開発者にそれを尋ねるべきです。また、客観的で有効な答えが得られない場合は、実際の開発者に置き換える必要があります。
しかし、質問を楽しませるには、開発者（優れた開発者がいると仮定して）、優れたツール、および優れたハードウェアを、できる限り最高のものにしてください。次に、ソフトウェアが動作する必要がある最低限の共通ベースライン環境をセットアップします。 つまりテストを行う場所。テスト環境（それは明確ですを開発環境（できれば、ストレステストへ。）
あなたの開発者が良いなら、彼らはあなたにこれを伝えているはずです（あなたが彼らに尋ねたと仮定します）。
その結果、多数のbitchin '開発者が生まれます。このものはそのままで十分難しいので、エクスペリエンスを悪化させないようにしましょう。
テストまたはQA環境のユーザーと同様のハードウェアを用意して、パフォーマンスの問題をすべて排除することをお勧めします。それは良いアイデアです。
私は標準を打ち破り、彼らがサーバーソフトウェアを書いている場合に限り、イエスと言います。あなたが望むすべてを笑いますが、私が今まで見た中で最も効率的なチームは、Wyse端末を備えたPerlのグループでした。これは1990年代後半で、大学のオフシュートショップで、空間グリッドソフトウェア（基本的には計算のみ）を作成していました。しかし、彼らは比較的強力な後期モデルのRS/6000と話していました。
イベントに興味を持たせるために、そこには盲目のプログラマがいました。徹底的に感動しました。
これは悪い考えではありませんが、開発者に迅速なプログラミング環境を持たせたいと考えています。
プログラマーに2台のマシン（テスト用の高速開発ボックスと低速の商品ボックス（おそらく仮想））を与えることで、これを実装できる可能性があります。
VSビルドプロセスを少し調整すると、リモートデバッグにより、テストボックスへの展開が標準になる可能性があります。
コーダーがより効率的なコードを開発するように強制することを検討する他の方法があります-たとえば、ユニットテストにパフォーマンスとメモリ使用の目標を含めることができます。メモリ使用量の予算を設定することも優れた目標です。また、HTMLコードのページのウェイトバジェットを設定します。
問題は、高速マシンで非効率なコードを作成する開発者ではなく、測定対象のパフォーマンスメトリックを定義していないことです。
製品要件の一部として、必要なカスタマーエクスペリエンスに基づいてすべてのコンピューターで測定できる特定の目標を定義する必要があります。お使いのコンピューターを他のタイプのコンピューターに関連付けることができる多くのWebサイト（Check SpecInt）があります。
これには多くの理由があります。最小限のサポート対象ハードウェアをより簡単に定義できるため、顧客からの苦情の数を制限できます。ほとんどのソフトウェアがほとんどのコンピューターで実行されることは誰もが知っていることですが、パフォーマンスの問題にすぎません。合理的に許容できるパフォーマンスがあり、顧客の苦情を制限します-そして顧客が電話をかけたときに、ベンチマークを使用して、本当に問題があるのか、または製品の動作に顧客が満足していないのかを判断できます。
開発用のコンピューターが遅いほどコードが速くなると私は確信していますが、これには代償が伴います。その理由は、私がこの直接の経験をしたということです。通勤時間が長いため、電車で作業するためのネットブックを購入しました。このネットブックは、過去5年間に購入したどのコンピュータよりも低速です。すべてが非常に遅いので、このネットブックで何かが耐えられないほど遅くなると、私は非常に早く目にします。遅いスポットにずっとすばやく気づきます（常にベンチマークする必要はありません）。ネットブックに取り組むことは、私が開発した方法を本当に変えました。
そうは言っても、私はこれを、特に専門家の環境で行うことを推奨していません。第一に、それは士気低下です。ほとんどすべての人がアイデアを言ったという事実自体が、プログラマーがアイデアに悪い反応を示すことさえ意味をなさなかった。
第二に、すべてが遅いということは、遅いマシンでは怠惰などのために、高速マシンで実行したいこと（たとえば1分かかる）が実際には実行できないことを意味します。これはインセンティブの問題です。
最後に：生成されたコードはより高速かもしれませんが、ほとんどの場合、生成に時間がかかります。
ポイント1、NO！ Studioは適切なマシンで実行することを目的としており、その要件は各バージョンでさらに強力になっただけです。 IntelliSenseをオンにして、シングルコアの非HTボックスを使用すると、スタジオの一部のバージョンを実際にロックできます。
＃2を指摘するために、テストプロジェクトにはいくつかのリソースを調整できるいくつかの機能があります。彼らは完璧ではありませんが、彼らはそこにいます。 VPCまたは低スペックVM画像も同様に制約されているというかなり良い仕事です。私はユーザーに時々テストをするために悪いマシンに座って、彼らが機能の影響を確認できるようにしました要求しました。
いいえ。実際、テストをあまり行っておらず、プロファイラーのような追加のツールをあまり使用しないため、バグが増えることになります。手頃な価格の最高のマシン（ゲーム開発やグラフィックショップの場合はグラフィックアクセラレーションハードウェアを含む）を提供し、VM内でテストしてもらいます。 VM仕様は、必要に応じて拡大または縮小できます。
これは興味深い質問だと思うので、すぐに「いいえ」を求めるつもりはありません。私の意見は、それは私たちが話している開発チームの種類に依存します。例：毎年のICFPプログラミングコンテストに出場しているグループをリードしている場合、HPCクラスターでの開発時間を短くしても良い結果が得られても、見つけたソリューションが優れているとは限りません。科学的または数値的アルゴリズムを作成している場合も同じことが言えます。64MBのメモリを搭載した古いAMD Duron 600 MHzでは、物事を成し遂げる方法に注意する必要があり、これは一部の設計にも影響を与える可能性があります。選択肢。
一方、賢いプログラマー/科学者/何であれ、とにかく注意が必要です。しかし、コンピュータAT ALLがなく、紙にメモを取らなければならないときに、私は自分の最高のコードのいくつかを書き留めていました。これは、IDEが厳密に必要な場合、巨大なフレームワークを含む大規模なプロジェクトには適用されません。
確かなことが1つあります。高速なマシンと優れた即時結果により、（悪い）プログラマーは甘やかされ、コンピューターでがらくたのいくつかの理由の1つかもしれません。
私は、8コア8Gマシンでビルドするのに約1時間かかるパッケージで作業しています（完全クリーンビルド）。テストした比較的低価格のラップトップも持っています。ローエンドのラップトップは、1日の作業中に2つのフルビルドを管理しません。
ラップトップで意図的なテストを行って、高速マシンで生産性を高めますか、それともすべてのビルドをラップトップで実行する必要がありますか？
これらは数字ではないことに注意してください。
通常は毎日クリーンビルドを実行する必要がないという点でリグデモです（単一モジュールで多くのテストを実行できます）が、部分的なビルドでもコンパイル/リンク時間におよそ1桁の違いがあることがわかります。
したがって、本当の問題は、私の遅いマシンでは、典型的なビルドがコーヒーを飲むのに十分な長さであるのに対して、私の速いマシンでは、少量のコーヒーしか飲めないということです。
仕事を終わらせるという観点からは、高速なマシンでの開発を好む。確実に期限を守ることができます。一方、管理者が自分の遅いマシンで開発を行ったとしたら、もっと多くのWebブラウジングができるようになるか、少なくとも本を読むことができると思います。
おもしろいことに、私はスタートアップで働いていて、結局これをやった。私は実際にはかなりうまくいったと思いますが、それは私たちがいた特定の状況のためだけです。クラスの自動再読み込みが実際に正しく機能したのはmod_Perlショップでした。すべての開発者はvimをIDE=選択として使用しました（またはリモート編集ソフトウェアを使用しました）。コードがコンパイル/リロード/するのを待つのに（もしあれば）時間がほとんど失われませんでした。等.
基本的に、私はこのアイデアが好きです。IFFは、すべての開発者の開発サイクルへの影響はごくわずかであり、コードのランタイム操作にのみ影響します。とにかくコードがコンパイル、前処理などされている場合は、開発者が取り組んでいる「バグを修正、テスト、次の」ループに時間を追加しています。
対人関係では、低速サーバーを使用することは決してforcedではありませんでしたが、低速サーバーを使用した場合は、独自のメンテナンスやセットアップを行う必要はありませんでした。また、このセットアップは最初から存在していたため、これを既存の開発チームに売り込もうとすることは想像できません。
元の質問をもう一度読んだところ、私を絶えず怖がらせているのは、本番環境とは異なる開発環境であることに気づきました。 VMを使用して、実行時に開発ワークステーションに影響を与えずに実行できなくなるコードを実行しませんか？最近、VirtualBoxを使用/愛用しています。
私もここでその傾向を打ち消します。
逸話：私は、286台のコンピューターを486-esにアップグレードしたオランダのソフトウェア開発会社で働いていました（そうです、私はその年です）。数週間以内に、社内ライブラリすべてのパフォーマンスが50％低下し、バグが増加しました...少しの調査によると、デバッグプロセス中にコード自体を熟考するのではなく、「迅速な」連続コードを使用したことがわかりました->コンパイル->テスト->修正（コード）などのサイクル。
関連：アメリカで同じ会社の子会社を始めたとき、ロシアのプログラマーを採用することになりました。彼らは、機能が少なく電力が少ないPCに慣れていて、より効率的なプログラマーだったからです。
これらは異なる時代であり、リソースは今日よりもはるかに少ないことに気づきましたが、ハードウェアの前面で行われたすべての進歩により、最終的な結果はすべての前進がより高い最小仕様を必要とするsloppierプログラミングによって打ち消されます...
したがって...プログラマは、「平均ジョー」の計算能力とハードウェアの仕様を超えないマシンでアプリケーションをテストする必要があると感じています。
ハードウェアは開発時よりも低コストです。
ほとんどのボトルネックはクライアントPCではなくデータベースにありますが、開発者よりも遅いマシンでのテストの言い訳にはなりません。テストツールを使用して最適化をテストします。
絶対違う。プログラマが購入できる最高のラップトップのお金、好きなキーボード、複数の大画面、プライベートオフィス、電話なし、無料のソフトドリンク、必要なすべての本（関連するもの）、主要な技術会議への毎年の旅行、あなたは素晴らしい結果を得るでしょう。次に、上限と下限のハードウェア/ソフトウェア/ブラウザー/帯域幅の組み合わせでテストします。
多くのアプリケーションで問題となるのは、開発者が実際のデータセットを「実行」する前にテストすることです。対話型アプリケーションの場合、ベースラインテストマシン/ VMが必要になります。
私は遅いWindows95マシンで作業していて、それにより、ForthとJavaScriptでMindForth人工知能を効率的に書くことができます。
これは興味深い考えです（開発者に遅いマシンを与えると、より最適化される可能性があります）。
ただし、ソリューションはより適切な方法でフレーム化されます-プログラムの要件に応答時間を入れ、テスト用のローエンドマシンを用意します。
また、本当に使いやすいコンパイラ/言語を使用している場合は、さまざまな方法でコードを生成し、最適なものを選択できる可能性があります。それは、より高速なコンピュータによってのみ助けられるでしょう。
他の人たちは、一般的に開発者が高速なマシンを持っていることを望んでいると答えました。同意する。 RAM-できるだけスキップしないでください-一部のビルドプロセスはディスクの使用量が非常に大きくなります。
あなたが取り除くことを検討したいかもしれないものは、ビルドドライブ上のウイルス対策です！これは減速するだけで、非常に強力な減速要因になる可能性があります。
可能であれば、Linuxで開発者に開発を任せることもできます。そこにあるツールは、あらゆる種類の追加タスク（ファイル内の何かをgrepするだけなど）に最適です。これはアンチウイルスも取り除きます。
プログラマーに良いハードウェアを手に入れるべきかどうかをプログラマーに尋ねるのは、デブ男に食べ物が好きかどうかを尋ねるようなものです。これは主観的な交換であることは知っていますが、それでも...質問する価値があるのでしょうか？ ：P
もちろん、私は過半数に同意します：[〜＃〜] no [〜＃〜]。
私は断定的に「いいえ」と言いたくなりますが、最近の経験を共有させてください。プロジェクトの誰かがデータをデータベースにインポートするためのコードに取り組んでいました。当時、彼は私たちのグループで最も古いPCを所有していたでしょう。 VS 2008では問題なく動作しましたが、もちろんマシンが高速であれば、エクスペリエンスは向上します。とにかく、ある時点で、テスト中に彼が書いていたプロセスは爆撃されました（そしてそれが完全に機能する前です）。彼は記憶を使い果たした。プロセスが爆撃するまでの実行にも数時間かかりました。私たちが知る限り、これはユーザーが使用しなければならなかったであろうことを覚えておいてください。
彼はより多くのRAMを求めました。彼は3〜4週間で新しいマシンを入手し、古いマシンは廃棄されるため、彼らは拒否しました。
この男の最適化の哲学は「私たちは大量のRAMを備えた高速マシンを持っている」（とにかく彼といくつかのマシンは除外されています）であることを覚えておいてください。しかし、この状況により、アルゴリズムをよりメモリ効率の高いものに変更して、2Gbマシン（XPを実行）で実行できるようになりました。書き換えの副作用として、プロセスも以前よりもはるかに速く実行されました。 。また、元のバージョンは、さらにデータがインポートされていたときに、4Gbを使用しても最終的に爆撃されたでしょう。
Soooo ...一般的には「いいえ」と言いますが、これはマシンの能力が低い開発者がより最適化されたモジュールをもたらし、ユーザーが結果として恩恵を受ける場合です（それは必要なプロセスではないため）非常に頻繁に実行され、最初はどちらにしても最適化するつもりはなかったので、マシンにいくつかの大きなテストを実行するのに十分なRAM）があった場合、元のバージョンで立ち往生していたでしょう。 。）私は彼の要点を見ることができますが、個人的には、ユーザーがプロセスが完了するまでに8時間待たなければならないという考えは嫌です。
そうは言っても、ほとんどの開発はかなり集中的であるため、原則として、プログラマーは強力なマシンを持つべきです。ただし、テストが「最も一般的な分母」のマシンで行われ、プロセスが爆弾にならず、ユーザーが一日中ペイントが乾いていないのを確認しないように、細心の注意を払う必要があります。しかし、これはすでに言われています。 :)
質問と回答を読むと、私はNOケースの激しいことに驚かされます。
私は25年間ソフトウェア開発に携わってきましたが、プログラマーが優れたコードを開発するにはたくさんのものが必要であることをためらうことはありません。
合理的な開発環境。恐竜じゃない。エッジを出血させる必要もありません。イライラしないように十分。
優れた仕様（書かれた仕様なしでどれだけのことができるのか？）
良い支援的な管理。
賢明な開発スケジュール。
ユーザーとユーザーが持つ環境をよく理解している。
さらに、この最後の点では、開発者はユーザーが何を使用するかということを意識する必要があります。ユーザーがスーパーコンピュータを持っていて、原子分割シミュレーションなど、パフォーマンスに多大な費用がかかる計算を何時間も実行している場合、パフォーマンスを考えることが重要です。
ユーザーが286のSteam搭載ラップトップを使用している場合、開発および開発者に最新の47 GHz Core i9000で開発テストを行わせると、いくつかの問題が発生します。
「開発者に最高を与え、それをテストする」と言う人は部分的に正しいですが、これは開発者にとって大きな精神的な問題を抱えています。手遅れになるまで、つまりテストが失敗するまで、ユーザーエクスペリエンスは理解できません。
テストが失敗すると、アーキテクチャはコミットされ、経営陣は約束をし、多額の費用が費やされ、それが災害に変わります。
開発者は、1日目から考え、理解し、ユーザーエクスペリエンスの領域にいる必要があります。
「ああ、そんなに効かない」と叫ぶ人たちは、自分の考えを語っています。私はこれが何度も起こるのを見てきました。開発者の通常の応答は、「より良いコンピューターを購入するように顧客に十分に伝える」というものであり、これは効果的に顧客を非難するものです。十分じゃない。
したがって、これはいくつかの問題があることを意味します：
開発者を管理者の満足と不満に保ち、プロジェクトが失敗する可能性を高めます。
開発には低速のマシンを使用します。開発者を混乱させるリスクがありますが、開発者は本当に重要なことに集中し続けることができます。
2台のマシンを開発デスクに置き、それらを強制的にクランカーでテストします（軽視されているため、テストは行われません。しかし、少なくともテストでパフォーマンスの問題がある場合は、非常に明確です）。
バッチシステムとパンチカードを覚えていますか？人々は好転するのに1時間か1日待った。何かが終わった。
5 MHzプロセッサを搭載した古いUNIXシステムを覚えていますか？物事は成し遂げられました。
Techo-geeksは出血するエッジを追いかけるのが大好きです。これは、考えることではなく、いじくり回すことを促進します。何年もの間、より多くのジュニア開発者と私が議論してきた何か...キーボードから指を離し、コードを読んで考えることにもっと時間を費やすように彼らに促したとき。
コードの開発では、考えることに代わるものはありません。
この場合、私の気持ちは-何が本当に重要かを理解することです。プロジェクトの成功？これは会社が運動をしている/殺している会社ですか？そうであれば、失敗するわけにはいきません。テストに失敗したものにお金をかける余裕はありません。開発サイクルのテストは遅すぎるため、障害の影響は遅すぎます。
[テストで見つかったバグは、開発中に開発者が見つけたバグの約10倍の修正コストがかかります。
そして、テストで見つかったバグは、アーキテクチャの設計段階で設計されたバグの約100倍のコストで修正されます。]
これが取引ブレーカーではなく、時間と費用をかけなければならない場合は、最先端のEdge開発環境を使用して、テストの失敗の地獄に悩まされます。そうでなければ、別の方法を見つけてください。下端のハードウェア、または各デスクに2台のマシン。
私のMacbook Proは数年前のものです。 LinuxとWindowsの間に（IE quirks）vmsをテストし、いくつかのWebブラウザーとターミナルを開くと、OSXスピニングホイールがたくさん表示されます。この場合、遅いマシンは生産性を低下させます。
私は開発者が利用可能な最高の開発システムを必要としていると言いますが、それは必ずしも最速を意味するわけではありません。たとえば、ノイズを最小限に抑えるために、オールパッシブ冷却を備えた比較的低速なシステムを意味します。
一つのこと-開発システムはかなり新しいものでなければならず、そして絶対には複数のコアを持っているべきです。
古いPCは、ショーパフォーマンスの問題の初期の方法では魅力的に聞こえるかもしれませんが、たとえば、Pentium 4は、実際には一部の現在のチップよりも高速（コアあたり）かもしれません。つまり、開発者をP4システムの使用に制限することです（実際に私が現在使用しているもの-それは私の個人的な予算の問題です）...
- 現在の主流のマルチコアシステムの恩恵を受けない非並行ソフトウェアの開発を奨励します。
- マルチスレッドソフトウェアが開発されても、同時実行性に関連する問題がシングルコアシステムでのテストに表示されない可能性があるため、バグに気付かない場合があります（または少なくとも早期に気付かない場合があります）。
- マルチスレッドソフトウェアは、深刻なパフォーマンスの問題を引き起こす可能性があり、マルチコアプロセッサではさらに悪化する可能性があります。 1つは、ディスクヘッドのスラッシング（データへのアクセスが数千倍遅くなる可能性がある）を引き起こし、個々のスレッドが順次アクセスを実行しているが、それぞれがディスクの異なる部分にアクセスしている場合です。これは、例えば、より遅い遅いPCでは、 1つの1 TBドライブではなく2つの古い160 GBドライブがあるため、これらのスレッドは同じディスクへのアクセスを求めて互いに競合することはありません。
PCには、仮想マシンを適切にサポートするには制限が多すぎるという問題もあります。複数のプラットフォームでのテスト用。
答えは真ん中にあります。
開発環境（Eclipseなど）を実行するための1つの高速ボックスを用意する
そして、出力をテストするためのもう1つの遅いボックスです。これは、Webアプリにとって特に重要です。
各ボックスに1つずつ並んだ画面。
コードが出力ボックスで許容できる場合、ほとんどのユーザーにとって許容範囲を超えます。
高速開発ボックスはプログラマーを怠惰にします。たとえば、必要になるたびにDOM内の要素を検索します。一度それを見つけて、結果をキャッシュしてください。
IE 6 ....を実行している遅いボックスでの違いに本当に気づくでしょう。
この理論は単純なもので、時代遅れです。昔はそうだった。
ペンティアム以前のコンピューターでターボパスカルのものをマイクロ最適化するために、より多くの時間を費やしたことを覚えています。これは2000年以前には理にかなっており、その後はずっと少なくなっています。今日では、10年前のハードウェアを最適化していません。ソフトウェアをテスト実行してボトルネックを見つけるだけで十分です。しかし、ここにいる誰もが侵略するように、これは開発者（つまり最適化）の生産性が古いハードウェアを開発用に提供することに関連していることを意味するものではありません。
1）開発者に遅いマシンを与えた場合、それは結果のコードがより高速またはより効率的になる可能性があることを意味しますか？
いいえ。良い開発者は甘やかされています。彼らがあなたの会社で悪いツールを手に入れているのを見たら、彼らはどこか別の場所で働くでしょう。 （優れた開発者は通常、別の場所に行くことを選択できます）
この質問への答えは、あなたが尋ねた人とは無関係に響く「いいえ」ではありませんか？
より遅いマシンを与えられるべきかグラフィックデザイナーに尋ねてください。
ライターよりも遅いマシンを選択するかどうかをライターに尋ねます。
管理アシスタントに、遅いマシンと速いマシンのどちらを好むか尋ねます。
彼ら全員は、彼らがより速い機械でより生産的になると言うでしょう。
遅いマシンを使用しているときのプロファイルエクスペリエンスしか想像できません。うわぁ。
要するに。地獄.
また、少なくとも4 GBのRAMを使用して、メインマシンに2 GBを確保できます。1つはVM用で、もう1つはVMが必要とする追加メモリ用であり、メモリを確保するためです。余裕。
また、2つのプロセッサは必須なので、アプリがCPUをロックまたは食い尽くす場合、開発者は何かをctrl-alt-delするために苦痛な方法をとる必要はありません。
ここでフローに逆行しましょう：はい。あるいは、少なくとも何十年もの間、業界で一般的な知恵でした（もちろん、開発者の間では例外です。開発者は、王族のように扱われず、最新のガジェットやコンピューターを手に入れないといつも怒ります）。
もちろん、開発者のマシンを減らすことは、彼の仕事を成し遂げるために実行する必要があるアプリケーションを実行するには遅すぎるため、彼の作業パフォーマンスに有害になる点があります。しかし、その点は、6GB RAM、2つの4GBビデオカード、2つのハイエンドサウンドカード、4つのスクリーンなどを備えた$ 10000以上のコンピューターから遠く離れたところにあります。
私は仕事に携わったことがありましたが、ハイエンドのマシンはありませんでしたし、それがまともなものである限り、かなり遅くなることはありませんでした（そして、いくつかの実際の標準以下のマシンは、減速の仕方を示したときにすぐに交換されました）。
開発者のマシンでの実行時の速度は、開発者が遅いコードを書いたり、対象のデプロイメント環境を知らなかったりして報復したり罰したりしない限り、あまり関係ありません。
マネージャーは、開発者がプロジェクトの目的を理解していることを確認し、常に順調に進んでいることを確認する必要があります。私たちが議論しているターゲットマシンの問題については、低速のマシンを使用して苦しむことではなく、低速のマシンで頻繁にテストすることで防止できます。
ほとんどのプログラマはコードとテストの方法を使用しているため、実行速度が遅いと開発も遅くなります。ランタイムが遅いと、タスクも遅くなります。