2

.Net WPF でいくつかのレガシー COM アプリケーションを再構築するという新しい課題がまもなくやってくる予定です。可能であれば、機能や既存のコードを再利用する必要がありますが、その範囲は限られていると思います。

既存の機能を複製する必要がありますが、最新の拡張可能なアーキテクチャを使用して実現する必要があります。

このタイプのプロジェクトにアプローチするための一般的なアドバイスはありますか? このテーマに関する適切なリソースはありますか?

試行錯誤された手法や一般的な落とし穴はありますか?

4

6 に答える 6

4

最も重要なことは、自動化された検証 (ユニット/機能テスト) です。この質問を参照してください。多くのアドバイスは似ています。

これは、新しいシステム用のテストを作成するという意味ではありません。古いシステムを通過し、新しいシステムに引き継がれるテストを作成するという意味です。これは、元の機能を再作成したことを確認する方法です。すでに存在するシステムでは、BDDスタイルで実行できる機能仕様を(面倒ではありますが) 非常に簡単に作成できると思います。

于 2009-08-22T10:19:04.803 に答える
3

よくある落とし穴は、壊れていないものを直そうとすることです。既存のソフトウェアを再発明せずに再利用する方法を考えてください。それが長い間存在しているなら、それはそれが本当にうまくいったからかもしれません. 新しいバグを導入せずに機能を一致させるために、大きなタスクが待ち受けています。

もう一度言いますが、それはあなたの会社がこのレガシー システムを使い果たしてしまったからかもしれません。なぜこれを再設計するよう求められたのか、古いものにはどのような制限があり、解決する必要があるのか​​を考えてみてください。

于 2009-08-22T10:35:49.030 に答える
3

目標を慎重に検討してください。COM Foundation の置き換えだけに関心がありますか? データベースの実装も変更しますか (たとえば、インデックスから SQL に?) 画面を (GUI から Web に?) ...?

これが非常に小さなアプリケーションであれば、完全に手作業で書き直すことができるかもしれません。適度なサイズの場合は、既存のアプリケーションを変更できる可能性があります (おそらく、COM 機能を他の同等のスキームに置き換えるため)。これが中規模から大規模の場合、合理的な時間枠内で確実に書き直したり変更したりすることは事実上不可能です。

このような大規模な変更については、変更の自動化を検討することをお勧めします。このような変更を実装するためのツールは、 DMS Software Reengineering Toolkitにあります。DMS を使用して、C++ コードの 800K SLOC を持つ顧客のために、C++ から C# へのトランスレータのほとんどを実装し、COM インターフェイスを同等の C# 機能に置き換えました (プロジェクト全体の約 3/4 でバードケージ管理シャッフルにより、ほぼ完全であるにもかかわらず、翻訳されています)。

これを行う際に考慮すべきことの 1 つは、機能を変更せずにアプリケーションを最新化することに集中することです。多くの場合、管理者はスコープ クリープ (「まあ、そこにいる間にアプリケーションを変更して...」) に抵抗できません。これは惨事への道です。現在のものにつながるすべての変更を行うには何年もかかったということを覚えておいてください。

于 2009-08-22T11:18:58.800 に答える
3

Michael Feathers: レガシー コードを効果的に扱うには、レガシー コードを操作したり、置き換えたりするための多くのテクニックが紹介されています。とても読みやすいと思いました。いくつかの方法 (および多くのハック) は、私にとって初めてでした。

于 2009-08-22T10:56:14.043 に答える
2

新しく再設計されたシステムをデプロイする際には、データのヒープ全体を古いものから新しいものに変換または移植しなければならない可能性が高いことに注意してください。そうしないと、その仕事だけで書き直しと同じくらい大きくなる可能性があるため、これを考慮してください。適切に、確実に、または効率的に変換しないと、たとえ機能が適切であっても、初日から新しいシステムを破滅させる可能性があります。

于 2009-08-22T10:40:59.050 に答える
2

私は現在、ほぼこれとまったく同じことを行っています。

私ができる最も重要なアドバイスは、システムの仕様を変更することです。提供するものに対する新たな期待がなければ、古いシステムの基準に縛られることになります。これらの標準は素晴らしいものではありません。

現在のシステムを使用している人々から、彼らが実際に何を達成しようとしているのかを判断し、ストレート ポートではなく、それを構築します。関係者全員が、長期的にはより良い状態になるでしょう。

それ以外は、このプロセス中に機能を追加しようとしないでください。その機会は、アプリケーションを再構築した後に訪れます。移植を行う際に、既存の機能と矛盾する新しい要件を受け入れることほど悪いことはありません。

于 2009-08-24T01:47:27.287 に答える