2

あなたが長期的なプロジェクト（長期的な=数年）の真っ只中にいると仮定しましょう。そして予想通り、真新しいリリースを思い付くいくつかのことがあります。まったく新しい機能（Linq、Entity Framework、WPF、WF ...など）を備えた新しい.Net Framework、お気に入りのコントロールライブラリの新しいVisual StudioまたはV.next、新しいMockFrameworkなどがあります。 。これらのテクノロジーアップデートを処理するためのガイドラインは何ですか？それらを即座に採用しますか、それともプロジェクトが終了するまで無視しますか？さまざまなもの（ツール、フレームワーク、サポートのもの）についてさまざまなガイドラインがありますか？

4

6 に答える 6

4

私の経験では、これらの決定は常にケースバイケースで行われます。次のようないくつかの要因が考慮されます。

  1. 新しいテクノロジーはどの程度成熟していますか？組織は最先端の新しいテクノロジーを最前線で使用することを好みますか、それとも実績のあるツールと方法論を使用することを好みますか？

  2. あなたの人々はどのようなスキルセットを持っていますか？それらは新しいテクノロジーの使用と一致していますか、それともより多くのトレーニングが必要ですか？生産性の向上は、スピードを上げるのにかかる時間よりも重要ですか？

  3. 既存のテクノロジーにどのような投資をしていますか？新しいテクノロジーに移行するためのコストはいくらですか？コードのやり直しと書き直しにはどのくらいの時間がかかりますか？

  4. 要件は何ですか？それは既存の技術によってサポートされていますか、それとも要件を満たすために新しいツールが必要ですか？

  5. パフォーマンスの期待は何ですか？新しいテクノロジーは、古いテクノロジーでは満たすことができないパフォーマンスの向上をもたらしますか？

  6. 技術文化はどうですか？組織のベンダー固有ですか（たとえば、Microsoftショップ）？オープンソースコードは使用できますか？

  7. プロジェクトの範囲は何ですか？フレームワークやツールなどのサポートテクノロジーの恩恵を受ける大規模なプロジェクトですか、それともこれらのことによって過度に重くなり複雑になる小さなプロジェクトですか？

  8. 新しいテクノロジーはどのようにサポートされていますか？ベンダーは優れたドキュメントを持っていますか？問題が発生した場合に話せる人はいますか？それとも、サポート契約なしで問題を解決する方法を知っている人々がいる組織ですか？

  9. テクノロジーは快適に使用できますか？それは理にかなっているようですか？清潔でエレガントですか？他の人はそれが好きなようですか？他の人が問題を抱えていますか？

  10. テクノロジーは今週の最新のフレーバーですか？戦場で具体的な結果を生み出すことが証明されたのでしょうか、それとも単なる宗教でしょうか。

  11. 新しいテクノロジーを学び、問題を解決するのにどれくらいの時間が必要ですか？メリットはコストを上回りますか？

非常に簡単な例として、最新のプロジェクトにLink to SQLを選択しました。これは、プロジェクトがORMを保証するほど複雑であり、L2Sのパフォーマンスが高く、軽量であり、Microsoft Shopであり、EntityFrameworkが私の感覚であるためです。プライムタイムの準備が整っていません（Microsoftは、将来的には頼りになるフレームワークになると言っていますが）。

于 2009-05-23T01:49:28.107 に答える
3

あなたが始めたものに固執しなさい。

大規模で長期にわたるプロジェクトには、多くの場合、巨大で非常に複雑なコードベースが付属しています。ライブラリの新しいバージョンへの変更またはアップグレードは、非常に微妙で予期しない方法でバグを追加する可能性があります。

また、大規模なプロジェクトの場合、使用するツールとライブラリは、設計段階でテストおよび評価されている必要があります。ショーストッパーやセキュリティの問題を見つけない限り、アップグレードしないことをお勧めします。

常に覚えておいてください：小川の途中で馬を変えないでください。:-)

于 2009-05-23T01:48:27.297 に答える
1

私はさまざまな要因が次のようにピッチインすると言います-

  1. ソフトウェアの寿命が近づいているとします。たとえば、昨年4月、MicrosoftはSQL Server 2000の主流のサポートを終了し、製品はそれを使用して、次のリリースでSQLServerの次のバージョンに移行するのが賢明です。
  2. 関係するもう1つの要素は、ソフトウェアの最新リリースの新機能が製品にもたらす価値です。.NET Frameworkの新しいリリースには、製品に何の価値ももたらさないものが含まれている場合がありますが、それではアップグレードするための強力なケースは構築されません。
  3. 予算も重要な要素です。すでにソフトウェアアシュアランスのようなものに参加していない限り、次のリリースにステップアップするにはライセンスをアップグレードする必要があると思います。
  4. チームへのトレーニングも要因です。最新のリリースが製品に追加される場合は、チームもトレーニングする必要があります。

ええと、他の要因もあるかもしれません。これらは私の頭のてっぺんから外れたものでした。お役に立てば幸いです。

乾杯

于 2009-05-23T01:50:35.920 に答える
1

フレームワーク固有の例について話している場合、私があなたに与える最大のアドバイスは、システムとアプリケーションを分離しておくことです。これが、Model-View-Controller などのパターンが好きな理由です。これは、コードをモジュールに保ち、アプリ全体を壊すことなくセクションをアップグレードできることを意味します。

より実用的なレベルでは、フレームワークに Git または SVN リポジトリがある場合は、リポジトリから通常の「システム」ディレクトリをチェックアウトし、「svn update」を時々呼び出して、最新かつ最高のビルドに追いつくことができます。

于 2009-05-23T01:54:11.840 に答える
0

別のポスターが言ったように、それは確かにケースバイケースのことです。何をいつアップグレードできるかは、主にシステムの新しいバージョンをテストするのがどれほど難しいか簡単かによって決まります。アプリケーション用の包括的な自動テストスイートがあると、これに大いに役立ちます。

一般的には、ライブラリなどの最新の安定したリリースにできるだけ頻繁に更新するようにしています。これにより、メンテナンスが容易になります。更新しないと、使用しているライブラリのバージョンのバグにパッチを適用したり、バグを回避したりする場合があります。更新の頻度を減らすと、処理する変更が増えるため、各更新の作業量が増え、最後にシステムに触れてから時間が長くなり、記憶が少なくなります。

于 2009-05-23T09:05:55.610 に答える
0

プロジェクトはそれほど長くは続かないことをお勧めします。数か月ごとに繰り返して、アプリケーションを細かく開発します。そうすれば、新しいテクノロジーが登場したときに、アプリケーション全体を再開発することを決定するのではなく、必要な変更を加えて更新を実装することができます。あなたが言うように、物事が変化するにつれてアプリケーション全体を開発しようとしてもうまくいきません。

于 2009-05-23T01:46:35.757 に答える