8

私の会社には、VB6 で記述された大量のレガシーアプリケーションがあります。

VB6 アプリケーションから .NET (具体的には 3.5) への移行を進めています。

VB6 から .NET に移行するための最善の戦略は何ですか?



:以下の更新は「プロジェクト管理」に移動する必要があり、主な質問とは関係ありません。

[更新] : これまでのフィードバックに感謝します。
ポップアップする質問が増えました。

  1. 新しいアプリケーションを開発する開発者をどのように割り当てますか?
  2. レガシー アプリを新しいアプリに変換する特別な 1 回限りのアップグレード部門が必要ですか? それとも、すべての開発者が変換プロセスに参加する必要がありますか?
  3. 上級開発者のみが変換に参加する必要がありますか? ジュニア開発者?または混合?

この問題について考えれば考えるほど、より多くの疑問が浮かび上がってくるようです。

4

5 に答える 5

8

明らかに、これは多くの作業を伴う主要な事業です。
したがって、私のアドバイスは、それを非常に長期的なプロジェクトのように扱うことです。

セキュリティ、回復力、保守性、アプリケーションの将来などの主要な問題に対処する明確な目標を念頭に置いてください。

これが利害関係者によって合意されたら、C# と VB.net または MVC と Webforms を試すことができるプロトタイプ システムを開発して、仮定をテストします。私はあなたの最高の開発者をこれに割り当てます.

次に、小規模なレガシー システムの 1 つから始めて、他の領域で再利用するコア コンポーネントを構築します。
この段階では、上級開発者から始めますが、全員が参加して新しいフレームワークに慣れる必要があります。
これにより、全員が同時にトレーニングを受け、取り残されることがなくなります。
所有しているアプリケーションの数に応じて開発者をローテーションするので、すべてのシステムが恩恵を受けることができます。

また、すべての新しい作業は、VB6 ではなく、.net 言語で行う必要があります。

レガシー アプリケーションを 1 つずつ徐々に変換します。(それらが変更されている場合、またはそれらを更新することに明確な利点がある場合にのみ、それらを変換します。)

これにより、移行によってユーザーの機能が妨げられないようにしながら、今後使用するための強固なフレームワークが得られます。

例:
私は、およそ 40 ほどの VB アプリケーションを扱う会社で働いていました。
時間をかけてこれらすべてを C# に移行し、現在 (5 年後)、約 150 の C# アプリケーション (すべて .net 2.) があります。

これらはすべて共通のフレームワークを共有しているため、保守が容易で、必要に応じて拡張できます。

于 2009-03-25T23:34:07.417 に答える
7

コア機能を COM 対応の .NET ライブラリに置き換えてみてください。機能を少しずつ .NET に移行して、既存の VB6 アプリを「空洞化」します。

完全な書き換えに注意してください。彼らは「きれいなカットだから」魅力的ですが、通常は狂気が先にあります!準備として、Michael Feathers による「レガシー コードを効果的に使用する」をお読みください。この本は特に「ある言語から別の言語への移行」には踏み込んでいませんが、実際に遭遇する多くの落とし穴を示しています。

すべての開発者は、以前に開発したレガシー アプリの移行作業を行うタイム スロットを定義する必要があると思います。彼らはすでにドメイン知識を持ち、問題領域を知っているため、最も生産性が高いはずです。

于 2009-03-25T23:52:04.893 に答える
3

これは、同様の質問に対する私の回答の適応です。

大規模なプログラムを自動的に変換することは、書き直すよりも優れた選択です。大規模なソフトウェアを楽観的に書き直すことから始めて、古いアーキテクチャのよく知られた欠陥のいくつかを早期に修正し、その後、当然のことと思っていた機能に行き詰まってしまうことは、よくある落とし穴です。年。この時点で、あなたの経営陣は神経質になり始め、すべてが非常に不快になる可能性があります.

...そして、これは私に同意するMicrosofty によるブログ投稿です。

私が .NET の黎明期に一緒に働いていた多くの企業は、.NET への移行と同時に、基礎となるアーキテクチャとコード構造を改善したいという強い欲求に突き動かされて、最初に書き直しに目を向けました。残念なことに、これらのプロジェクトの多くは困難に陥り、いくつかは完成しませんでした。彼らが解決しようとしていた問題が大きすぎた

この優れた Microsoftページでは、2 つのサード パーティの移行ツールが、機能が不十分な組み込みの VB.NET アップグレード ウィザードよりも優れているとして推奨されています。 Artinsoftと CodeArchitects VBMigrationです。Artinsoft は組み込みの VB.NET アップグレード ウィザードを作成しました。これは改良版です。CodeArchitects は、VB6 と VB.NET に関する古典的な本をいくつか書いた Francesco Balena によって設立されました。

同じマイクロソフトのページにも次のように書かれています。

.NET への完全な書き換えは、[変換よりも] はるかにコストがかかり、適切に行うのが困難です ... このアプローチは、少数の状況でのみ推奨されます。


編集: Sung はコメントで次のように述べています。私は強く反対しなければなりません。一般に、私もコード生成のファンではありませんが、この場合、結果のコードは元の VB6 と同じように構造化され、ほぼ完全に機能するはずです。私はまだこれらのツールを自分で実際に試したことはありませんが、顧客 の声から、この約束は果たされています.

そして、多くの移行を支援した経験に基づいて、上記の Microsoft のアドバイスを繰り返します。「完全な書き直しは、[私の強調] を変換するよりもはるかにコストがかかり、困難です。」 - 同じ時間がかかる可能性があるという仮定の完全な矛盾。VB6 の構造を改善したい場合は、移行して段階的にリファクタリングする方が、書き直すよりもはるかに費用対効果が高くなる可能性があります。

于 2009-03-26T08:23:47.267 に答える
2

これを参照してください:
https://stackoverflow.com/questions/507291/should-we-select-vb-net-or-c-when-upgrading-our-legacy-apps

もちろん、C# と VB.Net の比較はその一部にすぎません。

たとえば、この機会を利用してこれらのアプリをイントラネットに移動するかどうかを検討する必要があります (まだ行っていない場合)。または、Microsoft のスタックをどれだけ深く掘り下げたいですか。たとえば、Winformsで十分ですか、それともWPFを使用したいですか。

于 2009-03-25T23:26:20.087 に答える
1

Microsoft のツールから始めます。

http://msdn.microsoft.com/en-us/library/aa480541.aspx

于 2009-03-25T23:25:30.353 に答える