5

私は、ユーザーの大規模なインストールベースを持つ大規模なコードベースで作業しています。コードは元々、低レベルの作業用にいくつかのc++COMモジュールを使用してvb6で記述されていました。

すでにvb6で記述され、お客様が毎日使用しているすべてのコードを書き直すことは完全に不可能ですが、ソフトウェアの改善とカスタマイズも継続しています(大小)。

これまでの私の解決策は、新しいコードのほとんどをc#(winforms、さらにはwpf)で記述し、COM相互運用機能を使用してvb6からモジュールを呼び出すことです。

完全な書き直しのために止めることはできないが、同時に継続的な新しい開発が必要な、このような長期的なソフトウェアスイート(10年以上)の経験がある人はいますか?また、このような混合システムでは、モジュールをインターフェースするための最良の方法は何ですか?私は現在COMを使用していますが、個別のプロセスを使用するIPCも検討しています。

4

6 に答える 6

5

すべてを網羅する単一の答えを出すのは難しいですが、高レベルのアプローチは明らかです。少なくとも、これは私が使用したアプローチです。目標に優先順位を付けてから、それらの目標を達成するためのコストを特定してみてください。コストは本質的に「開発者の時間」に要約されます。

まず、機能しているものは何でも機能し続ける必要があります。動作しているものがあり、それを書き直す正当な理由がない場合は、そのままにしておいてください。

ジョブを実行するために既存のコードの一部を更新する必要がある場合は、メンテナンス コストが必要です。この時点で、書き換えによって保守コストが十分に改善されるかどうかを判断する必要があります。新しいバグが発生するため、新しいバグのテストとデバッグを差し引くことを忘れないでください。古いという理由だけで動作するコードを却下しないでください。

既存のコードが十分にモジュール化されている場合、通常は一度に 1 つずつ削り取ることができます。最初にメンテナンスの必要なコンポーネントを書き直します。

C# で新しい開発を行う場合は、COM コンポーネントを置き換える十分な理由が得られるまで、COM コンポーネントを問題なく使用できるはずです。

于 2009-03-25T02:15:11.593 に答える
3

あなたは良い計画を持っていると思います。これにより、最終的には、より優れたツールセットを利用して、ほとんどのコードが C# に移行されます。

VB6 コードは COM オブジェクトで構成されていますか?

コードは「完全な書き直しのために停止することはできません」と述べました。しかし、停止する必要はありません。VB6 機能の各部分を 1 つずつ、同等の C# コードに置き換えることができます。これにより、一度に 1 つの変更を加えることができます (できれば、何も壊していないことを証明する自動テストを使用してください)。

于 2009-03-25T02:10:03.850 に答える
3

動機がある場合は、必要に応じて書き直します。

私が取り組んでいた 1 つの古い Windows プロジェクトでは、C で記述されたルール エンジンが動作していたので、ブラック ボックス DLL として残しました。

私たちは新しいフロントエンドを構築しました。ユーザー ベースは、アプリケーションの使いやすく新しいモダンな外観に感銘を受けました。内部の何も変わっていませんでした。

データベース アクセス レイヤーは SQL Server DBLIB を使用しており、SQL Server をアップグレードするまで書き直されませんでした。

于 2009-03-25T02:22:26.537 に答える
1

この種のシステムがいくつかあります。このすべての不安な部分は、VB6 のライフサイクル サポート ステータスです。将来のサーバー アップグレードなどで重大な問題が発生した場合に、Microsoft から支援を受けることができず、自分で修正することができないというリスクがあります (小さいながらも)。 VB6 DLL およびパッチを適用したサーバー O/S)。これは、あなたの経営陣が関心を持っているかもしれないリスクです。

私たちは実際に、より重要なもののいくつかを書き直し、再設計することを検討しています。私たちは漸進的進化を試みましたが、うまくいく可能性がありますが、運用と保守の状況が興味深いものになります。まだ行っていない場合は、障害の分離に役立つように、すべて (古いコードと新しいコード) に構成可能なログを多数装備することを強くお勧めします。

COM は、従来のものと新しいものとの間の適切なインターフェイスのように思えます。コンポーネント間の相互作用が非常に単純でない限り、より基本的な IPC メカニズムに戻りたい理由がよくわかりません。COM には複雑さがありますが、再発明して維持しなければならないデータ型付けやバージョン管理など、多くの便利な抽象化も提供します...

于 2009-03-25T15:47:40.110 に答える
0

顧客のアップグレード パスを確認する必要があると思います。実際のところ、ある時点で 16 コアの CPU を使用すると、処理を高速化するために並行性が必要になります。したがって、VB6 から離れて WCF に移行するビジネス ケースがあります。WCF には、同時実行と同期のサポートが組み込まれています。プロセス間通信やマシン間通信だけでなく、ローカルのインプロセス通信にも使用できます。また、より多くの AOP スタイルのプログラミングを実行できるという利点もあります。

于 2009-03-25T02:07:50.080 に答える