5

予算を立てる時期であり、企業は、期限が来ており、それを必要としており、それに値する同僚のマシンを交換する費用を負担しています。

私たちのグループは、大きなメディア グループの一部門として存在する小さな ISV/SAAS です。私たちはコストセンターではありません。今年も利益を上げています。私たちは中規模のメディア グループに所有されており、そのビジネス モデルはまったく異なり、コスト削減のみを推進しているようです。

私たちのソフトウェア スタックは、Windows Server 2008 上の Visual Studio 2008、SQL 2008 です (各開発者のマシンで複数のルート Web サイトをホストおよびデバッグできるようにするため)。ターゲット ハードウェアは 3GHz クアッドコア ワークステーション、4GB RAM、および RAID 1 ミラーリング ハード ドライブであるため、開発者用ハード ドライブの紛失による生産性の損失から保護されます。

企業は、強力ではあるが使い古された廃止されたサーバーをいくつか提供したいと考えており、各開発者はそのサーバー上に仮想ワークステーションを持つことになります。私たちのデスクトップに置かれているコンピュータは、1 台あたり 400 ~ 500 ドルのダム端末です。

私は中立を保とうとしていますが、私の偏見を見分けるのは難しいと思います. これに対する実際の開発者の反応を見たいと思っており、これはそれを得るのに最適な場所だと思います.

賛否両論、これが試されたのを見た場合の証拠、およびそれがどれほどうまくいったか (またはうまくいかなかったか) を含めてください。

4

10 に答える 10

10

これは善意のアイデアのように聞こえますが、次のようになります。

私の経験では、今日の最新の IDE で生産性を高めるには、複数のコア、大量のメモリ、および高速ディスクが必要です。経済のある仮想環境でそれが起こっているとは思いません。個々のボックスはまだ優れています。

コントロールの問題でもあります。仮想環境では、あらゆる種類の制限を想像できます。たとえば、独自のツールをインストールすることはできますか?

結局、見当違いです。このアイデアがビルド時間を大幅に増加させた場合、ハードウェアの節約は生産性の損失によってすぐに消えてしまいます。逆に、開発者のためにまともな個々のマシンに費やされたお金は、ビルド時間の短縮で何度も何度も元に戻ります.

高品質の個々のマシンは投資であり、コストではありません。

于 2009-11-03T17:17:55.227 に答える
7

開発はディスク バウンドです。つまり、ほとんどの場合、ディスク バウンド プロセスであるビルドを待つことに時間を費やします。全員がマシンを共有している場合、ビルド時間はさらに悪化します。

于 2009-11-03T17:18:58.913 に答える
5

すべての条件 (パフォーマンス、ディスク容量など) は別として:

複数のモニターがサポートされている限り、これで問題ありません。

それがなければ、それは無理です。

于 2009-11-03T17:17:29.213 に答える
3

多くの場合、開発者ボックスが実際に何をしているかを理解するための基本的な失敗:

プロセッサとディスク、特にディスクを噛むように構築するとき。テストするときは、Visual Studio の 1 つまたは複数のインスタンスを実行することについて話している (2 つを過ぎると興味深いことが始まる)、データベース サーバー、Web サイト/サービス、およびその他すべてのもの (多くのタブが開いているブラウザー、ノートブック)ソフトウェア、そして天国だけが他に何を知っているか) すべてが複数のモニター (少なくとも 2 つ) に広がっています。たくさんのコア、たくさんのメモリをください!

仮想化についての議論があることを私は非常に喜んで受け入れることができます。優れた開発ボックスは、上記のいくつかを分離し、テスト用の「クリーンな」環境を提供するために、複数の同時 VM をホストできる必要があります。これは、その 1 人の開発者の利益のためだけに複数の VM をホストする 1 つの開発者のためのボックスであることに注意してください...

于 2009-11-03T17:32:13.520 に答える
1

私たちのチームは、かなり長い間、問題なくリモート サーバー (GUI 要素なし、プレーンな古いvim ) で開発しています。確かに、かなり強力なサーバーが必要であり、全員が同時にコンパイルを開始すると、少し遅くなることがあります。

しかし、おまけとして、オフィス、自宅、太陽が降り注ぐビーチなど、どこからでも開発できるという点で非常に移動可能です (私たちは皆ラップトップを持っています)。

もちろん、グラフィックが重いアプリでは、それがすべてうまくいくとは限りません。

于 2009-11-03T17:27:47.343 に答える
1

あなたのグループは、あなたが検討したソリューションを十分に文書化された形式で提供していないようです。文書化された開発プロセスがある場合、企業はプロセスの変更について話し合いたいと思うかもしれません。プロセスをやり直すことで $$ の $$ が発生し、おそらく後退します。とはいえ、プロセスが文書化されたら、内部的に冷酷にそれをより効率的かつ費用対効果の高いものにしようとする必要があり、企業の提案については心を開いてください。

于 2009-11-03T17:37:04.673 に答える
0

SVN / TRAC、継続的インテグレーション サーバー、製品デモ、テストなどのためのマシンが既にあり、チームがこれらのサーバーを使用できる唯一の用途は、個人用 VM であると仮定します。

于 2009-11-03T17:20:21.663 に答える
0

私はプロセッサを 100% に固定する多くのことを行っています。コンパイルは確かにこれを達成します。そのプロセッサを他の 10 人の開発者と共有しなければならないことを想像してみてください。生産性の損失は非常に明白になります。マルチコア PC を使用している場合、これはそれほど苦痛ではありません。Intel i7 を手に入れれば、8 人がログインしていても、おそらく気付かないでしょう。ほとんどのプログラム (私のコンパイラを含む) は、とにかく 1 つ以上のプロセッサを使用できません。

つまり、コストを削減するための実行可能なソリューションです。私は以前、これらのダム端末に切り替えた会社で働いていました。それは正常に動作します。私の大学には、ダム端末である HP UNIX マシンがありました。彼らはサーバーにログインし、プロセッサの所有権をログインしている人の数に分割しました。人々が行うことは、サーバーにログインして、ログインしている人の数を確認することです。多すぎる場合は、次のユーザーを検索します。 1 つは、ビルド時間が著しく遅いためです。覚えやすいサーバー名にログインすることはありません。=)

確かに機能しますが、特に複数の人が同時にビルドしている場合は、ビルド時間が長くなるため生産性が低下します。生産性を数値化するのは非常に難しいため、あなたの意見を主張するのは難しいかもしれません。

于 2009-11-03T17:22:53.767 に答える
0

アニメーション、ビデオ、または画像編集を行う必要がある場合、グラフィックス アクセラレーションも問題になる可能性があります。フレームレートや色深度が十分に高くないため、RDP セッションを介してビデオの再生を実際にテストすることはできません。

于 2009-11-03T17:25:00.063 に答える
0

パフォーマンスに関係なく、私の会社では開発マシンとしてラップトップに移行しています。主な利点は、開発者が自分のコンピューターを会議や会議などに持ち込めることです。また、問題を解決するときに同僚の隣に座ることができ、独自の開発環境を利用できることは非常に価値があります。

于 2009-11-03T17:32:58.457 に答える